idnits 2.17.1 draft-ietf-ipfix-architecture-08.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 1333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1318. ** 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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 774 has weird spacing: '...e, Flow timeo...' -- 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 (March 2005) is 6979 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) -- Looks like a reference, but probably isn't: 'IPFIX-INFO' on line 330 ** 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) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '7') (Obsoleted by RFC 5226) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 10 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: September 2, 2005 CAIDA | The University of Auckland 6 B. Claise 7 Cisco Systems, Inc. 8 J. Quittek 9 NEC Europe Ltd. 10 March 2005 12 Architecture for IP Flow Information Export 13 draft-ietf-ipfix-architecture-08 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 September 2, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 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, as 49 per the requirements set out in the IPFIX requirements document 50 IPFIX-REQS [1]. 52 Table of Contents 54 1. Changes/Issues from the -07 Draft . . . . . . . . . . . . . 4 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1 Document Scope . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2 IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Examples of Flows . . . . . . . . . . . . . . . . . . . . . 8 60 5. IPFIX Reference Model . . . . . . . . . . . . . . . . . . . 10 61 6. IPFIX Functional and Logical Blocks . . . . . . . . . . . . 11 62 6.1 Metering Process . . . . . . . . . . . . . . . . . . . . . 12 63 6.1.1 Flow Expiration . . . . . . . . . . . . . . . . . . . 12 64 6.1.2 Flow Export . . . . . . . . . . . . . . . . . . . . . 13 65 6.2 Observation Point . . . . . . . . . . . . . . . . . . . . 13 66 6.3 Selection Criteria for Packets . . . . . . . . . . . . . . 13 67 6.3.1 Sampling Functions, Si . . . . . . . . . . . . . . . . 14 68 6.3.2 Filter Functions, Fi . . . . . . . . . . . . . . . . . 14 69 6.4 Observation Domain . . . . . . . . . . . . . . . . . . . . 15 70 6.5 Exporting Process . . . . . . . . . . . . . . . . . . . . 15 71 6.6 Collecting Process . . . . . . . . . . . . . . . . . . . . 15 72 6.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 7. Overview of the IPFIX Protocol . . . . . . . . . . . . . . . 17 74 7.1 Information Model Overview . . . . . . . . . . . . . . . . 18 75 7.2 Flow Records . . . . . . . . . . . . . . . . . . . . . . . 18 76 7.3 Control Information . . . . . . . . . . . . . . . . . . . 19 77 7.4 Reporting Responsibilities . . . . . . . . . . . . . . . . 20 78 8. IPFIX Protocol Details . . . . . . . . . . . . . . . . . . . 20 79 8.1 The IPFIX Basis Protocol . . . . . . . . . . . . . . . . . 20 80 8.2 IPFIX Protocol on the Collecting Process . . . . . . . . . 21 81 8.3 Support for Applications . . . . . . . . . . . . . . . . . 21 82 9. Export Models . . . . . . . . . . . . . . . . . . . . . . . 21 83 9.1 Export with Reliable Control Connection . . . . . . . . . 21 84 9.2 Collector Failure Detection and Recovery . . . . . . . . . 22 85 9.3 Collector Redundancy . . . . . . . . . . . . . . . . . . . 22 86 10. IPFIX Flow Collection in Special Situations . . . . . . . . 23 87 11. Security Considerations . . . . . . . . . . . . . . . . . . 23 88 11.1 Data Security . . . . . . . . . . . . . . . . . . . . . 24 89 11.1.1 Host-Based Security . . . . . . . . . . . . . . . . 24 90 11.1.2 Authentication-only . . . . . . . . . . . . . . . . 24 91 11.1.3 Encryption . . . . . . . . . . . . . . . . . . . . . 25 92 11.2 IPFIX End-point Authentication . . . . . . . . . . . . . 25 93 12. IPFIX Overload . . . . . . . . . . . . . . . . . . . . . . . 25 94 12.1 Denial of Service (DoS) Attack Prevention . . . . . . . 26 95 12.1.1 Network Under Attack . . . . . . . . . . . . . . . . 26 96 12.1.2 Generic DoS Attack on the IPFIX Device and 97 Collector . . . . . . . . . . . . . . . . . . . . . 26 98 12.1.3 IPFIX Specific DoS Attack . . . . . . . . . . . . . 26 99 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 100 13.1 Numbers used in the Protocol . . . . . . . . . . . . . . 27 101 13.2 Numbers used in the Information Model . . . . . . . . . 27 102 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 103 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 15.1 Normative References . . . . . . . . . . . . . . . . . . 28 105 15.2 Informative References . . . . . . . . . . . . . . . . . 28 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 107 Intellectual Property and Copyright Statements . . . . . . . 30 109 1. Changes/Issues from the -07 Draft 111 Editorial Improvements: 113 Miscellaneous changes to text, making it clearer and simpler. 114 (Thanks to Paul Aitken for his detailed comments.) 116 2. Introduction 118 There are several applications e.g., usage-based accounting, traffic 119 profiling, traffic engineering, attack/intrusion detection, QoS 120 monitoring, that require flow-based IP traffic measurements. It is 121 therefore important to have a standard way of exporting information 122 related to IP flows. This document defines an architecture for IP 123 traffic flow monitoring, measuring and exporting. It provides a 124 high-level description of an IPFIX device's key components and their 125 functions. 127 2.1 Document Scope 129 This document defines the architecture for IPFIX. Its main 130 objectives are to: 132 o Describe the key IPFIX architectural components, consisting of (at 133 least) IPFIX devices and collectors communicating using the IPFIX 134 protocol. 136 o Define the IPFIX architectural requirements, e.g., recovery, 137 security, etc. 139 o Describe the characteristics of the IPFIX protocol. 141 2.2 IPFIX Documents Overview 143 The IPFIX protocol provides network administrators with access to IP 144 flow information. This document specifies the architecture for the 145 export of measured IP flow information from an IPFIX exporting 146 process to a collecting process, per the requirements defined in 147 IPFIX-REQS [1]. The IPFIX protocol document IPFIX-PROTO [3] 148 specifies how IPFIX data records and templates are carried via a 149 congestion-aware transport protocol from IPFIX exporting process to 150 IPFIX collecting process. IPFIX has a formal description of IPFIX 151 information elements (fields), their name, type and additional 152 semantic information, as specified in IPFIX-INFO [2]. Finally 153 IPFIX-AS [4] describes what type of applications can use the IPFIX 154 protocol and how they can use the information provided. It 155 furthermore shows how the IPFIX framework relates to other 156 architectures and frameworks. 158 Note that the IPFIX system does not provide for remote configuration 159 of an IPFIX device. Instead, IPFIX devices are configured by network 160 operations staff. 162 3. Terminology 164 The definitions of basic IPFIX terms such as IP Traffic Flow, 165 Exporting Process, Collecting Process, Observation Point, etc. are 166 semantically identical with those found in the IPFIX requirements 167 document IPFIX-REQS [1]. Some of the terms have been expanded for 168 more clarity when defining the protocol. Additional definitions 169 required for the architecture have also been defined. For the same 170 terms defined here and in IPFIX-PROTO [3] the definitions are 171 equivalent in both documents. 173 * Observation Point 175 An Observation Point is a location in the network where IP packets 176 can be observed. Examples include: a line to which a probe is 177 attached, a shared medium, such as an Ethernet-based LAN, a single 178 port of a router, or a set of interfaces (physical or logical) of 179 a router. 181 Note that vvery Observation Point is associated with an 182 Observation Domain (defined below), and that one Observation Point 183 may be a superset of several other Observation Points. For 184 example one Observation Point can be an entire line card. That 185 would be the superset of the individual Observation Points at the 186 line card's interfaces. 188 * Observation Domain 190 An Observation Domain is the largest set of Observation Points for 191 which Flow information can be aggregated by a Metering Process. 192 Each Observation Domain presents itself using a unique ID to the 193 Collecting Process to identify the IPFIX Messages it generates. 194 For example, a router line card may be an observation domain if it 195 is composed of several interfaces, each of which is an Observation 196 Point. 198 * IP Traffic Flow or Flow 199 There are several definitions of the term 'flow' being used by the 200 Internet community. Within the context of IPFIX we use the 201 following definition: 203 A Flow is defined as a set of IP packets passing an Observation 204 Point in the network during a certain time interval. All packets 205 belonging to a particular Flow have a set of common properties. 206 Each property is defined as the result of applying a function to 207 the values of: 209 1. One or more packet header field (e.g. destination IP address), 210 transport header field (e.g. destination port number), or 211 application header field (e.g. RTP header fields RTP-HDRF 212 [5]. 214 2. One or more characteristics of the packet itself (e.g. number 215 of MPLS labels) 217 3. One or more fields derived from packet treatment (e.g. next 218 hop IP address, output interface) 220 A packet is said to belong to a Flow if it completely satisfies 221 all the defined properties of the Flow. 223 This definition covers the range from a Flow containing all 224 packets observed at a network interface to a Flow consisting of 225 just a single packet between two applications. It includes 226 packets selected by a sampling mechanism. 228 * Flow Key 230 Each of the fields which 232 1. Belong to the packet header (e.g. destination IP address) 234 2. Are a property of the packet itself (e.g. packet length) 236 3. Are derived from packet treatment (e.g. AS number) 238 and which are used to define a Flow are termed Flow Keys. 240 * Flow Record 242 A Flow Record contains information about a specific Flow that was 243 observed at an Observation Point. A Flow Record contains measured 244 properties of the Flow (e.g. the total number of bytes for all the 245 Flow's packets) and usually characteristic properties of the Flow 246 (e.g. source IP address). 248 * Metering Process 250 The Metering Process generates Flow Records. Inputs to the 251 process are packet headers and characteristics observed at an 252 Observation Point, and packet treatment at the Observation Point 253 ((for example the selected output interface). 255 The Metering Process consists of a set of functions that includes 256 packet header capturing, timestamping, sampling, classifying, and 257 maintaining Flow Records. 259 The maintenance of Flow Records may include creating new records, 260 updating existing ones, computing Flow statistics, deriving 261 further Flow properties, detecting Flow expiration, passing Flow 262 Records to the Exporting Process, and deleting Flow Records. 264 * Exporting Process 266 An Exporting Process sends Flow Records to one or more Collecting 267 Processes. The Flow Records are generated by one or more Metering 268 Processes. 270 * Exporter 272 A device which hosts one or more Exporting Processes is termed an 273 Exporter. 275 * IPFIX Device 277 An IPFIX Device hosts at least one Observation Point, a Metering 278 Process and an Exporting Process. 280 * Collecting Process 282 A Collecting Process receives Flow Records from one or more 283 Exporting Processes. The Collecting Process might process or 284 store received Flow Records, but such actions are out of scope for 285 this document. 287 * Collector 289 A device which hosts one or more Collecting Processes is termed a 290 Collector. 292 * Template 293 A Template is an ordered sequence of pairs, used to 294 completely specify the structure and semantics of a particular set 295 of information that needs to be communicated from an IPFIX Device 296 to a Collector. Each Template is uniquely identifiable by means 297 of a Template ID. 299 * Control Information, Data Stream 301 The information that needs to be exported from the IPFIX Device 302 can be classified into the following categories: 304 Control Information 306 This includes the Flow definition, selection criteria for 307 packets within the Flow sent by the Exporting Process, and 308 templates describing the data to be exported. Control 309 Information carries all the information needed for the end- 310 points to understand the IPFIX protocol, and specifically for 311 the Collector to understand and interpret the data sent by the 312 sender Exporter. 314 Data Stream 316 This includes Flow Records carrying the field values for the 317 various observed Flows at each of the Observation Points. 319 IPFIX Message 321 An IPFIX Message is a message originating at the Exporting Process 322 that carries the IPFIX records of this Exporting Process and whose 323 destination is a Collecting Process. An IPFIX Message is 324 encapsulated at the transport layer. 326 Information Element 328 An Information Element is a protocol and encoding independent 329 description of an attribute which may appear in an IPFIX Record. 330 The IPFIX information model [IPFIX-INFO] defines the base set of 331 Information Elements for IPFIX. The type associated with an 332 Information Element indicates constraints on what it may contain 333 and also determines the valid encoding mechanisms for use in 334 IPFIX. 336 4. Examples of Flows 338 Some examples of Flows are listed below: 340 Example 1: The Flow Keys define the different fields by which Flows 341 are distinguished. The different combination of the field values 342 creates unique Flows. If {source IP address, destination IP address, 343 DSCP} are flow keys, then all of these are different Flows: 345 1. {198.18.40.1, 198.18.23.5, 4} 346 2. {198.18.40.23, 198.18.23.67, 4} 347 3. {198.18.40.23, 198.18.23.67, 2} 348 4. {198.18.20.200, 198.18.23.67, 4} 350 Example 2: A mask function can be applied to all the packets that 351 pass through an Observation Point, in order to aggregate some values. 352 This could be done by defining the set of Flow Keys as {source IP 353 address, destination IP address, DSCP} as in example 1 above, and 354 applying a function which masks out the least significant 8 bits of 355 the source IP address and destination IP address (i.e. the result is 356 a /24 address). The four Flows from example 1 would now be 357 aggregated into three Flows by merging the Flows 1 and 2 into a 358 single Flow: 360 1. {198.18.40.0/24, 198.18.23.0/24, 4} 361 2. {198.18.40.0/24, 198.18.23.0/24, 2} 362 3. {198.18.20.0/24, 198.18.23.0/24, 4} 364 Example 3: A filter defined by some Flow Key values can be applied on 365 all packets that pass the Observation Point, in order to select only 366 certain Flows. The filter is defined by choosing fixed values for 367 specific Keys from the packet. 369 All the packets that go from a customer network 198.18.40.0/24 to 370 another customer network 198.18.23.0/24 with DSCP value of 4 define a 371 Flow. All other combinations don't define a Flow and are not taken 372 into account. The three Flows from example 2 would now be reduced to 373 one Flow by filtering away the second and the third Flow, leaving 374 only {198.18.40.0/24, 198.18.23.0/24, 4}. 376 The above examples can be thought of as a function F() taking as 377 input {source IP address, destination IP address, DSCP}. The 378 function selects only the packets which satisfy all three of the 379 following conditions: 381 1. Mask out the least significant 8 bits of source IP address, match 382 against 198.18.40.0. 384 2. Mask out the least significant 8 bits of destination IP address, 385 match against 198.18.23.0. 387 3. Only accept DSCP value equal to 4. 389 Depending on the values of {source IP address, destination IP 390 address, DSCP} of the different observed packets, the Metering 391 Process function F() would choose/filter/aggregate different sets of 392 packets, which would create different Flows. For example, for 393 various combinations of values of {source IP address, destination IP 394 address, DSCP}, F(source IP address, destination IP address, DSCP) 395 would result in the definition of one or more Flows. 397 5. IPFIX Reference Model 399 The figure below shows the reference model for IPFIX. This figure 400 covers the various possible scenarios that can exist in an IPFIX 401 system. 403 +----------------+ +----------------+ 404 |[*Application 1]| ..|[*Application n]| 405 +--------+-------+ +-------+--------+ 406 ^ ^ 407 ~ ~ 408 +~~~~~~~~~~+~~~~~~~~+ 409 ^ 410 ~ 411 +------------------------+ +-------+------------------+ 412 |IPFIX Exporter | | Collector(1) | 413 |[Exporting Process(es)] |<----------->| [Collecting Process(es)] | 414 +------------------------+ +--------------------------+ 415 .... .... 416 +------------------------+ +---------------------------+ 417 |IPFIX Device(i) | | Collector(j) | 418 |[Observation Point(s)] |<---------->| [Collecting Process(es)] | 419 |[Metering Process(es)] | +---->| [*Application(s)] | 420 |[Exporting Process(es)] | | +---------------------------+ 421 +------------------------+ . 422 .... . .... 423 +------------------------+ | +--------------------------+ 424 |IPFIX Device(m) | | | Collector(n) | 425 |[Observation Point(s)] |<-----+---->| [Collecting Process(es)] | 426 |[Metering Process(es)] | | [*Application(s)] | 427 |[Exporting Process(es)] | +--------------------------+ 428 +------------------------+ 430 The various functional components are indicated within brackets []. 431 The functional components within [*] are not part of the IPFIX 432 architecture. The interfaces shown by "<-->" are defined by the 433 IPFIX architecture but those shown by "<~~>" are not. 435 Figure 3 437 The figure below shows a typical IPFIX Device where the IPFIX 438 components are shown in rectangular boxes. 440 +-------------------------------------------------+ 441 | IPFIX Device | 442 | +-----+ | 443 | +---......--+-----------+---------> | | 444 | | | | | | 445 | +----+----+ +----+----+ | | | 446 | |Metering | |Metering | | E | | 447 | |Process 1| |Process N| | x | | 448 | +---------+ +---------+ | p | | 449 | ^ ^ | o | | 450 | +------+----------------------+-------+ | r | | 451 | | | Observation Domain 1 | | | t | | 452 | |+-----+------+ +-----+------+| | i | | 453 | ||Obsv Point 1| ... |Obsv Point M|| | n | | 454 | |+------------+ +------------+| | g | | Export 455 Packets | +------^------------------------^-----+ | | | packets 456 --->----+--------+----------.....---------+ | | | to 457 In | | +---------> 458 | . . . . . | | |Collector 459 | | | | 460 | +---......--+-----------+---------> | | 461 | | | | | | 462 | +----+----+ +----+----+ | P | | 463 | |Metering | |Metering | | r | | 464 | |Process 1| |Process N| | o | | 465 | +---------+ +---------+ | c | | 466 | ^ ^ | e | | 467 | +------+----------------------+-------+ | s | | 468 | | | Observation Domain K | | | s | | 469 | |+-----+------+ +-----+------+| | | | 470 | ||Obsv Point 1| ... |Obsv Point M|| | | | 471 | |+------------+ +------------+| | | | 472 Packets | +------^------------------------^-----+ +-----+ | 473 --->----+--------+---------- ... ---------+ | 474 In | | 475 +-------------------------------------------------+ 477 Figure 4 479 6. IPFIX Functional and Logical Blocks 480 6.1 Metering Process 482 Every Observation Point in an IPFIX Device, participating in Flow 483 measurements, must be associated with at least one Metering Process. 484 Every packet coming into an Observation Point goes into each of the 485 Metering Processes associated with the Observation Point. Broadly, 486 each Metering Process observes the packets that pass an Observation 487 Point, does timestamping and classifies the packets into Flow(s) 488 based on the selection criteria. 490 The Metering Process is a functional block which manages all the 491 Flows generated from an Observation Domain. The typical functions of 492 a Metering Process may include: 494 o Maintain database(s) of all the Flow Records from an Observation 495 Domain. This includes creating new Flow Records, updating 496 existing ones, computing Flow Records statistics, deriving further 497 Flow properties, adding non-flow-specific information based on the 498 packet treatment (in some cases fields like AS numbers, router 499 state, etc.) 501 o Maintain statistics about the Metering Process itself, such as 502 Flow Records generated, packets observed, etc. 504 6.1.1 Flow Expiration 506 A Flow is considered to have expired under the following conditions: 508 1. If no packets belonging to the Flow have been observed for a 509 certain period of time. This time period should be configurable 510 at the Metering Process, with a minimum value of 0 seconds for 511 immediate expiration. Note that a zero timeout would report a 512 Flow as a sequence of single-packet Flows. 514 2. If the IPFIX Device experiences resource constraints, a Flow may 515 be prematurely expired (e.g. lack of memory to store Flow 516 Records) 518 3. For long-running Flows, the Metering Process should expire the 519 Flow on a regular basis or based on some expiration policy. This 520 periodicity or expiration policy should be configurable at the 521 Metering Process. When a long-running Flow is expired, its Flow 522 Record may still be maintained by the Metering Process so that 523 the Metering Process does not need to create a new Flow Record 524 for further observed packets of the same Flow. 526 6.1.2 Flow Export 528 The Exporting Process decides when and whether to export an expired 529 Flow. A Flow can be exported because it expired for any of the 530 reasons mentioned in Flow Expiration section. For example: the 531 Exporting Process exports a portion of the expired Flows every 'x' 532 seconds. 534 For long-lasting Flows, the Exporting Process should export the Flow 535 Records on a regular basis or based on some export policy. This 536 periodicity or export policy should be configurable at the Metering 537 Process. 539 6.2 Observation Point 541 A Flow Record can be better analyzed if the Observation Point from 542 which it was measured is known. As such it is recommended that IPFIX 543 Devices send this information to Collectors. In cases where there is 544 a single Observation Point or where the Observation Point information 545 is not relevant, the Metering Process may choose not to add the 546 Observation Point information to the Flow Records. 548 6.3 Selection Criteria for Packets 550 A Metering Process may define rules so that only certain packets 551 within an incoming stream of packets are chosen for measurement at an 552 Observation Point. This may be done by one of the two methods 553 defined below or a combination of them, in either order. A 554 combination of each of these methods can be adopted to select the 555 packets, i.e. one can define a set of methods {F1, S1, F2, S2, S3} 556 executed in a specified sequence at an Observation Point to select 557 particular Flows. 559 The figure below shows the operations which may be applied as part of 560 a typical Metering Process. 562 packet header capturing 563 | 564 timestamping 565 | 566 v 567 +----->+ 568 | | 569 | sampling Si (1:1 in case of no sampling) 570 | | 571 | filtering Fi (select all when no criteria) 572 | | 573 +------+ 574 | 575 v 576 Flows 578 Figure 5 580 6.3.1 Sampling Functions, Si 582 A sampling function determines which packets within a stream of 583 incoming packets is selected for measurement, i.e. packets that 584 satisfy the sampling criteria for this Metering Process. 586 Example: sample every 100th packet that was received at an 587 Observation Point. 589 Choosing all the packets is a special case where the sampling rate is 590 1:1. 592 6.3.2 Filter Functions, Fi 594 A Filter Function selects only those incoming packets that satisfy a 595 function on fields defined by the packet header fields, fields 596 obtained while doing the packet processing, or properties of the 597 packet itself. 599 Example: Mask/Match of the fields that define a filter. A filter 600 might be defined as {Protocol == TCP, Destination Port between 80 and 601 120}. 603 Several such filters could be used in any sequence to select packets. 604 Note that packets selected by a (sequence of) filter functions may be 605 further classified by other filter functions, i.e. the selected 606 packets may belong to several Flows, any or all of which are 607 exported. 609 6.4 Observation Domain 611 The Observation Domain is a logical block that presents a single 612 identity for a group of Observation Points within an IPFIX Device. 613 Each {Observation Point, Metering Process} pair belongs to a single 614 Observation Domain. An IPFIX Device could have multiple Observation 615 Domains, each of which has a subset of the total set of Observation 616 Points in it. Each Observation Domain must carry a unique ID within 617 the context of an IPFIX Device. Note that in case of multiple 618 Observation Domains, a unique ID per Observation Domain must be 619 transmitted as a parameter to the Exporting Function. That unique ID 620 is referred to as the IPFIX Source ID. 622 6.5 Exporting Process 624 The Exporting Process is the functional block that sends data to one 625 or more IPFIX Collectors using the IPFIX protocol. On one side the 626 Exporting Process interfaces with Metering Process(es) to get Flow 627 Records, while on the other side it talks to a Collecting Process on 628 the Collector(s). 630 There may be additional rules defined within an Observation Domain so 631 that only certain Flow Records are exported. This may be done by 632 either one or a combination of Si, Fi, as described in the section on 633 "Selection Criteria for Packets". 635 Example: Only the Flow Records which meet the following selection 636 criteria are exported: 638 1. All Flow Records whose destination IP address matches 639 {198.18.33.5}. 641 2. Every other (i.e. sampling rate 1 in 2) Flow Record whose 642 destination IP address matches {198.18.11.30}. 644 6.6 Collecting Process 646 Collecting Processes use a Flow Record's Template ID to interpret 647 that Flow Record's Information Elements. To allow this, an IPFIX 648 Exporter must ensure that an IPFIX Collector knows the Template ID 649 for each incoming Flow Record. To interpret incoming Flow Records, 650 an IPFIX Collector may also need to know the function F() that was 651 used by the Metering Process for each Flow. 653 The functions of the Collecting Process must include: 655 o Identifying, accepting and decoding the IPFIX Messages from 656 different pairs. 658 o Storing the Control Information and Flow Records received from an 659 IPFIX Device. 661 At a high level, the Collecting Process: 663 1. Receives and stores the Control Information. 665 2. Decodes and stores the Flow Records using the Control 666 Information. 668 6.7 Summary 670 The figure below shows the functions performed in sequence by the 671 various functional blocks in an IPFIX Device. 673 Packet(s) coming in to Observation Point(s) 674 | | 675 v v 676 +----------------+-------------------------+ +-----+-------+ 677 | Metering Process on an | | | 678 | Observation Point | | | 679 | | | | 680 | packet header capturing | | | 681 | | |...| Metering | 682 | timestamping | | Process N | 683 | | | | | 684 | +----->+ | | | 685 | | | | | | 686 | | sampling Si (1:1 in case of no | | | 687 | | | sampling) | | | 688 | | classifying Fi (select all when | | | 689 | | | no criteria) | | | 690 | +------+ | | | 691 | | | | | 692 | | Timing out Flows | | | 693 | | Handle resource overloads | | | 694 +--------|---------------------------------+ +-----|-------+ 695 | | 696 Flow Records (identified by Observation Domain) Flow Records 697 | | 698 +---------+---------------------------------+ 699 | 700 +--------------------|----------------------------------------------+ 701 | | Exporting Process | 702 |+-------------------|-------------------------------------------+ | 703 || v IPFIX Protocol | | 704 ||+-----------------------------+ +----------------------------+| | 705 |||Rules for | |Functions || | 706 ||| Picking/sending Templates | |-Packetize selected Control || | 707 ||| Picking/sending Flow Records|->| & data Information into || | 708 ||| Encoding Template & data | | IPFIX export packets. || | 709 ||| Selecting Flows to export(*)| |-Handle export errors || | 710 ||+-----------------------------+ +----------------------------+| | 711 |+----------------------------+----------------------------------+ | 712 | | | 713 | exported IPFIX Messages | 714 | | | 715 | +------------+-----------------+ | 716 | | Anonymize export packet(*) | | 717 | +------------+-----------------+ | 718 | | | 719 | +------------+-----------------+ | 720 | | Transport Protocol | | 721 | +------------+-----------------+ | 722 | | | 723 +-----------------------------+-------------------------------------+ 724 | 725 v 726 IPFIX export packet to Collector 728 (*) indicates that the block is optional. 730 Figure 6 732 7. Overview of the IPFIX Protocol 734 An IPFIX Device consists of a set of co-operating processes that 735 implement the functional blocks described in the previous section. 736 Alternatively, an IPFIX Device can be viewed simply as a network 737 entity which implements the IPFIX protocol. At the IPFIX Device, the 738 protocol functionality resides in the Exporting Process. The IPFIX 739 Exporting Process gets Flow Records from a Metering Process, and 740 sends them to the Collector(s). 742 At a high level, an IPFIX Device performs the following tasks: 744 1. Encode Control Information into Templates. 746 2. Encode packets observed at the Observation Points into Flow 747 Records. 749 3. Packetize the selected Templates and Flow Records into IPFIX 750 Messages. 752 4. Send IPFIX Messages to the Collector. 754 The IPFIX protocol communicates information from an IPFIX Exporter to 755 an IPFIX Collector. That information includes not only Flow Records, 756 but also information about the Metering Process. Such information 757 (referred to as Control Information) includes details of the data 758 fields in Flow Records. It may also include statistics from the 759 Metering Process, such as the number of packets lost (i.e. not 760 metered). 762 For details of the IPFIX protocol please refer to IPFIX-PROTO [3]. 764 7.1 Information Model Overview 766 The IP Flow Information eXport (IPFIX) protocol serves for 767 transmitting information related to measured IP traffic over the 768 Internet. The protocol specification in IPFIX-PROTO [3] defines how 769 Information Elements are transmitted. For Information Elements, it 770 specifies the encoding of a set of basic data types. However, the 771 list of fields that can be transmitted by the protocol, such as Flow 772 attributes (source IP address, number of packets, etc.) and 773 information about the Metering and Exporting Process (packet 774 Observation Point, sampling rate, Flow timeout interval, etc.), is 775 not specified in IPFIX-PROTO [3]. Instead, it is defined in the 776 IPFIX Information Model document IPFIX-INFO [2]. 778 The Information Model provides a complete description of the 779 properties of every IPFIX Information Element. It does this by 780 specifying each element's name, Field Type, data type, etc., and 781 providing a description of each element. Element descriptions give 782 the semantics of the element, i.e. say how it is derived from a Flow 783 or other information available within an IPFIX Device. 785 7.2 Flow Records 787 The following rules provide guidelines to be followed while encoding 788 the Flow Records information: 790 A Flow Record contains enough information so that the Collecting 791 Process can identify the corresponding . 794 The Exporting Process encodes a given Information Element (as 795 specified in IPFIX-INFO [2]), based on the encoding standards 796 prescribed by IPFIX-PROTO [3]. 798 7.3 Control Information 800 The following rules provide guidelines to be followed while encoding 801 the Control Information: 803 o Per-Flow Control Information should be encoded such that the 804 Collecting Process can capture the structure and semantics of the 805 corresponding Flow data for each of the Flow Records exported by 806 the IPFIX Device. 808 o Configuration Control Information is conveyed to a Collector so 809 that its Collecting Process can capture the structure and 810 semantics of the corresponding configuration data. The 811 configuration data which is also Control Information should carry 812 additional information on the Observation Domain within which the 813 configuration takes effect. 815 For example, sampling using the same sampling algorithm, say 1 in 100 816 packets, is configured on two Observation Points O1 and O2. The 817 configuration in this case may be encoded as {ID, configuration 818 domain (O1,O2), sampling algorithm, interval (1 in 100)}, where ID 819 uniquely identifies this configuration. The ID must be sent within 820 the Flow Records in order to be able to match the right configuration 821 control information. 823 The Control Information is used by the Collecting Process to: 825 o Decode and interpret Flow Records. 827 o Understand the state of the Exporting Process. 829 Sending Control Information from the Exporting Process in a timely 830 and reliable manner is critical to the proper functioning of the 831 IPFIX Collecting Process. The following approaches may be taken for 832 the export of Control Information: 834 1. Send all the Control Information pertaining to Flow Records prior 835 to sending the Flow Records themselves. This includes any 836 incremental changes to the definition of the Flow Records. 838 2. Notify on a near real time basis the state of the IPFIX Device to 839 the Collecting Process. This includes all changes such as a 840 configuration change that affects the Flow behavior, changes to 841 Exporting Process resources that alter export rates, etc., which 842 the Collector needs to be aware of. 844 3. Since it is vital that a Collecting Process maintains accurate 845 knowledge of the Exporter's state, the export of the Control 846 Information should be done such that it reaches the Collector 847 reliably. One way to achieve this is to send the Control 848 Information over a reliable transport. 850 7.4 Reporting Responsibilities 852 From time to time an IPFIX Device may not be able to observe all the 853 packets reaching one of its Observation Points. This could occur if 854 a Metering Process finds itself temporarily short of resources. For 855 example it might run out of packet buffers for IPFIX export, or it 856 might detect errors in its underlying transport layer. 858 In such situations, the IPFIX Device must report the number of packet 859 losses that have occurred to its Collector(s). 861 8. IPFIX Protocol Details 863 When the IPFIX Working Group was chartered there were existing common 864 practices in the area of Flow export, for example NetFlow, CRANE, 865 LFAP, RTFM, etc. IPFIX's charter required the Working Group to 866 consider those existing practices, and select the one that was the 867 closest fit to the IPFIX requirements IPFIX-REQS [1]. Additions or 868 modifications would then be made to the selected protocol to fit it 869 exactly into the IPFIX architecture. 871 8.1 The IPFIX Basis Protocol 873 The Working Group went through an extensive evaluation of the various 874 existing protocols that were available, weighing the level of 875 compliance with the requirements, and selected one of the candidates 876 as the basis for the IPFIX protocol. For more details of the 877 evaluation process please see IPFIX-EVAL [6]. 879 In the basis protocol Flow Records are defined by Templates, where a 880 Template is an ordered set of the Information Elements appearing in a 881 Flow Record, together with their field sizes within those records. 883 This approach provides the following advantages: 885 o Using the Template mechanism, new fields can be added to IPFIX 886 Flow Records without changing the structure of the export record 887 format. 889 o Templates that are sent to the Collecting Process carry structural 890 information about the exported Flow Record fields. Therefore, if 891 the Collector does not understand the semantics of new fields it 892 can ignore them, but still interpret the Flow Record. 894 o Because the template mechanism is flexible, it allows the export 895 of only the required fields from the Flows to the Collecting 896 Process. This helps to reduce the exported Flow data volume and 897 possibly provide memory savings at the Exporting Process and 898 Collecting Process. Sending only the required information can 899 also reduce network load. 901 8.2 IPFIX Protocol on the Collecting Process 903 The Collecting Process is responsible for: 905 1. Receiving and decoding Flow Records from the IPFIX Devices. 907 2. Reporting on the loss of Flow Records sent to the Collecting 908 Process by an IPFIX Exporting Process. 910 Complete details of the IPFIX protocol are given in IPFIX-PROTO [3]. 912 8.3 Support for Applications 914 Applications that use the information collected by IPFIX may be 915 Billing or Intrusion Detection sub-systems, etc. These applications 916 may be an integral part of the Collecting Process or they may be co- 917 located with the Collecting Process. The way by which these 918 applications interface with IPFIX systems to get the desired 919 information is out of scope for this document. 921 9. Export Models 923 9.1 Export with Reliable Control Connection 925 As mentioned in the IPFIX-REQS [1] document, an IPFIX Device must be 926 able to transport its Control Information and Data Stream over a 927 congestion-aware transport protocol. 929 If the network in which the IPFIX Device and Collecting Process are 930 located does not guarantee reliability, at least the Control 931 Information should be exported over a reliable transport. The Data 932 Stream may be exported over a reliable or unreliable transport 933 protocol. 935 Possible transport protocols include: 937 o SCTP: Supports reliable and unreliable transport. 939 o TCP: Provides reliable transport only. 941 o UDP: Provides unreliable transport only. Network operators would 942 need to avoid congestion by keeping traffic within their own 943 administrative domains. 945 9.2 Collector Failure Detection and Recovery 947 The transport connection (in the case of a connection oriented 948 protocol) is pre-configured between the IPFIX Device and the 949 Collector. The IPFIX protocol does not provide any mechanism for 950 configuring the Exporting and Collecting Processes. 952 Once connected, an IPFIX Collector receives Control Information and 953 uses that information to interpret Flow Records. The IPFIX Device 954 should set a keepalive (e.g. the keepalive timeout in the case of 955 TCP, the HEARTBEAT interval in the case of SCTP) to a sufficiently 956 low value so that it can quickly detect a Collector failure. 958 Collector failure refers to the crash or restart of the Collecting 959 Process, or of the Collector itself. A Collector failure is detected 960 at the IPFIX Device by the break in the connection oriented transport 961 protocol session, depending on the transport protocol - the 962 connection timeout mechanisms differ. On detecting a keepalive 963 timeout in a single Collector scenario, the IPFIX Device should stop 964 sending Flow Records to the Collector and try to reestablish the 965 transport connection. If Collecting Process failover is supported by 966 the Exporting Process, backup session(s) may be opened in advance, 967 and Control Information sent to it. 969 There could be one or more secondary Collectors with priority 970 assigned to them. The primary Collector crash is detected at the 971 IPFIX Device. On detecting loss of connectivity, the IPFIX Device 972 opens a Data Stream with the secondary Collector of the next highest 973 priority. If that secondary was not opened in advance, both the 974 Control Information and Data Stream must be sent to it. That 975 Collector might then become the primary, or the Exporting Process 976 might try to reestablish the original session. 978 9.3 Collector Redundancy 980 Configuring redundant Collectors is an alternative to configuring 981 backup Collectors. In this model, all Collectors simultaneously 982 receive the Control Information and Data Streams. Multiple {Control 983 Information, Data Stream} pairs could be sent, each to a different 984 Collector from the same IPFIX Device. Since the IPFIX protocol 985 requires a congestion-aware transport, achieving redundancy using 986 multicast is not an option. 988 10. IPFIX Flow Collection in Special Situations 990 An IPFIX Device could be doing one or more of generating, receiving, 991 altering special types of traffic which are listed below. 993 Tunnel traffic: 995 The IPFIX Device could be the head, midpoint or endpoint of a 996 tunnel. In such cases the IPFIX Device could be handling GRE, 997 IPinIP or UTI traffic. 999 VPN traffic: 1001 The IPFIX Device could be a provider edge device which receives 1002 traffic from customer sites belonging to different Virtual Private 1003 Networks. 1005 Similarly, IPFIX could be implemented on devices which perform one or 1006 more of the following special services: 1008 o Explicitly drop packets. For example a device which provides 1009 firewall service drops packets based on some administrative 1010 policy. 1012 o Alter the values of fields used as IPFIX Flow Keys of interest. 1013 For example a device which provides NAT service can change source 1014 and/or destination IP address. 1016 In cases such as those listed above, there should be clear guidelines 1017 as to: 1019 o How and when to classify the packets as Flows in the IPFIX Device. 1021 o If multiple encapsulations are used to define Flows, how to convey 1022 the same fields (e.g. IP address) in different layers. 1024 o How to differentiate Flows based on different private domains. 1025 For example, overlapping IP addresses in Layer-3 VPNs. 1027 o What extra information needs be exported so that the Collector can 1028 make a clear interpretation of the received Flow Records. 1030 11. Security Considerations 1032 Flow information can be used for various purposes, such as usage 1033 accounting, traffic profiling, traffic engineering, and intrusion 1034 detection. The security requirement may differ significantly for 1035 such applications. To be able to satisfy the security needs of 1036 various IPFIX users, an IPFIX system must provide different levels of 1037 security protection. 1039 11.1 Data Security 1041 IPFIX data comprises Control Information and Data Stream generated by 1042 the IPFIX Device. 1044 The IPFIX data may exist in both the IPFIX Device and the Collector. 1045 In addition, the data is also transferred on the wire from the IPFIX 1046 Device to the Collector when it is exported. To provide security, 1047 the data should be protected from common network attacks. 1049 The protection of IPFIX data within the end system (IPFIX Device and 1050 Collector) is out of scope for this document. It is assumed that the 1051 end system operator will provide adequate security for the IPFIX 1052 data. 1054 The IPFIX architecture must allow different levels of protection to 1055 the IPFIX data on the wire. Wherever security functions are required 1056 it is recommended that users should leverage lower layers using 1057 either IPSEC or TLS, if these can successfully satisfy the security 1058 requirement of IPFIX data protection. 1060 To protect the data on the wire, three levels of granularity should 1061 be supported; these are described in the following subsections. 1063 11.1.1 Host-Based Security 1065 Security may not be required when the transport between the IPFIX 1066 Device and the Collector is perceived as safe. This option allows 1067 the protocol to run most efficiently without extra overhead and an 1068 IPFIX system must support it. 1070 11.1.2 Authentication-only 1072 Authentication-only protection provides IPFIX users with the 1073 assurance of data integrity and authenticity. The data exchanged 1074 between the IPFIX Device and the Collector is protected by an 1075 authentication signature. Any modification of the IPFIX data will be 1076 detected by the recipient, resulting in discarding of the received 1077 data. However, the authentication-only option doesn't offer data 1078 confidentiality. 1080 The IPFIX user should not use authentication-only when sensitive or 1081 confidential information is being exchanged. An IPFIX solution 1082 should support this option. The authentication-only option should 1083 provide replay attack protection. Some means to achieve this level 1084 of security are: 1086 o TCP with MD5 options. 1088 o IP Authentication Header 1090 11.1.3 Encryption 1092 Data encryption provides the best protection for IPFIX data. The 1093 IPFIX data is encrypted at the sender and only the intended recipient 1094 can decrypt and have access to the data. This option must be used 1095 when the transport between the IPFIX Device and the Collector are 1096 unsafe and the IPFIX data needs to be protected. It is recommended 1097 that the underlying transport layer's security functions be used for 1098 this purpose. Some means to achieve this level of security are: 1100 o Encapsulating Security Payload. 1102 o Transport Layer Security Protocol 1104 The data encryption option adds overhead to the IPFIX data transfer. 1105 It may limit the rate that an Exporter can report its Flow Records to 1106 the Collector due to the resource requirement for running encryption. 1108 11.2 IPFIX End-point Authentication 1110 It is important to make sure that the IPFIX Device is talking to the 1111 "right" Collector rather than to a masquerading Collector. The same 1112 logic also holds true from the Collector point of view, i.e. it may 1113 want to make sure it is collecting the Flow Records from the "right" 1114 IPFIX Device. An IPFIX system should allow the end point 1115 authentication capability so that either one-way or mutual 1116 authentication can be performed between the IPFIX Device and 1117 Collector. 1119 The IPFIX architecture should use any existing transport protection 1120 protocols such as TLS or IPSEC to fulfill the authentication 1121 requirement. 1123 12. IPFIX Overload 1125 An IPFIX Device could become overloaded under various conditions. 1126 This may be because of exhaustion of internal resources used for Flow 1127 generation and/or export. Such overloading may cause loss of data 1128 from the Exporting Process, either from lack of export bandwidth 1129 (possibly caused by an unusually high number of observed Flows) or 1130 from network congestion in the path from Exporter to Collector. 1132 IPFIX Collectors should be able to detect the loss of exported Flow 1133 Records, and should at least record the number of lost Flow Records. 1135 12.1 Denial of Service (DoS) Attack Prevention 1137 Since one of the potential usages for IPFIX is for intrusion 1138 detection, it is important for the IPFIX architecture to support some 1139 kind of DoS resistance. 1141 12.1.1 Network Under Attack 1143 The Network itself may be under attack, resulting in an overwhelming 1144 number of IPFIX Messages. An IPFIX system should try to capture as 1145 much information as possible. However, when a large number of IPFIX 1146 Messages are generated in a short period of time, the IPFIX system 1147 may become overloaded. 1149 12.1.2 Generic DoS Attack on the IPFIX Device and Collector 1151 The IPFIX Device and Collector may be subject to generic DoS attacks, 1152 just as any system on any open network. These types of attacks are 1153 not IPFIX specific. Preventing and responding to such types of 1154 attacks are out of the scope of this document. 1156 12.1.3 IPFIX Specific DoS Attack 1158 There are some specific attacks on the IPFIX portion of the IPFIX 1159 Device or Collector: 1161 o The attacker could overwhelm the Collector with spoofed IPFIX 1162 export packets. One way to solve this problem is to periodically 1163 synchronize the sequence numbers of the Flow Records between the 1164 Exporting and Collecting Processes. 1166 o The attacker could provide false reports to the Collector by 1167 sending spoofed packets. 1169 The problems mentioned above can be solved to a large extent if the 1170 control packets are encrypted both ways. 1172 13. IANA Considerations 1174 The IPFIX Architecture, as set out in this document, has two sets of 1175 assigned numbers. Considerations for assigning them are discussed in 1176 this section, using the example policies as set out in the 1177 "Guidelines for IANA Considerations" document IANA-RFC [7]. 1179 13.1 Numbers used in the Protocol 1181 IPFIX Messages, as described in IPFIX-PROTO [3], use two fields with 1182 assigned values. These are the IPFIX Version Number, indicating 1183 which version of the IPFIX Protocol was used to export an IPFIX 1184 Message, and the IPFIX Template Number, indicating the type for each 1185 set of information within an IPFIX message. 1187 Changes in either IPFIX Version Number or IPFIX Template Number 1188 assignments require an IETF Consensus, i.e. they are to be made via 1189 RFCs approved by the IESG. 1191 13.2 Numbers used in the Information Model 1193 Fields of the IPFIX protocol carry information about traffic 1194 measurement. They are modeled as elements of the IPFIX information 1195 model IPFIX-INFO [2]. Each Information Element describes a field 1196 which may appear in an IPFIX Message. Within an IPFIX message the 1197 field type is indicated by its Field Type. 1199 Changes in IPFIX Field Type will be administered by IANA, subject to 1200 Expert Review, i.e. review by one of a group of experts designated by 1201 an IETF Operations and Management Area Director. Those experts will 1202 initially be drawn from the Working Group Chairs and document editors 1203 of the IPFIX and PSAMP Working Groups. 1205 14. Acknowledgements 1207 The document editors wish to thank all the people contributing to the 1208 discussion of this document on the mailing list, and the design teams 1209 for many valuable comments. In particular, the following made 1210 significant contributions: 1212 Tanja Zseby 1213 Paul Calato 1214 Dave Plonka 1215 Jeffrey Meyer 1216 K.C.Norseth 1217 Vamsi Valluri 1218 Cliff Wang 1219 Ram Gopal 1220 Jc Martin 1221 Carter Bullard 1222 Reinaldo Penno 1223 Simon Leinen 1224 Kevin Zhang 1225 Paul Aitken 1226 Special thanks to Dave Plonka for the multiple thorough reviews. 1228 15. References 1230 15.1 Normative References 1232 [1] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements 1233 for IP Flow Information Export", RFC RFC 3917, October 2004. 1235 [2] Meyer, J., Quittek, J., and S. Bryant, "IPFIX: Information 1236 Model", (work in progress), Internet Draft, 1237 draft-ietf-ipfix-info-08.txt, October 2004. 1239 [3] Claise, B., Bryant, S., Sadasivan, G., and M. Fullmer, "IPFIX: 1240 Protocol", (work in progress), Internet Draft, 1241 draft-ietf-ipfix-protocol-10.txt, December 2004. 1243 [4] Zseby, T., Boschi, E., Penno, R., Brownlee, N., and B. Claise, 1244 "IPFIX: Protocol", (work in progress), Internet Draft, 1245 draft-ietf-ipfix-as-05.txt, October 2004. 1247 15.2 Informative References 1249 [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1250 "RTP: A Transport Protocol for Real-Time Applications", 1251 RFC 1889, January 1996. 1253 [6] Leinen, S., "Evaluation of Candidate Protocols for IP Flow 1254 Information Export", RFC 3955, October 2004. 1256 [7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1257 Considerations Section in RFCs", RFC 2434, October 1998. 1259 Authors' Addresses 1261 Ganesh Sadasivan 1262 Cisco Systems, Inc. 1263 170 West Tasman Drive 1264 San Jose, CA 95134 1265 USA 1267 Phone: +1 408 527-0251 1268 Email: gsadasiv@cisco.com 1269 Nevil Brownlee 1270 CAIDA | The University of Auckland 1271 Private Bag 92019 1272 Auckland 1273 New Zealand 1275 Phone: +64 9 373 7599 x8941 1276 Email: n.brownlee@auckland.ac.nz 1278 Benoit Claise 1279 Cisco Systems, Inc. 1280 De Kleetlaan 6a b1 1281 1831 Diegem 1282 Belgium 1284 Phone: +32 2 704 5622 1285 Email: bclaise@cisco.com 1287 Juergen Quittek 1288 NEC Europe Ltd. 1289 Adenauerplatz 6 1290 69225 Heidelberg 1291 Germany 1293 Phone: +49 6221 90511-15 1294 Email: quittek@ccrle.nec.de 1296 Intellectual Property Statement 1298 The IETF takes no position regarding the validity or scope of any 1299 Intellectual Property Rights or other rights that might be claimed to 1300 pertain to the implementation or use of the technology described in 1301 this document or the extent to which any license under such rights 1302 might or might not be available; nor does it represent that it has 1303 made any independent effort to identify any such rights. Information 1304 on the procedures with respect to rights in RFC documents can be 1305 found in BCP 78 and BCP 79. 1307 Copies of IPR disclosures made to the IETF Secretariat and any 1308 assurances of licenses to be made available, or the result of an 1309 attempt made to obtain a general license or permission for the use of 1310 such proprietary rights by implementers or users of this 1311 specification can be obtained from the IETF on-line IPR repository at 1312 http://www.ietf.org/ipr. 1314 The IETF invites any interested party to bring to its attention any 1315 copyrights, patents or patent applications, or other proprietary 1316 rights that may cover technology that may be required to implement 1317 this standard. Please address the information to the IETF at 1318 ietf-ipr@ietf.org. 1320 The IETF has been notified of intellectual property rights claimed in 1321 regard to some or all of the specification contained in this 1322 document. For more information consult the online list of claimed 1323 rights. 1325 Disclaimer of Validity 1327 This document and the information contained herein are provided on an 1328 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1329 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1330 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1331 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1332 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1333 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1335 Copyright Statement 1337 Copyright (C) The Internet Society (2005). This document is subject 1338 to the rights, licenses and restrictions contained in BCP 78, and 1339 except as set forth therein, the authors retain all their rights. 1341 Acknowledgment 1343 Funding for the RFC Editor function is currently provided by the 1344 Internet Society.