idnits 2.17.1 draft-ietf-ipfix-architecture-09.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 1339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1324. ** 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 772 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 (August 15, 2005) is 6821 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 327 ** 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: February 16, 2006 CAIDA | The University of Auckland 6 B. Claise 7 Cisco Systems, Inc. 8 J. Quittek 9 NEC Europe Ltd. 10 August 15, 2005 12 Architecture for IP Flow Information Export 13 draft-ietf-ipfix-architecture-09 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 February 16, 2006. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1 Document Scope . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2 IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Examples of Flows . . . . . . . . . . . . . . . . . . . . . 8 59 4. IPFIX Reference Model . . . . . . . . . . . . . . . . . . . 10 60 5. IPFIX Functional and Logical Blocks . . . . . . . . . . . . 11 61 5.1 Metering Process . . . . . . . . . . . . . . . . . . . . . 11 62 5.1.1 Flow Expiration . . . . . . . . . . . . . . . . . . . 12 63 5.1.2 Flow Export . . . . . . . . . . . . . . . . . . . . . 12 64 5.2 Observation Point . . . . . . . . . . . . . . . . . . . . 13 65 5.3 Selection Criteria for Packets . . . . . . . . . . . . . . 13 66 5.3.1 Sampling Functions, Si . . . . . . . . . . . . . . . . 14 67 5.3.2 Filter Functions, Fi . . . . . . . . . . . . . . . . . 14 68 5.4 Observation Domain . . . . . . . . . . . . . . . . . . . . 15 69 5.5 Exporting Process . . . . . . . . . . . . . . . . . . . . 15 70 5.6 Collecting Process . . . . . . . . . . . . . . . . . . . . 15 71 5.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 6. Overview of the IPFIX Protocol . . . . . . . . . . . . . . . 17 73 6.1 Information Model Overview . . . . . . . . . . . . . . . . 18 74 6.2 Flow Records . . . . . . . . . . . . . . . . . . . . . . . 18 75 6.3 Control Information . . . . . . . . . . . . . . . . . . . 19 76 6.4 Reporting Responsibilities . . . . . . . . . . . . . . . . 20 77 7. IPFIX Protocol Details . . . . . . . . . . . . . . . . . . . 20 78 7.1 The IPFIX Basis Protocol . . . . . . . . . . . . . . . . . 20 79 7.2 IPFIX Protocol on the Collecting Process . . . . . . . . . 21 80 7.3 Support for Applications . . . . . . . . . . . . . . . . . 21 81 8. Export Models . . . . . . . . . . . . . . . . . . . . . . . 21 82 8.1 Export with Reliable Control Connection . . . . . . . . . 21 83 8.2 Collector Failure Detection and Recovery . . . . . . . . . 22 84 8.3 Collector Redundancy . . . . . . . . . . . . . . . . . . . 22 85 9. IPFIX Flow Collection in Special Situations . . . . . . . . 23 86 10. Security Considerations . . . . . . . . . . . . . . . . . . 23 87 10.1 Data Security . . . . . . . . . . . . . . . . . . . . . 24 88 10.1.1 Host-Based Security . . . . . . . . . . . . . . . . 24 89 10.1.2 Authentication-only . . . . . . . . . . . . . . . . 24 90 10.1.3 Encryption . . . . . . . . . . . . . . . . . . . . . 25 91 10.2 IPFIX End-point Authentication . . . . . . . . . . . . . 25 92 11. IPFIX Overload . . . . . . . . . . . . . . . . . . . . . . . 25 93 11.1 Denial of Service (DoS) Attack Prevention . . . . . . . 26 94 11.1.1 Network Under Attack . . . . . . . . . . . . . . . . 26 95 11.1.2 Generic DoS Attack on the IPFIX Device and 96 Collector . . . . . . . . . . . . . . . . . . . . . 26 98 11.1.3 IPFIX Specific DoS Attack . . . . . . . . . . . . . 26 99 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 100 12.1 Numbers used in the Protocol . . . . . . . . . . . . . . 27 101 12.2 Numbers used in the Information Model . . . . . . . . . 27 102 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 103 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 14.1 Normative References . . . . . . . . . . . . . . . . . . 28 105 14.2 Informative References . . . . . . . . . . . . . . . . . 28 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 107 A. Changes/Issues from the -08 Draft . . . . . . . . . . . . . 29 108 Intellectual Property and Copyright Statements . . . . . . . 30 110 1. Introduction 112 There are several applications e.g., usage-based accounting, traffic 113 profiling, traffic engineering, attack/intrusion detection, QoS 114 monitoring, that require flow-based IP traffic measurements. It is 115 therefore important to have a standard way of exporting information 116 related to IP flows. This document defines an architecture for IP 117 traffic flow monitoring, measuring and exporting. It provides a 118 high-level description of an IPFIX device's key components and their 119 functions. 121 1.1 Document Scope 123 This document defines the architecture for IPFIX. Its main 124 objectives are to: 126 o Describe the key IPFIX architectural components, consisting of (at 127 least) IPFIX devices and collectors communicating using the IPFIX 128 protocol. 130 o Define the IPFIX architectural requirements, e.g., recovery, 131 security, etc. 133 o Describe the characteristics of the IPFIX protocol. 135 1.2 IPFIX Documents Overview 137 The IPFIX protocol provides network administrators with access to IP 138 flow information. This document specifies the architecture for the 139 export of measured IP flow information from an IPFIX exporting 140 process to a collecting process, per the requirements defined in 141 IPFIX-REQS [1]. The IPFIX protocol document IPFIX-PROTO [3] 142 specifies how IPFIX data records and templates are carried via a 143 congestion-aware transport protocol from IPFIX exporting process to 144 IPFIX collecting process. IPFIX has a formal description of IPFIX 145 information elements (fields), their name, type and additional 146 semantic information, as specified in IPFIX-INFO [2]. Finally 147 IPFIX-AS [4] describes what type of applications can use the IPFIX 148 protocol and how they can use the information provided. It 149 furthermore shows how the IPFIX framework relates to other 150 architectures and frameworks. 152 Note that the IPFIX system does not provide for remote configuration 153 of an IPFIX device. Instead, IPFIX devices are configured by network 154 operations staff. 156 2. Terminology 158 The definitions of basic IPFIX terms such as IP Traffic Flow, 159 Exporting Process, Collecting Process, Observation Point, etc. are 160 semantically identical with those found in the IPFIX requirements 161 document IPFIX-REQS [1]. Some of the terms have been expanded for 162 more clarity when defining the protocol. Additional definitions 163 required for the architecture have also been defined. For the same 164 terms defined here and in IPFIX-PROTO [3] the definitions are 165 equivalent in both documents. 167 * Observation Point 169 An Observation Point is a location in the network where IP packets 170 can be observed. Examples include: a line to which a probe is 171 attached, a shared medium, such as an Ethernet-based LAN, a single 172 port of a router, or a set of interfaces (physical or logical) of 173 a router. 175 Note that vvery Observation Point is associated with an 176 Observation Domain (defined below), and that one Observation Point 177 may be a superset of several other Observation Points. For 178 example one Observation Point can be an entire line card. That 179 would be the superset of the individual Observation Points at the 180 line card's interfaces. 182 * Observation Domain 184 An Observation Domain is the largest set of Observation Points for 185 which Flow information can be aggregated by a Metering Process. 186 Each Observation Domain presents itself using a unique ID to the 187 Collecting Process to identify the IPFIX Messages it generates. 188 For example, a router line card may be an observation domain if it 189 is composed of several interfaces, each of which is an Observation 190 Point. 192 * IP Traffic Flow or Flow 194 There are several definitions of the term 'flow' being used by the 195 Internet community. Within the context of IPFIX we use the 196 following definition: 198 A Flow is defined as a set of IP packets passing an Observation 199 Point in the network during a certain time interval. All packets 200 belonging to a particular Flow have a set of common properties. 201 Each property is defined as the result of applying a function to 202 the values of: 204 1. One or more packet header field (e.g. destination IP address), 205 transport header field (e.g. destination port number), or 206 application header field (e.g. RTP header fields RTP-HDRF 207 [5]. 209 2. One or more characteristics of the packet itself (e.g. number 210 of MPLS labels) 212 3. One or more fields derived from packet treatment (e.g. next 213 hop IP address, output interface) 215 A packet is said to belong to a Flow if it completely satisfies 216 all the defined properties of the Flow. 218 This definition covers the range from a Flow containing all 219 packets observed at a network interface to a Flow consisting of 220 just a single packet between two applications. It includes 221 packets selected by a sampling mechanism. 223 * Flow Key 225 Each of the fields which 227 1. Belong to the packet header (e.g. destination IP address) 229 2. Are a property of the packet itself (e.g. packet length) 231 3. Are derived from packet treatment (e.g. AS number) 233 and which are used to define a Flow are termed Flow Keys. 235 * Flow Record 237 A Flow Record contains information about a specific Flow that was 238 observed at an Observation Point. A Flow Record contains measured 239 properties of the Flow (e.g. the total number of bytes for all the 240 Flow's packets) and usually characteristic properties of the Flow 241 (e.g. source IP address). 243 * Metering Process 245 The Metering Process generates Flow Records. Inputs to the 246 process are packet headers and characteristics observed at an 247 Observation Point, and packet treatment at the Observation Point 248 ((for example the selected output interface). All measurements 249 must be conducted from the point of view of the observation point. 251 The Metering Process consists of a set of functions that includes 252 packet header capturing, timestamping, sampling, classifying, and 253 maintaining Flow Records. 255 The maintenance of Flow Records may include creating new records, 256 updating existing ones, computing Flow statistics, deriving 257 further Flow properties, detecting Flow expiration, passing Flow 258 Records to the Exporting Process, and deleting Flow Records. 260 * Exporting Process 262 An Exporting Process sends Flow Records to one or more Collecting 263 Processes. The Flow Records are generated by one or more Metering 264 Processes. 266 * Exporter 268 A device which hosts one or more Exporting Processes is termed an 269 Exporter. 271 * IPFIX Device 273 An IPFIX Device hosts at least one Observation Point, a Metering 274 Process and an Exporting Process. 276 * Collecting Process 278 A Collecting Process receives Flow Records from one or more 279 Exporting Processes. The Collecting Process might process or 280 store received Flow Records, but such actions are out of scope for 281 this document. 283 * Collector 285 A device which hosts one or more Collecting Processes is termed a 286 Collector. 288 * Template 290 A Template is an ordered sequence of pairs, used to 291 completely specify the structure and semantics of a particular set 292 of information that needs to be communicated from an IPFIX Device 293 to a Collector. Each Template is uniquely identifiable by means 294 of a Template ID. 296 * Control Information, Data Stream 298 The information that needs to be exported from the IPFIX Device 299 can be classified into the following categories: 301 Control Information 303 This includes the Flow definition, selection criteria for 304 packets within the Flow sent by the Exporting Process, and 305 templates describing the data to be exported. Control 306 Information carries all the information needed for the end- 307 points to understand the IPFIX protocol, and specifically for 308 the Collector to understand and interpret the data sent by the 309 sender Exporter. 311 Data Stream 313 This includes Flow Records carrying the field values for the 314 various observed Flows at each of the Observation Points. 316 IPFIX Message 318 An IPFIX Message is a message originating at the Exporting Process 319 that carries the IPFIX records of this Exporting Process and whose 320 destination is a Collecting Process. An IPFIX Message is 321 encapsulated at the transport layer. 323 Information Element 325 An Information Element is a protocol and encoding independent 326 description of an attribute which may appear in an IPFIX Record. 327 The IPFIX information model [IPFIX-INFO] defines the base set of 328 Information Elements for IPFIX. The type associated with an 329 Information Element indicates constraints on what it may contain 330 and also determines the valid encoding mechanisms for use in 331 IPFIX. 333 3. Examples of Flows 335 Some examples of Flows are listed below: 337 Example 1: The Flow Keys define the different fields by which Flows 338 are distinguished. The different combination of the field values 339 creates unique Flows. If {source IP address, destination IP address, 340 DSCP} are flow keys, then all of these are different Flows: 342 1. {198.18.40.1, 198.18.23.5, 4} 343 2. {198.18.40.23, 198.18.23.67, 4} 344 3. {198.18.40.23, 198.18.23.67, 2} 345 4. {198.18.20.200, 198.18.23.67, 4} 347 Example 2: A mask function can be applied to all the packets that 348 pass through an Observation Point, in order to aggregate some values. 349 This could be done by defining the set of Flow Keys as {source IP 350 address, destination IP address, DSCP} as in example 1 above, and 351 applying a function which masks out the least significant 8 bits of 352 the source IP address and destination IP address (i.e. the result is 353 a /24 address). The four Flows from example 1 would now be 354 aggregated into three Flows by merging the Flows 1 and 2 into a 355 single Flow: 357 1. {198.18.40.0/24, 198.18.23.0/24, 4} 358 2. {198.18.40.0/24, 198.18.23.0/24, 2} 359 3. {198.18.20.0/24, 198.18.23.0/24, 4} 361 Example 3: A filter defined by some Flow Key values can be applied on 362 all packets that pass the Observation Point, in order to select only 363 certain Flows. The filter is defined by choosing fixed values for 364 specific Keys from the packet. 366 All the packets that go from a customer network 198.18.40.0/24 to 367 another customer network 198.18.23.0/24 with DSCP value of 4 define a 368 Flow. All other combinations don't define a Flow and are not taken 369 into account. The three Flows from example 2 would now be reduced to 370 one Flow by filtering away the second and the third Flow, leaving 371 only {198.18.40.0/24, 198.18.23.0/24, 4}. 373 The above examples can be thought of as a function F() taking as 374 input {source IP address, destination IP address, DSCP}. The 375 function selects only the packets which satisfy all three of the 376 following conditions: 378 1. Mask out the least significant 8 bits of source IP address, match 379 against 198.18.40.0. 381 2. Mask out the least significant 8 bits of destination IP address, 382 match against 198.18.23.0. 384 3. Only accept DSCP value equal to 4. 386 Depending on the values of {source IP address, destination IP 387 address, DSCP} of the different observed packets, the Metering 388 Process function F() would choose/filter/aggregate different sets of 389 packets, which would create different Flows. For example, for 390 various combinations of values of {source IP address, destination IP 391 address, DSCP}, F(source IP address, destination IP address, DSCP) 392 would result in the definition of one or more Flows. 394 4. IPFIX Reference Model 396 The figure below shows the reference model for IPFIX. This figure 397 covers the various possible scenarios that can exist in an IPFIX 398 system. 400 +----------------+ +----------------+ 401 |[*Application 1]| ..|[*Application n]| 402 +--------+-------+ +-------+--------+ 403 ^ ^ 404 ~ ~ 405 +~~~~~~~~~~+~~~~~~~~+ 406 ^ 407 ~ 408 +------------------------+ +-------+------------------+ 409 |IPFIX Exporter | | Collector(1) | 410 |[Exporting Process(es)] |<----------->| [Collecting Process(es)] | 411 +------------------------+ +--------------------------+ 412 .... .... 413 +------------------------+ +---------------------------+ 414 |IPFIX Device(i) | | Collector(j) | 415 |[Observation Point(s)] |<---------->| [Collecting Process(es)] | 416 |[Metering Process(es)] | +---->| [*Application(s)] | 417 |[Exporting Process(es)] | | +---------------------------+ 418 +------------------------+ . 419 .... . .... 420 +------------------------+ | +--------------------------+ 421 |IPFIX Device(m) | | | Collector(n) | 422 |[Observation Point(s)] |<-----+---->| [Collecting Process(es)] | 423 |[Metering Process(es)] | | [*Application(s)] | 424 |[Exporting Process(es)] | +--------------------------+ 425 +------------------------+ 427 The various functional components are indicated within brackets []. 428 The functional components within [*] are not part of the IPFIX 429 architecture. The interfaces shown by "<-->" are defined by the 430 IPFIX architecture but those shown by "<~~>" are not. 432 Figure 3 434 The figure below shows a typical IPFIX Device where the IPFIX 435 components are shown in rectangular boxes. 437 +-------------------------------------------------+ 438 | IPFIX Device | 439 | +-----+ | 440 | +---......--+-----------+---------> | | 441 | | | | | | 442 | +----+----+ +----+----+ | | | 443 | |Metering | |Metering | | E | | 444 | |Process 1| |Process N| | x | | 445 | +---------+ +---------+ | p | | 446 | ^ ^ | o | | 447 | +------+----------------------+-------+ | r | | 448 | | | Observation Domain 1 | | | t | | 449 | |+-----+------+ +-----+------+| | i | | 450 | ||Obsv Point 1| ... |Obsv Point M|| | n | | 451 | |+------------+ +------------+| | g | | Export 452 Packets | +------^------------------------^-----+ | | | packets 453 --->----+--------+----------.....---------+ | | | to 454 In | | +---------> 455 | . . . . . | | |Collector 456 | | | | 457 | +---......--+-----------+---------> | | 458 | | | | | | 459 | +----+----+ +----+----+ | P | | 460 | |Metering | |Metering | | r | | 461 | |Process 1| |Process N| | o | | 462 | +---------+ +---------+ | c | | 463 | ^ ^ | e | | 464 | +------+----------------------+-------+ | s | | 465 | | | Observation Domain K | | | s | | 466 | |+-----+------+ +-----+------+| | | | 467 | ||Obsv Point 1| ... |Obsv Point M|| | | | 468 | |+------------+ +------------+| | | | 469 Packets | +------^------------------------^-----+ +-----+ | 470 --->----+--------+---------- ... ---------+ | 471 In | | 472 +-------------------------------------------------+ 474 Figure 4 476 5. IPFIX Functional and Logical Blocks 478 5.1 Metering Process 480 Every Observation Point in an IPFIX Device, participating in Flow 481 measurements, must be associated with at least one Metering Process. 482 Every packet coming into an Observation Point goes into each of the 483 Metering Processes associated with the Observation Point. Broadly, 484 each Metering Process observes the packets that pass an Observation 485 Point, does timestamping and classifies the packets into Flow(s) 486 based on the selection criteria. 488 The Metering Process is a functional block which manages all the 489 Flows generated from an Observation Domain. The typical functions of 490 a Metering Process may include: 492 o Maintain database(s) of all the Flow Records from an Observation 493 Domain. This includes creating new Flow Records, updating 494 existing ones, computing Flow Records statistics, deriving further 495 Flow properties, adding non-flow-specific information based on the 496 packet treatment (in some cases fields like AS numbers, router 497 state, etc.) 499 o Maintain statistics about the Metering Process itself, such as 500 Flow Records generated, packets observed, etc. 502 5.1.1 Flow Expiration 504 A Flow is considered to have expired under the following conditions: 506 1. If no packets belonging to the Flow have been observed for a 507 certain period of time. This time period should be configurable 508 at the Metering Process, with a minimum value of 0 seconds for 509 immediate expiration. Note that a zero timeout would report a 510 Flow as a sequence of single-packet Flows. 512 2. If the IPFIX Device experiences resource constraints, a Flow may 513 be prematurely expired (e.g. lack of memory to store Flow 514 Records) 516 3. For long-running Flows, the Metering Process should expire the 517 Flow on a regular basis or based on some expiration policy. This 518 periodicity or expiration policy should be configurable at the 519 Metering Process. When a long-running Flow is expired, its Flow 520 Record may still be maintained by the Metering Process so that 521 the Metering Process does not need to create a new Flow Record 522 for further observed packets of the same Flow. 524 5.1.2 Flow Export 526 The Exporting Process decides when and whether to export an expired 527 Flow. A Flow can be exported because it expired for any of the 528 reasons mentioned in Flow Expiration section. For example: the 529 Exporting Process exports a portion of the expired Flows every 'x' 530 seconds. 532 For long-lasting Flows, the Exporting Process should export the Flow 533 Records on a regular basis or based on some export policy. This 534 periodicity or export policy should be configurable at the Metering 535 Process. 537 5.2 Observation Point 539 A Flow Record can be better analyzed if the Observation Point from 540 which it was measured is known. As such it is recommended that IPFIX 541 Devices send this information to Collectors. In cases where there is 542 a single Observation Point or where the Observation Point information 543 is not relevant, the Metering Process may choose not to add the 544 Observation Point information to the Flow Records. 546 5.3 Selection Criteria for Packets 548 A Metering Process may define rules so that only certain packets 549 within an incoming stream of packets are chosen for measurement at an 550 Observation Point. This may be done by one of the two methods 551 defined below or a combination of them, in either order. A 552 combination of each of these methods can be adopted to select the 553 packets, i.e. one can define a set of methods {F1, S1, F2, S2, S3} 554 executed in a specified sequence at an Observation Point to select 555 particular Flows. 557 The figure below shows the operations which may be applied as part of 558 a typical Metering Process. 560 packet header capturing 561 | 562 timestamping 563 | 564 v 565 +----->+ 566 | | 567 | sampling Si (1:1 in case of no sampling) 568 | | 569 | filtering Fi (select all when no criteria) 570 | | 571 +------+ 572 | 573 v 574 Flows 576 Figure 5 578 5.3.1 Sampling Functions, Si 580 A sampling function determines which packets within a stream of 581 incoming packets is 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 Source 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 {198.18.33.5}. 639 2. Every other (i.e. sampling rate 1 in 2) Flow Record whose 640 destination IP address matches {198.18.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 668 The figure below shows the functions performed in sequence by the 669 various functional blocks in an IPFIX Device. 671 Packet(s) coming in to Observation Point(s) 672 | | 673 v v 674 +----------------+-------------------------+ +-----+-------+ 675 | Metering Process on an | | | 676 | Observation Point | | | 677 | | | | 678 | packet header capturing | | | 679 | | |...| Metering | 680 | timestamping | | Process N | 681 | | | | | 682 | +----->+ | | | 683 | | | | | | 684 | | sampling Si (1:1 in case of no | | | 685 | | | sampling) | | | 686 | | classifying Fi (select all when | | | 687 | | | no criteria) | | | 688 | +------+ | | | 689 | | | | | 690 | | Timing out Flows | | | 691 | | Handle resource overloads | | | 692 +--------|---------------------------------+ +-----|-------+ 693 | | 694 Flow Records (identified by Observation Domain) Flow Records 695 | | 696 +---------+---------------------------------+ 697 | 698 +--------------------|----------------------------------------------+ 699 | | Exporting Process | 700 |+-------------------|-------------------------------------------+ | 701 || v IPFIX Protocol | | 702 ||+-----------------------------+ +----------------------------+| | 703 |||Rules for | |Functions || | 704 ||| Picking/sending Templates | |-Packetize selected Control || | 705 ||| Picking/sending Flow Records|->| & data Information into || | 706 ||| Encoding Template & data | | IPFIX export packets. || | 707 ||| Selecting Flows to export(*)| |-Handle export errors || | 708 ||+-----------------------------+ +----------------------------+| | 709 |+----------------------------+----------------------------------+ | 710 | | | 711 | exported IPFIX Messages | 712 | | | 713 | +------------+-----------------+ | 714 | | Anonymize export packet(*) | | 715 | +------------+-----------------+ | 716 | | | 717 | +------------+-----------------+ | 718 | | Transport Protocol | | 719 | +------------+-----------------+ | 720 | | | 721 +-----------------------------+-------------------------------------+ 722 | 723 v 724 IPFIX export packet to Collector 726 (*) indicates that the block is optional. 728 Figure 6 730 6. Overview of the IPFIX Protocol 732 An IPFIX Device consists of a set of co-operating processes that 733 implement the functional blocks described in the previous section. 734 Alternatively, an IPFIX Device can be viewed simply as a network 735 entity which implements the IPFIX protocol. At the IPFIX Device, the 736 protocol functionality resides in the Exporting Process. The IPFIX 737 Exporting Process gets Flow Records from a Metering Process, and 738 sends them to the Collector(s). 740 At a high level, an IPFIX Device performs the following tasks: 742 1. Encode Control Information into Templates. 744 2. Encode packets observed at the Observation Points into Flow 745 Records. 747 3. Packetize the selected Templates and Flow Records into IPFIX 748 Messages. 750 4. Send IPFIX Messages to the Collector. 752 The IPFIX protocol communicates information from an IPFIX Exporter to 753 an IPFIX Collector. That information includes not only Flow Records, 754 but also information about the Metering Process. Such information 755 (referred to as Control Information) includes details of the data 756 fields in Flow Records. It may also include statistics from the 757 Metering Process, such as the number of packets lost (i.e. not 758 metered). 760 For details of the IPFIX protocol please refer to IPFIX-PROTO [3]. 762 6.1 Information Model Overview 764 The IP Flow Information eXport (IPFIX) protocol serves for 765 transmitting information related to measured IP traffic over the 766 Internet. The protocol specification in IPFIX-PROTO [3] defines how 767 Information Elements are transmitted. For Information Elements, it 768 specifies the encoding of a set of basic data types. However, the 769 list of fields that can be transmitted by the protocol, such as Flow 770 attributes (source IP address, number of packets, etc.) and 771 information about the Metering and Exporting Process (packet 772 Observation Point, sampling rate, Flow timeout interval, etc.), is 773 not specified in IPFIX-PROTO [3]. Instead, it is defined in the 774 IPFIX Information Model document IPFIX-INFO [2]. 776 The Information Model provides a complete description of the 777 properties of every IPFIX Information Element. It does this by 778 specifying each element's name, Field Type, data type, etc., and 779 providing a description of each element. Element descriptions give 780 the semantics of the element, i.e. say how it is derived from a Flow 781 or other information available within an IPFIX Device. 783 6.2 Flow Records 785 The following rules provide guidelines to be followed while encoding 786 the Flow Records information: 788 A Flow Record contains enough information so that the Collecting 789 Process can identify the corresponding . 792 The Exporting Process encodes a given Information Element (as 793 specified in IPFIX-INFO [2]), based on the encoding standards 794 prescribed by IPFIX-PROTO [3]. 796 6.3 Control Information 798 The following rules provide guidelines to be followed while encoding 799 the Control Information: 801 o Per-Flow Control Information should be encoded such that the 802 Collecting Process can capture the structure and semantics of the 803 corresponding Flow data for each of the Flow Records exported by 804 the IPFIX Device. 806 o Configuration Control Information is conveyed to a Collector so 807 that its Collecting Process can capture the structure and 808 semantics of the corresponding configuration data. The 809 configuration data which is also Control Information should carry 810 additional information on the Observation Domain within which the 811 configuration takes effect. 813 For example, sampling using the same sampling algorithm, say 1 in 100 814 packets, is configured on two Observation Points O1 and O2. The 815 configuration in this case may be encoded as {ID, configuration 816 domain (O1,O2), sampling algorithm, interval (1 in 100)}, where ID 817 uniquely identifies this configuration. The ID must be sent within 818 the Flow Records in order to be able to match the right configuration 819 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 behavior, 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, or it 854 might detect errors in its underlying transport layer. 856 In such situations, the IPFIX Device must report the number of packet 857 losses that have occurred to its Collector(s). 859 7. IPFIX Protocol Details 861 When the IPFIX Working Group was chartered there were existing common 862 practices in the area of Flow export, for example NetFlow, CRANE, 863 LFAP, RTFM, etc. IPFIX's charter required the Working Group to 864 consider those existing practices, and select the one that was the 865 closest fit to the IPFIX requirements IPFIX-REQS [1]. Additions or 866 modifications would then be made to the selected protocol to fit it 867 exactly into the IPFIX architecture. 869 7.1 The IPFIX Basis Protocol 871 The Working Group went through an extensive evaluation of the various 872 existing protocols that were available, weighing the level of 873 compliance with the requirements, and selected one of the candidates 874 as the basis for the IPFIX protocol. For more details of the 875 evaluation process please see IPFIX-EVAL [6]. 877 In the basis protocol Flow Records are defined by Templates, where a 878 Template is an ordered set of the Information Elements appearing in a 879 Flow Record, together with their field sizes within those records. 881 This approach provides the following advantages: 883 o Using the Template mechanism, new fields can be added to IPFIX 884 Flow Records without changing the structure of the export record 885 format. 887 o Templates that are sent to the Collecting Process carry structural 888 information about the exported Flow Record fields. Therefore, if 889 the Collector does not understand the semantics of new fields it 890 can ignore them, but still interpret the Flow Record. 892 o Because the template mechanism is flexible, it allows the export 893 of only the required fields from the Flows to the Collecting 894 Process. This helps to reduce the exported Flow data volume and 895 possibly provide memory savings at the Exporting Process and 896 Collecting Process. Sending only the required information can 897 also reduce network load. 899 7.2 IPFIX Protocol on the Collecting Process 901 The Collecting Process is responsible for: 903 1. Receiving and decoding Flow Records from the IPFIX Devices. 905 2. Reporting on the loss of Flow Records sent to the Collecting 906 Process by an IPFIX Exporting Process. 908 Complete details of the IPFIX protocol are given in IPFIX-PROTO [3]. 910 7.3 Support for Applications 912 Applications that use the information collected by IPFIX may be 913 Billing or Intrusion Detection sub-systems, etc. These applications 914 may be an integral part of the Collecting Process or they may be co- 915 located with the Collecting Process. The way by which these 916 applications interface with IPFIX systems to get the desired 917 information is out of scope for this document. 919 8. Export Models 921 8.1 Export with Reliable Control Connection 923 As mentioned in the IPFIX-REQS [1] document, an IPFIX Device must be 924 able to transport its Control Information and Data Stream over a 925 congestion-aware transport protocol. 927 If the network in which the IPFIX Device and Collecting Process are 928 located does not guarantee reliability, at least the Control 929 Information should be exported over a reliable transport. The Data 930 Stream may be exported over a reliable or unreliable transport 931 protocol. 933 Possible transport protocols include: 935 o SCTP: Supports reliable and unreliable transport. 937 o TCP: Provides reliable transport only. 939 o UDP: Provides unreliable transport only. Network operators would 940 need to avoid congestion by keeping traffic within their own 941 administrative domains. 943 8.2 Collector Failure Detection and Recovery 945 The transport connection (in the case of a connection oriented 946 protocol) is pre-configured between the IPFIX Device and the 947 Collector. The IPFIX protocol does not provide any mechanism for 948 configuring the Exporting and Collecting Processes. 950 Once connected, an IPFIX Collector receives Control Information and 951 uses that information to interpret Flow Records. The IPFIX Device 952 should set a keepalive (e.g. the keepalive timeout in the case of 953 TCP, the HEARTBEAT interval in the case of SCTP) to a sufficiently 954 low value so that it can quickly detect a Collector failure. 956 Collector failure refers to the crash or restart of the Collecting 957 Process, or of the Collector itself. A Collector failure is detected 958 at the IPFIX Device by the break in the connection oriented transport 959 protocol session, depending on the transport protocol - the 960 connection timeout mechanisms differ. On detecting a keepalive 961 timeout in a single Collector scenario, the IPFIX Device should stop 962 sending Flow Records to the Collector and try to reestablish the 963 transport connection. If Collecting Process failover is supported by 964 the Exporting Process, backup session(s) may be opened in advance, 965 and Control Information sent to it. 967 There could be one or more secondary Collectors with priority 968 assigned to them. The primary Collector crash is detected at the 969 IPFIX Device. On detecting loss of connectivity, the IPFIX Device 970 opens a Data Stream with the secondary Collector of the next highest 971 priority. If that secondary was not opened in advance, both the 972 Control Information and Data Stream must be sent to it. That 973 Collector might then become the primary, or the Exporting Process 974 might try to reestablish the original session. 976 8.3 Collector Redundancy 978 Configuring redundant Collectors is an alternative to configuring 979 backup Collectors. In this model, all Collectors simultaneously 980 receive the Control Information and Data Streams. Multiple {Control 981 Information, Data Stream} pairs could be sent, each to a different 982 Collector from the same IPFIX Device. Since the IPFIX protocol 983 requires a congestion-aware transport, achieving redundancy using 984 multicast is not an option. 986 9. IPFIX Flow Collection in Special Situations 988 An IPFIX Device could be doing one or more of generating, receiving, 989 altering special types of traffic which are listed below. 991 Tunnel traffic: 993 The IPFIX Device could be the head, midpoint or endpoint of a 994 tunnel. In such cases the IPFIX Device could be handling GRE, 995 IPinIP or UTI traffic. 997 VPN traffic: 999 The IPFIX Device could be a provider edge device which receives 1000 traffic from customer sites belonging to different Virtual Private 1001 Networks. 1003 Similarly, IPFIX could be implemented on devices which perform one or 1004 more of the following special services: 1006 o Explicitly drop packets. For example a device which provides 1007 firewall service drops packets based on some administrative 1008 policy. 1010 o Alter the values of fields used as IPFIX Flow Keys of interest. 1011 For example a device which provides NAT service can change source 1012 and/or destination IP address. 1014 In cases such as those listed above, there should be clear guidelines 1015 as to: 1017 o How and when to classify the packets as Flows in the IPFIX Device. 1019 o If multiple encapsulations are used to define Flows, how to convey 1020 the same fields (e.g. IP address) in different layers. 1022 o How to differentiate Flows based on different private domains. 1023 For example, overlapping IP addresses in Layer-3 VPNs. 1025 o What extra information needs be exported so that the Collector can 1026 make a clear interpretation of the received Flow Records. 1028 10. Security Considerations 1030 Flow information can be used for various purposes, such as usage 1031 accounting, traffic profiling, traffic engineering, and intrusion 1032 detection. The security requirement may differ significantly for 1033 such applications. To be able to satisfy the security needs of 1034 various IPFIX users, an IPFIX system must provide different levels of 1035 security protection. 1037 10.1 Data Security 1039 IPFIX data comprises Control Information and Data Stream generated by 1040 the IPFIX Device. 1042 The IPFIX data may exist in both the IPFIX Device and the Collector. 1043 In addition, the data is also transferred on the wire from the IPFIX 1044 Device to the Collector when it is exported. To provide security, 1045 the data should be protected from common network attacks. 1047 The protection of IPFIX data within the end system (IPFIX Device and 1048 Collector) is out of scope for this document. It is assumed that the 1049 end system operator will provide adequate security for the IPFIX 1050 data. 1052 The IPFIX architecture must allow different levels of protection to 1053 the IPFIX data on the wire. Wherever security functions are required 1054 it is recommended that users should leverage lower layers using 1055 either IPSEC or TLS, if these can successfully satisfy the security 1056 requirement of IPFIX data protection. 1058 To protect the data on the wire, three levels of granularity should 1059 be supported; these are described in the following subsections. 1061 10.1.1 Host-Based Security 1063 Security may not be required when the transport between the IPFIX 1064 Device and the Collector is perceived as safe. This option allows 1065 the protocol to run most efficiently without extra overhead and an 1066 IPFIX system must support it. 1068 10.1.2 Authentication-only 1070 Authentication-only protection provides IPFIX users with the 1071 assurance of data integrity and authenticity. The data exchanged 1072 between the IPFIX Device and the Collector is protected by an 1073 authentication signature. Any modification of the IPFIX data will be 1074 detected by the recipient, resulting in discarding of the received 1075 data. However, the authentication-only option doesn't offer data 1076 confidentiality. 1078 The IPFIX user should not use authentication-only when sensitive or 1079 confidential information is being exchanged. An IPFIX solution 1080 should support this option. The authentication-only option should 1081 provide replay attack protection. Some means to achieve this level 1082 of security are: 1084 o TCP with MD5 options. 1086 o IP Authentication Header 1088 10.1.3 Encryption 1090 Data encryption provides the best protection for IPFIX data. The 1091 IPFIX data is encrypted at the sender and only the intended recipient 1092 can decrypt and have access to the data. This option must be used 1093 when the transport between the IPFIX Device and the Collector are 1094 unsafe and the IPFIX data needs to be protected. It is recommended 1095 that the underlying transport layer's security functions be used for 1096 this purpose. Some means to achieve this level of security are: 1098 o Encapsulating Security Payload. 1100 o Transport Layer Security Protocol 1102 The data encryption option adds overhead to the IPFIX data transfer. 1103 It may limit the rate that an Exporter can report its Flow Records to 1104 the Collector due to the resource requirement for running encryption. 1106 10.2 IPFIX End-point Authentication 1108 It is important to make sure that the IPFIX Device is talking to the 1109 "right" Collector rather than to a masquerading Collector. The same 1110 logic also holds true from the Collector point of view, i.e. it may 1111 want to make sure it is collecting the Flow Records from the "right" 1112 IPFIX Device. An IPFIX system should allow the end point 1113 authentication capability so that either one-way or mutual 1114 authentication can be performed between the IPFIX Device and 1115 Collector. 1117 The IPFIX architecture should use any existing transport protection 1118 protocols such as TLS or IPSEC to fulfill the authentication 1119 requirement. 1121 11. IPFIX Overload 1123 An IPFIX Device could become overloaded under various conditions. 1124 This may be because of exhaustion of internal resources used for Flow 1125 generation and/or export. Such overloading may cause loss of data 1126 from the Exporting Process, either from lack of export bandwidth 1127 (possibly caused by an unusually high number of observed Flows) or 1128 from network congestion in the path from Exporter to Collector. 1130 IPFIX Collectors should be able to detect the loss of exported Flow 1131 Records, and should at least record the number of lost Flow Records. 1133 11.1 Denial of Service (DoS) Attack Prevention 1135 Since one of the potential usages for IPFIX is for intrusion 1136 detection, it is important for the IPFIX architecture to support some 1137 kind of DoS resistance. 1139 11.1.1 Network Under Attack 1141 The Network itself may be under attack, resulting in an overwhelming 1142 number of IPFIX Messages. An IPFIX system should try to capture as 1143 much information as possible. However, when a large number of IPFIX 1144 Messages are generated in a short period of time, the IPFIX system 1145 may become overloaded. 1147 11.1.2 Generic DoS Attack on the IPFIX Device and Collector 1149 The IPFIX Device and Collector may be subject to generic DoS attacks, 1150 just as any system on any open network. These types of attacks are 1151 not IPFIX specific. Preventing and responding to such types of 1152 attacks are out of the scope of this document. 1154 11.1.3 IPFIX Specific DoS Attack 1156 There are some specific attacks on the IPFIX portion of the IPFIX 1157 Device or Collector: 1159 o The attacker could overwhelm the Collector with spoofed IPFIX 1160 export packets. One way to solve this problem is to periodically 1161 synchronize the sequence numbers of the Flow Records between the 1162 Exporting and Collecting Processes. 1164 o The attacker could provide false reports to the Collector by 1165 sending spoofed packets. 1167 The problems mentioned above can be solved to a large extent if the 1168 control packets are encrypted both ways. 1170 12. IANA Considerations 1172 The IPFIX Architecture, as set out in this document, has two sets of 1173 assigned numbers. Considerations for assigning them are discussed in 1174 this section, using the example policies as set out in the 1175 "Guidelines for IANA Considerations" document IANA-RFC [7]. 1177 12.1 Numbers used in the Protocol 1179 IPFIX Messages, as described in IPFIX-PROTO [3], use two fields with 1180 assigned values. These are the IPFIX Version Number, indicating 1181 which version of the IPFIX Protocol was used to export an IPFIX 1182 Message, and the IPFIX Template Number, indicating the type for each 1183 set of information within an IPFIX message. 1185 Changes in either IPFIX Version Number or IPFIX Template Number 1186 assignments require an IETF Consensus, i.e. they are to be made via 1187 RFCs approved by the IESG. 1189 12.2 Numbers used in the Information Model 1191 Fields of the IPFIX protocol carry information about traffic 1192 measurement. They are modeled as elements of the IPFIX information 1193 model IPFIX-INFO [2]. Each Information Element describes a field 1194 which may appear in an IPFIX Message. Within an IPFIX message the 1195 field type is indicated by its Field Type. 1197 Changes in IPFIX Field Type will be administered by IANA, subject to 1198 Expert Review, i.e. review by one of a group of experts designated by 1199 an IETF Operations and Management Area Director. Those experts will 1200 initially be drawn from the Working Group Chairs and document editors 1201 of the IPFIX and PSAMP Working Groups. 1203 13. 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 Special thanks to Dave Plonka for the multiple thorough reviews. 1226 14. References 1228 14.1 Normative References 1230 [1] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements 1231 for IP Flow Information Export", RFC RFC 3917, October 2004. 1233 [2] Meyer, J., Quittek, J., and S. Bryant, "IPFIX: Information 1234 Model", (work in progress), Internet Draft, 1235 draft-ietf-ipfix-info-08.txt, October 2004. 1237 [3] Claise, B., Bryant, S., Sadasivan, G., and M. Fullmer, "IPFIX: 1238 Protocol", (work in progress), Internet Draft, 1239 draft-ietf-ipfix-protocol-10.txt, December 2004. 1241 [4] Zseby, T., Boschi, E., Penno, R., Brownlee, N., and B. Claise, 1242 "IPFIX: Protocol", (work in progress), Internet Draft, 1243 draft-ietf-ipfix-as-05.txt, October 2004. 1245 14.2 Informative References 1247 [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1248 "RTP: A Transport Protocol for Real-Time Applications", 1249 RFC 1889, January 1996. 1251 [6] Leinen, S., "Evaluation of Candidate Protocols for IP Flow 1252 Information Export", RFC 3955, October 2004. 1254 [7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1255 Considerations Section in RFCs", RFC 2434, October 1998. 1257 Authors' Addresses 1259 Ganesh Sadasivan 1260 Cisco Systems, Inc. 1261 170 West Tasman Drive 1262 San Jose, CA 95134 1263 USA 1265 Phone: +1 408 527-0251 1266 Email: gsadasiv@cisco.com 1267 Nevil Brownlee 1268 CAIDA | The University of Auckland 1269 Private Bag 92019 1270 Auckland 1271 New Zealand 1273 Phone: +64 9 373 7599 x8941 1274 Email: n.brownlee@auckland.ac.nz 1276 Benoit Claise 1277 Cisco Systems, Inc. 1278 De Kleetlaan 6a b1 1279 1831 Diegem 1280 Belgium 1282 Phone: +32 2 704 5622 1283 Email: bclaise@cisco.com 1285 Juergen Quittek 1286 NEC Europe Ltd. 1287 Adenauerplatz 6 1288 69225 Heidelberg 1289 Germany 1291 Phone: +49 6221 90511-15 1292 Email: quittek@ccrle.nec.de 1294 Appendix A. Changes/Issues from the -08 Draft 1296 Editorial Improvements: 1298 Added this sentence from RFC 3917 (IPFIX Requirements): All 1299 measurements must be conducted from the point of view of the 1300 observation point. 1302 Intellectual Property Statement 1304 The IETF takes no position regarding the validity or scope of any 1305 Intellectual Property Rights or other rights that might be claimed to 1306 pertain to the implementation or use of the technology described in 1307 this document or the extent to which any license under such rights 1308 might or might not be available; nor does it represent that it has 1309 made any independent effort to identify any such rights. Information 1310 on the procedures with respect to rights in RFC documents can be 1311 found in BCP 78 and BCP 79. 1313 Copies of IPR disclosures made to the IETF Secretariat and any 1314 assurances of licenses to be made available, or the result of an 1315 attempt made to obtain a general license or permission for the use of 1316 such proprietary rights by implementers or users of this 1317 specification can be obtained from the IETF on-line IPR repository at 1318 http://www.ietf.org/ipr. 1320 The IETF invites any interested party to bring to its attention any 1321 copyrights, patents or patent applications, or other proprietary 1322 rights that may cover technology that may be required to implement 1323 this standard. Please address the information to the IETF at 1324 ietf-ipr@ietf.org. 1326 The IETF has been notified of intellectual property rights claimed in 1327 regard to some or all of the specification contained in this 1328 document. For more information consult the online list of claimed 1329 rights. 1331 Disclaimer of Validity 1333 This document and the information contained herein are provided on an 1334 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1335 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1336 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1337 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1338 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1339 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1341 Copyright Statement 1343 Copyright (C) The Internet Society (2005). This document is subject 1344 to the rights, licenses and restrictions contained in BCP 78, and 1345 except as set forth therein, the authors retain all their rights. 1347 Acknowledgment 1349 Funding for the RFC Editor function is currently provided by the 1350 Internet Society.