idnits 2.17.1 draft-ietf-ipfix-architecture-10.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 1346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1336. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 6, 2006) is 6594 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3917 (ref. '1') == Outdated reference: A later version (-15) exists of draft-ietf-ipfix-info-08 == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-10 == Outdated reference: A later version (-12) exists of draft-ietf-ipfix-as-05 ** Downref: Normative reference to an Informational draft: draft-ietf-ipfix-as (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '5') (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '7') (Obsoleted by RFC 5226) Summary: 5 errors (**), 0 flaws (~~), 5 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: October 8, 2006 CAIDA | The University of Auckland 6 B. Claise 7 Cisco Systems, Inc. 8 J. Quittek 9 NEC Europe Ltd. 10 April 6, 2006 12 Architecture for IP Flow Information Export 13 draft-ietf-ipfix-architecture-10 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 October 8, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This memo defines the IP Flow Information eXport (IPFIX) architecture 47 for the selective monitoring of IP flows, and for the export of 48 measured IP flow information from an IPFIX device to a collector. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . . 4 54 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Examples of Flows . . . . . . . . . . . . . . . . . . . . . . 8 57 4. IPFIX Reference Model . . . . . . . . . . . . . . . . . . . . 10 58 5. IPFIX Functional and Logical Blocks . . . . . . . . . . . . . 11 59 5.1. Metering Process . . . . . . . . . . . . . . . . . . . . . 11 60 5.1.1. Flow Expiration . . . . . . . . . . . . . . . . . . . 12 61 5.1.2. Flow Export . . . . . . . . . . . . . . . . . . . . . 12 62 5.2. Observation Point . . . . . . . . . . . . . . . . . . . . 13 63 5.3. Selection Criteria for Packets . . . . . . . . . . . . . . 13 64 5.3.1. Sampling Functions, Si . . . . . . . . . . . . . . . . 14 65 5.3.2. Filter Functions, Fi . . . . . . . . . . . . . . . . . 14 66 5.4. Observation Domain . . . . . . . . . . . . . . . . . . . . 14 67 5.5. Exporting Process . . . . . . . . . . . . . . . . . . . . 14 68 5.6. Collecting Process . . . . . . . . . . . . . . . . . . . . 15 69 5.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 6. Overview of the IPFIX Protocol . . . . . . . . . . . . . . . . 17 71 6.1. Information Model Overview . . . . . . . . . . . . . . . . 17 72 6.2. Flow Records . . . . . . . . . . . . . . . . . . . . . . . 18 73 6.3. Control Information . . . . . . . . . . . . . . . . . . . 18 74 6.4. Reporting Responsibilities . . . . . . . . . . . . . . . . 19 75 7. IPFIX Protocol Details . . . . . . . . . . . . . . . . . . . . 20 76 7.1. The IPFIX Basis Protocol . . . . . . . . . . . . . . . . . 20 77 7.2. IPFIX Protocol on the Collecting Process . . . . . . . . . 20 78 7.3. Support for Applications . . . . . . . . . . . . . . . . . 21 79 8. Export Models . . . . . . . . . . . . . . . . . . . . . . . . 21 80 8.1. Export with Reliable Control Connection . . . . . . . . . 21 81 8.2. Collector Failure Detection and Recovery . . . . . . . . . 21 82 8.3. Collector Redundancy . . . . . . . . . . . . . . . . . . . 22 83 9. IPFIX Flow Collection in Special Situations . . . . . . . . . 22 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 85 10.1. Data Security . . . . . . . . . . . . . . . . . . . . . . 23 86 10.1.1. Host-Based Security . . . . . . . . . . . . . . . . . 24 87 10.1.2. Authentication-only . . . . . . . . . . . . . . . . . 24 88 10.1.3. Encryption . . . . . . . . . . . . . . . . . . . . . . 24 89 10.2. IPFIX End-point Authentication . . . . . . . . . . . . . . 25 90 10.3. IPFIX Overload . . . . . . . . . . . . . . . . . . . . . . 25 91 10.3.1. Denial of Service (DoS) Attack Prevention . . . . . . 25 92 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 93 11.1. Numbers used in the Protocol . . . . . . . . . . . . . . . 26 94 11.2. Numbers used in the Information Model . . . . . . . . . . 27 95 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 96 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 97 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 98 13.2. Informative References . . . . . . . . . . . . . . . . . . 28 99 Appendix A. Changes/Issues from the -09 Draft . . . . . . . . . . 28 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 101 Intellectual Property and Copyright Statements . . . . . . . . . . 31 103 1. Introduction 105 There are several applications e.g., usage-based accounting, traffic 106 profiling, traffic engineering, attack/intrusion detection, QoS 107 monitoring, that require flow-based IP traffic measurements. It is 108 therefore important to have a standard way of exporting information 109 related to IP flows. This document defines an architecture for IP 110 traffic flow monitoring, measuring and exporting. It provides a 111 high-level description of an IPFIX device's key components and their 112 functions. 114 1.1. Document Scope 116 This document defines the architecture for IPFIX. Its main 117 objectives are to: 119 o Describe the key IPFIX architectural components, consisting of (at 120 least) IPFIX devices and collectors communicating using the IPFIX 121 protocol. 123 o Define the IPFIX architectural requirements, e.g., recovery, 124 security, etc. 126 o Describe the characteristics of the IPFIX protocol. 128 1.2. IPFIX Documents Overview 130 The IPFIX protocol provides network administrators with access to IP 131 flow information. This document specifies the architecture for the 132 export of measured IP flow information from an IPFIX exporting 133 process to a collecting process, per the requirements defined in 134 IPFIX-REQS [1]. The IPFIX protocol document IPFIX-PROTO [3] 135 specifies how IPFIX data records and templates are carried via a 136 congestion-aware transport protocol from IPFIX exporting process to 137 IPFIX collecting process. IPFIX has a formal description of IPFIX 138 information elements (fields), their name, type and additional 139 semantic information, as specified in IPFIX-INFO [2]. Finally 140 IPFIX-AS [4] describes what type of applications can use the IPFIX 141 protocol and how they can use the information provided. It 142 furthermore shows how the IPFIX framework relates to other 143 architectures and frameworks. 145 Note that the IPFIX system does not provide for remote configuration 146 of an IPFIX device. Instead, implementors must provide an effective 147 way to configure their IPFIX devices. 149 2. Terminology 151 The definitions of basic IPFIX terms such as IP Traffic Flow, 152 Exporting Process, Collecting Process, Observation Point, etc. are 153 semantically identical with those found in the IPFIX requirements 154 document IPFIX-REQS [1]. Some of the terms have been expanded for 155 more clarity when defining the protocol. Additional definitions 156 required for the architecture have also been defined. For the same 157 terms defined here and in IPFIX-PROTO [3] the definitions are 158 equivalent in both documents. 160 * Observation Point 162 An Observation Point is a location in the network where IP packets 163 can be observed. Examples include: a line to which a probe is 164 attached, a shared medium, such as an Ethernet-based LAN, a single 165 port of a router, or a set of interfaces (physical or logical) of 166 a router. 168 Note that every Observation Point is associated with an 169 Observation Domain (defined below), and that one Observation Point 170 may be a superset of several other Observation Points. For 171 example one Observation Point can be an entire line card. That 172 would be the superset of the individual Observation Points at the 173 line card's interfaces. 175 * Observation Domain 177 An Observation Domain is the largest set of Observation Points for 178 which Flow information can be aggregated by a Metering Process. 179 For example, a router line card may be an observation domain if it 180 is composed of several interfaces, each of which is an Observation 181 Point. Each Observation Domain presents itself to the Collecting 182 Process using an Observation Domain ID to identify the IPFIX 183 Messages it generates. Observation Domain IDs are unique per 184 Exporting Process. 186 * IP Traffic Flow or Flow 188 There are several definitions of the term 'flow' being used by the 189 Internet community. Within the context of IPFIX we use the 190 following definition: 192 A Flow is defined as a set of IP packets passing an Observation 193 Point in the network during a certain time interval. All packets 194 belonging to a particular Flow have a set of common properties. 195 Each property is defined as the result of applying a function to 196 the values of: 198 1. One or more packet header fields (e.g. destination IP 199 address), transport header fields (e.g. destination port 200 number), or application header field (e.g. RTP header fields) 201 RTP-HDRF [5]. 203 2. One or more characteristics of the packet itself (e.g. number 204 of MPLS labels) 206 3. One or more fields derived from packet treatment (e.g. next 207 hop IP address, output interface) 209 A packet is said to belong to a Flow if it completely satisfies 210 all the defined properties of the Flow. 212 This definition covers the range from a Flow containing all 213 packets observed at a network interface to a Flow consisting of 214 just a single packet between two applications. It includes 215 packets selected by a sampling mechanism. 217 * Flow Key 219 Each of the fields which 221 1. Belong to the packet header (e.g. destination IP address) 223 2. Are a property of the packet itself (e.g. packet length) 225 3. Are derived from packet treatment (e.g. AS number) 227 and which are used to define a Flow are termed Flow Keys. 229 * Flow Record 231 A Flow Record contains information about a specific Flow that was 232 observed at an Observation Point. A Flow Record contains measured 233 properties of the Flow (e.g. the total number of bytes for all the 234 Flow's packets) and usually characteristic properties of the Flow 235 (e.g. source IP address). 237 * Metering Process 239 The Metering Process generates Flow Records. Inputs to the 240 process are packet headers and characteristics observed at an 241 Observation Point, and packet treatment at the Observation Point 242 (for example the selected output interface). All measurements 243 must be conducted from the point of view of the observation point. 245 The Metering Process consists of a set of functions that includes 246 packet header capturing, timestamping, sampling, classifying, and 247 maintaining Flow Records. 249 The maintenance of Flow Records may include creating new records, 250 updating existing ones, computing Flow statistics, deriving 251 further Flow properties, detecting Flow expiration, passing Flow 252 Records to the Exporting Process, and deleting Flow Records. 254 * Exporting Process 256 An Exporting Process sends Flow Records to one or more Collecting 257 Processes. The Flow Records are generated by one or more Metering 258 Processes. 260 * Exporter 262 A device which hosts one or more Exporting Processes is termed an 263 Exporter. 265 * IPFIX Device 267 An IPFIX Device hosts at least one Observation Point, a Metering 268 Process and an Exporting Process. 270 * Collecting Process 272 A Collecting Process receives Flow Records from one or more 273 Exporting Processes. The Collecting Process might process or 274 store received Flow Records, but such actions are out of scope for 275 this document. 277 * Collector 279 A device which hosts one or more Collecting Processes is termed a 280 Collector. 282 * Template 284 A Template is an ordered sequence of pairs, used to 285 completely specify the structure and semantics of a particular set 286 of information that needs to be communicated from an IPFIX Device 287 to a Collector. Each Template is uniquely identifiable by means 288 of a Template ID. 290 * Control Information, Data Stream 292 The information that needs to be exported from the IPFIX Device 293 can be classified into the following categories: 295 Control Information 297 This includes the Flow definition, selection criteria for 298 packets within the Flow sent by the Exporting Process, and 299 templates describing the data to be exported. Control 300 Information carries all the information needed for the end- 301 points to understand the IPFIX protocol, and specifically for 302 the Collector to understand and interpret the data sent by the 303 sending Exporter. 305 Data Stream 307 This includes Flow Records carrying the field values for the 308 various observed Flows at each of the Observation Points. 310 IPFIX Message 312 An IPFIX Message is a message originating at the Exporting Process 313 that carries the IPFIX records of this Exporting Process and whose 314 destination is a Collecting Process. An IPFIX Message is 315 encapsulated at the transport layer. 317 Information Element 319 An Information Element is a protocol and encoding independent 320 description of an attribute which may appear in an IPFIX Record. 321 The IPFIX information model IPFIX-INFO [2] defines the base set of 322 Information Elements for IPFIX. The type associated with an 323 Information Element indicates constraints on what it may contain 324 and also determines the valid encoding mechanisms for use in 325 IPFIX. 327 3. Examples of Flows 329 Some examples of Flows are listed below: 331 Example 1: The Flow Keys define the different fields by which Flows 332 are distinguished. The different combination of the field values 333 creates unique Flows. If {source IP address, destination IP address, 334 DSCP} are flow keys, then all of these are different Flows: 336 1. {192.0.2.1, 192.0.2.65, 4} 337 2. {192.0.2.23, 192.0.2.67, 4} 338 3. {192.0.2.23, 192.0.2.67, 2} 339 4. {192.0.2.129, 192.0.2.67, 4} 341 Example 2: A mask function can be applied to all the packets that 342 pass through an Observation Point, in order to aggregate some values. 343 This could be done by defining the set of Flow Keys as {source IP 344 address, destination IP address, DSCP} as in example 1 above, and 345 applying a function which masks out the least significant 6 bits of 346 the source IP address and destination IP address (i.e. the result is 347 a /26 address). The four Flows from example 1 would now be 348 aggregated into three Flows by merging the Flows 1 and 2 into a 349 single Flow: 351 1. {192.0.2.0/26, 192.0.2.64/26, 4} 352 2. {192.0.2.0/26, 192.0.2.64/26, 2} 353 3. {192.0.2.128/26, 192.0.2.64/26, 4} 355 Example 3: A filter defined by some Flow Key values can be applied on 356 all packets that pass the Observation Point, in order to select only 357 certain Flows. The filter is defined by choosing fixed values for 358 specific Keys from the packet. 360 All the packets that go from a customer network 192.0.2.0/26 to 361 another customer network 192.0.2.64/26 with DSCP value of 4 define a 362 Flow. All other combinations don't define a Flow and are not taken 363 into account. The three Flows from example 2 would now be reduced to 364 one Flow by filtering away the second and the third Flow, leaving 365 only {192.0.2.0/26, 192.0.2.64/26, 4}. 367 The above examples can be thought of as a function F() taking as 368 input {source IP address, destination IP address, DSCP}. The 369 function selects only the packets which satisfy all three of the 370 following conditions: 372 1. Mask out the least significant 6 bits of source IP address, match 373 against 192.0.2.0. 375 2. Mask out the least significant 6 bits of destination IP address, 376 match against 192.0.2.64. 378 3. Only accept DSCP value equal to 4. 380 Depending on the values of {source IP address, destination IP 381 address, DSCP} of the different observed packets, the Metering 382 Process function F() would choose/filter/aggregate different sets of 383 packets, which would create different Flows. For example, for 384 various combinations of values of {source IP address, destination IP 385 address, DSCP}, F(source IP address, destination IP address, DSCP) 386 would result in the definition of one or more Flows. 388 4. IPFIX Reference Model 390 The figure below shows the reference model for IPFIX. This figure 391 covers the various possible scenarios that can exist in an IPFIX 392 system. 394 +----------------+ +----------------+ 395 |[*Application 1]| ... |[*Application n]| 396 +--------+-------+ +-------+--------+ 397 ^ ^ 398 | | 399 + = = = = -+- = = = = + 400 ^ 401 | 402 +------------------------+ +-------+------------------+ 403 |IPFIX Exporter | | Collector(1) | 404 |[Exporting Process(es)] |<---------->| [Collecting Process(es)] | 405 +------------------------+ +--------------------------+ 406 .... .... 407 +------------------------+ +---------------------------+ 408 |IPFIX Device(i) | | Collector(j) | 409 |[Observation Point(s)] |<--------->| [Collecting Process(es)] | 410 |[Metering Process(es)] | +---->| [*Application(s)] | 411 |[Exporting Process(es)] | | +---------------------------+ 412 +------------------------+ . 413 .... . .... 414 +------------------------+ | +--------------------------+ 415 |IPFIX Device(m) | | | Collector(n) | 416 |[Observation Point(s)] |<----+---->| [Collecting Process(es)] | 417 |[Metering Process(es)] | | [*Application(s)] | 418 |[Exporting Process(es)] | +--------------------------+ 419 +------------------------+ 421 The various functional components are indicated within brackets []. 422 The functional components within [*] are not part of the IPFIX 423 architecture. The interfaces shown by "<----->" are defined by the 424 IPFIX architecture but those shown by "<= = = =>" are not. 426 Figure 3 427 The figure below shows a typical IPFIX Device where the IPFIX 428 components are shown in rectangular boxes. 430 +-------------------------------------------------+ 431 | IPFIX Device | 432 | +-----+ | 433 | +---......--+-----------+---------> | | 434 | | | | | | 435 | +----+----+ +----+----+ | | | 436 | |Metering | |Metering | | E | | 437 | |Process 1| |Process N| | x | | 438 | +---------+ +---------+ | p | | 439 | ^ ^ | o | | 440 | +------+----------------------+-------+ | r | | 441 | | | Observation Domain 1 | | | t | | 442 | |+-----+------+ +-----+------+| | i | | 443 | ||Obsv Point 1| ... |Obsv Point M|| | n | | 444 | |+------------+ +------------+| | g | | Export 445 Packets | +------^------------------------^-----+ | | | packets 446 --->----+--------+----------.....---------+ | | | to 447 In | | +---------> 448 | . . . . . | | |Collector 449 | | | | 450 | +---......--+-----------+---------> | | 451 | | | | | | 452 | +----+----+ +----+----+ | P | | 453 | |Metering | |Metering | | r | | 454 | |Process 1| |Process N| | o | | 455 | +---------+ +---------+ | c | | 456 | ^ ^ | e | | 457 | +------+----------------------+-------+ | s | | 458 | | | Observation Domain K | | | s | | 459 | |+-----+------+ +-----+------+| | | | 460 | ||Obsv Point 1| ... |Obsv Point M|| | | | 461 | |+------------+ +------------+| | | | 462 Packets | +------^------------------------^-----+ +-----+ | 463 --->----+--------+---------- ... ---------+ | 464 In | | 465 +-------------------------------------------------+ 467 Figure 4 469 5. IPFIX Functional and Logical Blocks 471 5.1. Metering Process 473 Every Observation Point in an IPFIX Device, participating in Flow 474 measurements, must be associated with at least one Metering Process. 475 Every packet coming into an Observation Point goes into each of the 476 Metering Processes associated with the Observation Point. Broadly, 477 each Metering Process observes the packets that pass an Observation 478 Point, does timestamping and classifies the packets into Flow(s) 479 based on the selection criteria. 481 The Metering Process is a functional block which manages all the 482 Flows generated from an Observation Domain. The typical functions of 483 a Metering Process may include: 485 o Maintain database(s) of all the Flow Records from an Observation 486 Domain. This includes creating new Flow Records, updating 487 existing ones, computing Flow Records statistics, deriving further 488 Flow properties, adding non-flow-specific information based on the 489 packet treatment (in some cases fields like AS numbers, router 490 state, etc.) 492 o Maintain statistics about the Metering Process itself, such as 493 Flow Records generated, packets observed, etc. 495 5.1.1. Flow Expiration 497 A Flow is considered to have expired under the following conditions: 499 1. If no packets belonging to the Flow have been observed for a 500 certain period of time. This time period should be configurable 501 at the Metering Process, with a minimum value of 0 seconds for 502 immediate expiration. Note that a zero timeout would report a 503 Flow as a sequence of single-packet Flows. 505 2. If the IPFIX Device experiences resource constraints, a Flow may 506 be prematurely expired (e.g. lack of memory to store Flow 507 Records) 509 3. For long-running Flows, the Metering Process should expire the 510 Flow on a regular basis or based on some expiration policy. This 511 periodicity or expiration policy should be configurable at the 512 Metering Process. When a long-running Flow is expired, its Flow 513 Record may still be maintained by the Metering Process so that 514 the Metering Process does not need to create a new Flow Record 515 for further observed packets of the same Flow. 517 5.1.2. Flow Export 519 The Exporting Process decides when and whether to export an expired 520 Flow. A Flow can be exported because it expired for any of the 521 reasons mentioned in Flow Expiration section. For example: the 522 Exporting Process exports a portion of the expired Flows every 'x' 523 seconds. 525 For long-lasting Flows, the Exporting Process should export the Flow 526 Records on a regular basis or based on some export policy. This 527 periodicity or export policy should be configurable at the Exporting 528 Process. 530 5.2. Observation Point 532 A Flow Record can be better analysed if the Observation Point from 533 which it was measured is known. As such it is recommended that IPFIX 534 Devices send this information to Collectors. In cases where there is 535 a single Observation Point or where the Observation Point information 536 is not relevant, the Metering Process may choose not to add the 537 Observation Point information to the Flow Records. 539 5.3. Selection Criteria for Packets 541 A Metering Process may define rules so that only certain packets 542 within an incoming stream of packets are chosen for measurement at an 543 Observation Point. This may be done by one of the two methods 544 defined below or a combination of them, in either order. A 545 combination of each of these methods can be adopted to select the 546 packets, i.e. one can define a set of methods {F1, S1, F2, S2, S3} 547 executed in a specified sequence at an Observation Point to select 548 particular Flows. 550 The figure below shows the operations which may be applied as part of 551 a typical Metering Process. 553 packet header capturing 554 | 555 timestamping 556 | 557 v 558 +----->+ 559 | | 560 | sampling Si (1:1 in case of no sampling) 561 | | 562 | filtering Fi (select all when no criteria) 563 | | 564 +------+ 565 | 566 v 567 Flows 569 Figure 5 571 5.3.1. Sampling Functions, Si 573 A sampling function determines which packets within a stream of 574 incoming packets are selected for measurement, i.e. packets that 575 satisfy the sampling criteria for this Metering Process. 577 Example: sample every 100th packet that was received at an 578 Observation Point. 580 Choosing all the packets is a special case where the sampling rate is 581 1:1. 583 5.3.2. Filter Functions, Fi 585 A Filter Function selects only those incoming packets that satisfy a 586 function on fields defined by the packet header fields, fields 587 obtained while doing the packet processing, or properties of the 588 packet itself. 590 Example: Mask/Match of the fields that define a filter. A filter 591 might be defined as {Protocol == TCP, Destination Port between 80 and 592 120}. 594 Several such filters could be used in any sequence to select packets. 595 Note that packets selected by a (sequence of) filter functions may be 596 further classified by other filter functions, i.e. the selected 597 packets may belong to several Flows, any or all of which are 598 exported. 600 5.4. Observation Domain 602 The Observation Domain is a logical block that presents a single 603 identity for a group of Observation Points within an IPFIX Device. 604 Each {Observation Point, Metering Process} pair belongs to a single 605 Observation Domain. An IPFIX Device could have multiple Observation 606 Domains, each of which has a subset of the total set of Observation 607 Points in it. Each Observation Domain must carry a unique ID within 608 the context of an IPFIX Device. Note that in case of multiple 609 Observation Domains, a unique ID per Observation Domain must be 610 transmitted as a parameter to the Exporting Function. That unique ID 611 is referred to as the IPFIX Observation Domain ID. 613 5.5. Exporting Process 615 The Exporting Process is the functional block that sends data to one 616 or more IPFIX Collectors using the IPFIX protocol. On one side the 617 Exporting Process interfaces with Metering Process(es) to get Flow 618 Records, while on the other side it talks to a Collecting Process on 619 the Collector(s). 621 There may be additional rules defined within an Observation Domain so 622 that only certain Flow Records are exported. This may be done by 623 either one or a combination of Si, Fi, as described in the section on 624 "Selection Criteria for Packets". 626 Example: Only the Flow Records which meet the following selection 627 criteria are exported: 629 1. All Flow Records whose destination IP address matches 630 {192.0.33.5}. 632 2. Every other (i.e. sampling rate 1 in 2) Flow Record whose 633 destination IP address matches {192.0.11.30}. 635 5.6. Collecting Process 637 Collecting Processes use a Flow Record's Template ID to interpret 638 that Flow Record's Information Elements. To allow this, an IPFIX 639 Exporter must ensure that an IPFIX Collector knows the Template ID 640 for each incoming Flow Record. To interpret incoming Flow Records, 641 an IPFIX Collector may also need to know the function F() that was 642 used by the Metering Process for each Flow. 644 The functions of the Collecting Process must include: 646 o Identifying, accepting and decoding the IPFIX Messages from 647 different pairs. 649 o Storing the Control Information and Flow Records received from an 650 IPFIX Device. 652 At a high level, the Collecting Process: 654 1. Receives and stores the Control Information. 656 2. Decodes and stores the Flow Records using the Control 657 Information. 659 5.7. Summary 661 The figure below shows the functions performed in sequence by the 662 various functional blocks in an IPFIX Device. 664 Packet(s) coming in to Observation Point(s) 665 | | 666 v v 668 +----------------+-------------------------+ +-----+-------+ 669 | Metering Process on an | | | 670 | Observation Point | | | 671 | | | | 672 | packet header capturing | | | 673 | | |...| Metering | 674 | timestamping | | Process N | 675 | | | | | 676 | +----->+ | | | 677 | | | | | | 678 | | sampling Si (1:1 in case of no | | | 679 | | | sampling) | | | 680 | | classifying Fi (select all when | | | 681 | | | no criteria) | | | 682 | +------+ | | | 683 | | | | | 684 | | Timing out Flows | | | 685 | | Handle resource overloads | | | 686 +--------|---------------------------------+ +-----|-------+ 687 | | 688 Flow Records (identified by Observation Domain) Flow Records 689 | | 690 +---------+---------------------------------+ 691 | 692 +--------------------|----------------------------------------------+ 693 | | Exporting Process | 694 |+-------------------|-------------------------------------------+ | 695 || v IPFIX Protocol | | 696 ||+-----------------------------+ +----------------------------+| | 697 |||Rules for | |Functions || | 698 ||| Picking/sending Templates | |-Packetise selected Control || | 699 ||| Picking/sending Flow Records|->| & data Information into || | 700 ||| Encoding Template & data | | IPFIX export packets. || | 701 ||| Selecting Flows to export(*)| |-Handle export errors || | 702 ||+-----------------------------+ +----------------------------+| | 703 |+----------------------------+----------------------------------+ | 704 | | | 705 | exported IPFIX Messages | 706 | | | 707 | +------------+-----------------+ | 708 | | Anonymise export packet(*) | | 709 | +------------+-----------------+ | 710 | | | 711 | +------------+-----------------+ | 712 | | Transport Protocol | | 713 | +------------+-----------------+ | 714 | | | 715 +-----------------------------+-------------------------------------+ 716 | 717 v 718 IPFIX export packet to Collector 720 (*) indicates that the block is optional. 722 Figure 6 724 6. Overview of the IPFIX Protocol 726 An IPFIX Device consists of a set of co-operating processes that 727 implement the functional blocks described in the previous section. 728 Alternatively, an IPFIX Device can be viewed simply as a network 729 entity which implements the IPFIX protocol. At the IPFIX Device, the 730 protocol functionality resides in the Exporting Process. The IPFIX 731 Exporting Process gets Flow Records from a Metering Process, and 732 sends them to the Collector(s). 734 At a high level, an IPFIX Device performs the following tasks: 736 1. Encode Control Information into Templates. 738 2. Encode packets observed at the Observation Points into Flow 739 Records. 741 3. Packetise the selected Templates and Flow Records into IPFIX 742 Messages. 744 4. Send IPFIX Messages to the Collector. 746 The IPFIX protocol communicates information from an IPFIX Exporter to 747 an IPFIX Collector. That information includes not only Flow Records, 748 but also information about the Metering Process. Such information 749 (referred to as Control Information) includes details of the data 750 fields in Flow Records. It may also include statistics from the 751 Metering Process, such as the number of packets lost (i.e. not 752 metered). 754 For details of the IPFIX protocol please refer to IPFIX-PROTO [3]. 756 6.1. Information Model Overview 758 The IP Flow Information eXport (IPFIX) protocol serves for 759 transmitting information related to measured IP traffic over the 760 Internet. The protocol specification in IPFIX-PROTO [3] defines how 761 Information Elements are transmitted. For Information Elements, it 762 specifies the encoding of a set of basic data types. However, the 763 list of fields that can be transmitted by the protocol, such as Flow 764 attributes (source IP address, number of packets, etc.) and 765 information about the Metering and Exporting Process (packet 766 Observation Point, sampling rate, Flow timeout interval, etc.), is 767 not specified in IPFIX-PROTO [3]. Instead, it is defined in the 768 IPFIX Information Model document IPFIX-INFO [2]. 770 The Information Model provides a complete description of the 771 properties of every IPFIX Information Element. It does this by 772 specifying each element's name, Field Type, data type, etc., and 773 providing a description of each element. Element descriptions give 774 the semantics of the element, i.e. say how it is derived from a Flow 775 or other information available within an IPFIX Device. 777 6.2. Flow Records 779 The following rules provide guidelines to be followed while encoding 780 the Flow Records information: 782 A Flow Record contains enough information so that the Collecting 783 Process can identify the corresponding . 786 The Exporting Process encodes a given Information Element (as 787 specified in IPFIX-INFO [2]), based on the encoding standards 788 prescribed by IPFIX-PROTO [3]. 790 6.3. Control Information 792 The following rules provide guidelines to be followed while encoding 793 the Control Information: 795 o Per-Flow Control Information should be encoded such that the 796 Collecting Process can capture the structure and semantics of the 797 corresponding Flow data for each of the Flow Records exported by 798 the IPFIX Device. 800 o Configuration Control Information is conveyed to a Collector so 801 that its Collecting Process can capture the structure and 802 semantics of the corresponding configuration data. The 803 configuration data which is also Control Information should carry 804 additional information on the Observation Domain within which the 805 configuration takes effect. 807 For example, sampling using the same sampling algorithm, say 1 in 100 808 packets, is configured on two Observation Points O1 and O2. The 809 configuration in this case may be encoded as {ID, configuration 810 domain (O1,O2), sampling algorithm, interval (1 in 100)}, where ID is 811 the Observation Domain ID for the domain containing O1 and O2. The 812 Observation Domain ID uniquely identifies this configuration, and 813 must be sent within the Flow Records in order to be able to match the 814 right configuration control information. 816 The Control Information is used by the Collecting Process to: 818 o Decode and interpret Flow Records. 820 o Understand the state of the Exporting Process. 822 Sending Control Information from the Exporting Process in a timely 823 and reliable manner is critical to the proper functioning of the 824 IPFIX Collecting Process. The following approaches may be taken for 825 the export of Control Information: 827 1. Send all the Control Information pertaining to Flow Records prior 828 to sending the Flow Records themselves. This includes any 829 incremental changes to the definition of the Flow Records. 831 2. Notify on a near real time basis the state of the IPFIX Device to 832 the Collecting Process. This includes all changes such as a 833 configuration change that affects the Flow behaviour, changes to 834 Exporting Process resources that alter export rates, etc., which 835 the Collector needs to be aware of. 837 3. Since it is vital that a Collecting Process maintains accurate 838 knowledge of the Exporter's state, the export of the Control 839 Information should be done such that it reaches the Collector 840 reliably. One way to achieve this is to send the Control 841 Information over a reliable transport. 843 6.4. Reporting Responsibilities 845 From time to time an IPFIX Device may not be able to observe all the 846 packets reaching one of its Observation Points. This could occur if 847 a Metering Process finds itself temporarily short of resources. For 848 example it might run out of packet buffers for IPFIX export, or it 849 might detect errors in its underlying transport layer. 851 In such situations, the IPFIX Device should attempt to count the 852 number of packet losses that have occurred, and report them to its 853 Collector(s). If it is not possible to count losses accurately, e.g. 854 when transport layer errors are detected, the IPFIX device should 855 report this fact, and perhaps indicate the time period during which 856 some packets might not have been observed. 858 7. IPFIX Protocol Details 860 When the IPFIX Working Group was chartered there were existing common 861 practices in the area of Flow export, for example NetFlow, CRANE, 862 LFAP, RTFM, etc. IPFIX's charter required the Working Group to 863 consider those existing practices, and select the one that was the 864 closest fit to the IPFIX requirements IPFIX-REQS [1]. Additions or 865 modifications would then be made to the selected protocol to fit it 866 exactly into the IPFIX architecture. 868 7.1. The IPFIX Basis Protocol 870 The Working Group went through an extensive evaluation of the various 871 existing protocols that were available, weighing the level of 872 compliance with the requirements, and selected one of the candidates 873 as the basis for the IPFIX protocol. For more details of the 874 evaluation process please see IPFIX-EVAL [6]. 876 In the basis protocol Flow Records are defined by Templates, where a 877 Template is an ordered set of the Information Elements appearing in a 878 Flow Record, together with their field sizes within those records. 880 This approach provides the following advantages: 882 o Using the Template mechanism, new fields can be added to IPFIX 883 Flow Records without changing the structure of the export record 884 format. 886 o Templates that are sent to the Collecting Process carry structural 887 information about the exported Flow Record fields. Therefore, if 888 the Collector does not understand the semantics of new fields it 889 can ignore them, but still interpret the Flow Record. 891 o Because the template mechanism is flexible, it allows the export 892 of only the required fields from the Flows to the Collecting 893 Process. This helps to reduce the exported Flow data volume and 894 possibly provide memory savings at the Exporting Process and 895 Collecting Process. Sending only the required information can 896 also reduce network load. 898 7.2. IPFIX Protocol on the Collecting Process 900 The Collecting Process is responsible for: 902 1. Receiving and decoding Flow Records from the IPFIX Devices. 904 2. Reporting on the loss of Flow Records sent to the Collecting 905 Process by an IPFIX Exporting Process. 907 Complete details of the IPFIX protocol are given in IPFIX-PROTO [3]. 909 7.3. Support for Applications 911 Applications that use the information collected by IPFIX may be 912 Billing or Intrusion Detection sub-systems, etc. These applications 913 may be an integral part of the Collecting Process or they may be co- 914 located with the Collecting Process. The way by which these 915 applications interface with IPFIX systems to get the desired 916 information is out of scope for this document. 918 8. Export Models 920 8.1. Export with Reliable Control Connection 922 As mentioned in the IPFIX-REQS [1] document, an IPFIX Device must be 923 able to transport its Control Information and Data Stream over a 924 congestion-aware transport protocol. 926 If the network in which the IPFIX Device and Collecting Process are 927 located does not guarantee reliability, at least the Control 928 Information should be exported over a reliable transport. The Data 929 Stream may be exported over a reliable or unreliable transport 930 protocol. 932 Possible transport protocols include: 934 o SCTP: Supports reliable and unreliable transport. 936 o TCP: Provides reliable transport only. 938 o UDP: Provides unreliable transport only. Network operators would 939 need to avoid congestion by keeping traffic within their own 940 administrative domains. For example, one could use a dedicated 941 network (or Ethernet link) to carry IPFIX traffic from Exporter to 942 Collector. 944 8.2. Collector Failure Detection and Recovery 946 The transport connection (in the case of a connection oriented 947 protocol) is pre-configured between the IPFIX Device and the 948 Collector. The IPFIX protocol does not provide any mechanism for 949 configuring the Exporting and Collecting Processes. 951 Once connected, an IPFIX Collector receives Control Information and 952 uses that information to interpret Flow Records. The IPFIX Device 953 should set a keepalive (e.g. the keepalive timeout in the case of 954 TCP, the HEARTBEAT interval in the case of SCTP) to a sufficiently 955 low value so that it can quickly detect a Collector failure. 957 Collector failure refers to the crash or restart of the Collecting 958 Process, or of the Collector itself. A Collector failure is detected 959 at the IPFIX Device by the break in the connection oriented transport 960 protocol session, depending on the transport protocol - the 961 connection timeout mechanisms differ. On detecting a keepalive 962 timeout in a single Collector scenario, the IPFIX Device should stop 963 sending Flow Records to the Collector and try to reestablish the 964 transport connection. If Collecting Process failover is supported by 965 the Exporting Process, backup session(s) may be opened in advance, 966 and Control Information sent to it. 968 There could be one or more secondary Collectors with priority 969 assigned to them. The primary Collector crash is detected at the 970 IPFIX Device. On detecting loss of connectivity, the IPFIX Device 971 opens a Data Stream with the secondary Collector of the next highest 972 priority. If that secondary was not opened in advance, both the 973 Control Information and Data Stream must be sent to it. That 974 Collector might then become the primary, or the Exporting Process 975 might try to reestablish the original session. 977 8.3. Collector Redundancy 979 Configuring redundant Collectors is an alternative to configuring 980 backup Collectors. In this model, all Collectors simultaneously 981 receive the Control Information and Data Streams. Multiple {Control 982 Information, Data Stream} pairs could be sent, each to a different 983 Collector from the same IPFIX Device. Since the IPFIX protocol 984 requires a congestion-aware transport, achieving redundancy using 985 multicast is not an option. 987 9. IPFIX Flow Collection in Special Situations 989 An IPFIX Device could be doing one or more of generating, receiving, 990 altering special types of traffic which are listed below. 992 Tunnel traffic: 994 The IPFIX Device could be the head, midpoint or endpoint of a 995 tunnel. In such cases the IPFIX Device could be handling GRE, 996 IPinIP or UTI traffic. 998 VPN traffic: 1000 The IPFIX Device could be a provider edge device which receives 1001 traffic from customer sites belonging to different Virtual Private 1002 Networks. 1004 Similarly, IPFIX could be implemented on devices which perform one or 1005 more of the following special services: 1007 o Explicitly drop packets. For example a device which provides 1008 firewall service drops packets based on some administrative 1009 policy. 1011 o Alter the values of fields used as IPFIX Flow Keys of interest. 1012 For example a device which provides NAT service can change source 1013 and/or destination IP address. 1015 In cases such as those listed above, there should be clear guidelines 1016 as to: 1018 o How and when to classify the packets as Flows in the IPFIX Device. 1020 o If multiple encapsulations are used to define Flows, how to convey 1021 the same fields (e.g. IP address) in different layers. 1023 o How to differentiate Flows based on different private domains. 1024 For example, overlapping IP addresses in Layer-3 VPNs. 1026 o What extra information needs be exported so that the Collector can 1027 make a clear interpretation of the received Flow Records. 1029 10. Security Considerations 1031 Flow information can be used for various purposes, such as usage 1032 accounting, traffic profiling, traffic engineering, and intrusion 1033 detection. The security requirement may differ significantly for 1034 such applications. To be able to satisfy the security needs of 1035 various IPFIX users, an IPFIX system must provide different levels of 1036 security protection. 1038 10.1. Data Security 1040 IPFIX data comprises Control Information and Data Stream generated by 1041 the IPFIX Device. 1043 The IPFIX data may exist in both the IPFIX Device and the Collector. 1044 In addition, the data is also transferred on the wire from the IPFIX 1045 Device to the Collector when it is exported. To provide security, 1046 the data should be protected from common network attacks. 1048 The protection of IPFIX data within the end system (IPFIX Device and 1049 Collector) is out of scope for this document. It is assumed that the 1050 end system operator will provide adequate security for the IPFIX 1051 data. 1053 The IPFIX architecture must allow different levels of protection to 1054 the IPFIX data on the wire. Wherever security functions are required 1055 it is recommended that users should leverage lower layers using 1056 either IPsec or TLS, if these can successfully satisfy the security 1057 requirement of IPFIX data protection. 1059 To protect the data on the wire, three levels of granularity should 1060 be supported; these are described in the following subsections. 1062 10.1.1. Host-Based Security 1064 Security may not be required when the transport between the IPFIX 1065 Device and the Collector is perceived as safe. This option allows 1066 the protocol to run most efficiently without extra overhead and an 1067 IPFIX system must support it. 1069 10.1.2. Authentication-only 1071 Authentication-only protection provides IPFIX users with the 1072 assurance of data integrity and authenticity. The data exchanged 1073 between the IPFIX Device and the Collector is protected by an 1074 authentication signature. Any modification of the IPFIX data will be 1075 detected by the recipient, resulting in discarding of the received 1076 data. However, the authentication-only option doesn't offer data 1077 confidentiality. 1079 The IPFIX user should not use authentication-only when sensitive or 1080 confidential information is being exchanged. An IPFIX solution 1081 should support this option. The authentication-only option should 1082 provide replay attack protection. Some means to achieve this level 1083 of security are: 1085 o TCP with 'signed packet' option 1087 o IP Authentication Header 1089 10.1.3. Encryption 1091 Data encryption provides the best protection for IPFIX data. The 1092 IPFIX data is encrypted at the sender and only the intended recipient 1093 can decrypt and have access to the data. This option must be used 1094 when the transport between the IPFIX Device and the Collector are 1095 unsafe and the IPFIX data needs to be protected. It is recommended 1096 that the underlying transport layer's security functions be used for 1097 this purpose. Some means to achieve this level of security are: 1099 o Encapsulating Security Payload. 1101 o Transport Layer Security Protocol 1103 The data encryption option adds overhead to the IPFIX data transfer. 1104 It may limit the rate that an Exporter can report its Flow Records to 1105 the Collector due to the resource requirement for running encryption. 1107 10.2. IPFIX End-point Authentication 1109 It is important to make sure that the IPFIX Device is talking to the 1110 "right" Collector rather than to a masquerading Collector. The same 1111 logic also holds true from the Collector point of view, i.e. it may 1112 want to make sure it is collecting the Flow Records from the "right" 1113 IPFIX Device. An IPFIX system should allow the end point 1114 authentication capability so that either one-way or mutual 1115 authentication can be performed between the IPFIX Device and 1116 Collector. 1118 The IPFIX architecture should use any existing transport protection 1119 protocols such as TLS or IPsec to fulfil the authentication 1120 requirement. 1122 10.3. IPFIX Overload 1124 An IPFIX Device could become overloaded under various conditions. 1125 This may be because of exhaustion of internal resources used for Flow 1126 generation and/or export. Such overloading may cause loss of data 1127 from the Exporting Process, either from lack of export bandwidth 1128 (possibly caused by an unusually high number of observed Flows) or 1129 from network congestion in the path from Exporter to Collector. 1131 IPFIX Collectors should be able to detect the loss of exported Flow 1132 Records, and should at least record the number of lost Flow Records. 1134 10.3.1. Denial of Service (DoS) Attack Prevention 1136 Since one of the potential usages for IPFIX is for intrusion 1137 detection, it is important for the IPFIX architecture to support some 1138 kind of DoS resistance. 1140 10.3.1.1. Network Under Attack 1142 The Network itself may be under attack, resulting in an overwhelming 1143 number of IPFIX Messages. An IPFIX system should try to capture as 1144 much information as possible. However, when a large number of IPFIX 1145 Messages are generated in a short period of time, the IPFIX system 1146 may become overloaded. 1148 10.3.1.2. Generic DoS Attack on the IPFIX Device and Collector 1150 The IPFIX Device and Collector may be subject to generic DoS attacks, 1151 just as any system on any open network. These types of attacks are 1152 not IPFIX specific. Preventing and responding to such types of 1153 attacks are out of the scope of this document. 1155 10.3.1.3. IPFIX Specific DoS Attack 1157 There are some specific attacks on the IPFIX portion of the IPFIX 1158 Device or Collector: 1160 o The attacker could overwhelm the Collector with spoofed IPFIX 1161 export packets. One way to solve this problem is to periodically 1162 synchronise the sequence numbers of the Flow Records between the 1163 Exporting and Collecting Processes. 1165 o The attacker could provide false reports to the Collector by 1166 sending spoofed packets. 1168 The problems mentioned above can be solved to a large extent if the 1169 control packets are encrypted both ways. 1171 11. IANA Considerations 1173 The IPFIX Architecture, as set out in this document, has two sets of 1174 assigned numbers. Considerations for assigning them are discussed in 1175 this section, using the example policies as set out in the 1176 "Guidelines for IANA Considerations" document IANA-RFC [7]. 1178 11.1. Numbers used in the Protocol 1180 IPFIX Messages, as described in IPFIX-PROTO [3], use two fields with 1181 assigned values. These are the IPFIX Version Number, indicating 1182 which version of the IPFIX Protocol was used to export an IPFIX 1183 Message, and the IPFIX Set ID, indicating the type for each set of 1184 information within an IPFIX message. 1186 Changes in either IPFIX Version Number or IPFIX Set ID assignments 1187 require an IETF Consensus, i.e. they are to be made via RFCs approved 1188 by the IESG. 1190 11.2. Numbers used in the Information Model 1192 Fields of the IPFIX protocol carry information about traffic 1193 measurement. They are modelled as elements of the IPFIX information 1194 model IPFIX-INFO [2]. Each Information Element describes a field 1195 which may appear in an IPFIX Message. Within an IPFIX message the 1196 field type is indicated by its Field Type. 1198 Changes in IPFIX Field Type will be administered by IANA, subject to 1199 Expert Review, i.e. review by one of a group of experts designated by 1200 an IETF Operations and Management Area Director. Those experts will 1201 initially be drawn from the Working Group Chairs and document editors 1202 of the IPFIX and PSAMP Working Groups. 1204 12. Acknowledgements 1206 The document editors wish to thank all the people contributing to the 1207 discussion of this document on the mailing list, and the design teams 1208 for many valuable comments. In particular, the following made 1209 significant contributions: 1211 Tanja Zseby 1212 Paul Calato 1213 Dave Plonka 1214 Jeffrey Meyer 1215 K.C.Norseth 1216 Vamsi Valluri 1217 Cliff Wang 1218 Ram Gopal 1219 Jc Martin 1220 Carter Bullard 1221 Reinaldo Penno 1222 Simon Leinen 1223 Kevin Zhang 1224 Paul Aitken 1226 Special thanks to Dave Plonka for the multiple thorough reviews. 1228 13. References 1229 13.1. Normative References 1231 [1] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements 1232 for IP Flow Information Export", RFC RFC 3917, October 2004. 1234 [2] Meyer, J., Quittek, J., and S. Bryant, "IPFIX: Information 1235 Model", (work in progress), Internet Draft, 1236 draft-ietf-ipfix-info-08.txt, October 2004. 1238 [3] Claise, B., Bryant, S., Sadasivan, G., and M. Fullmer, "IPFIX: 1239 Protocol", (work in progress), Internet Draft, 1240 draft-ietf-ipfix-protocol-10.txt, December 2004. 1242 [4] Zseby, T., Boschi, E., Penno, R., Brownlee, N., and B. Claise, 1243 "IPFIX: Protocol", (work in progress), Internet Draft, 1244 draft-ietf-ipfix-as-05.txt, October 2004. 1246 13.2. Informative References 1248 [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1249 "RTP: A Transport Protocol for Real-Time Applications", 1250 RFC 1889, January 1996. 1252 [6] Leinen, S., "Evaluation of Candidate Protocols for IP Flow 1253 Information Export", RFC 3955, October 2004. 1255 [7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1256 Considerations Section in RFCs", RFC 2434, October 1998. 1258 Appendix A. Changes/Issues from the -09 Draft 1260 Editorial Improvements: 1262 Changed 'Source ID' to 'Observation Domain ID' throughout, to make 1263 the text clearer, and to match the other IPFIX drafts. 1265 Section 6.4: added comment "If it is not possible to count losses 1266 accurately, e.g. when transport layer errors are detected, the 1267 IPFIX device should report this fact, and perhaps indicate the 1268 time period during which some packets might not have been 1269 observed." 1271 Combined sections 10 and 11. Both are now included in Section 10, 1272 Security Considerations. 1274 Miscellaneous editorial changes to fix typos, tidy up style, etc. 1276 Authors' Addresses 1278 Ganesh Sadasivan 1279 Cisco Systems, Inc. 1280 170 West Tasman Drive 1281 San Jose, CA 95134 1282 USA 1284 Phone: +1 408 527-0251 1285 Email: gsadasiv@cisco.com 1287 Nevil Brownlee 1288 CAIDA | The University of Auckland 1289 Private Bag 92019 1290 Auckland 1291 New Zealand 1293 Phone: +64 9 373 7599 x88941 1294 Email: n.brownlee@auckland.ac.nz 1296 Benoit Claise 1297 Cisco Systems, Inc. 1298 De Kleetlaan 6a b1 1299 1831 Diegem 1300 Belgium 1302 Phone: +32 2 704 5622 1303 Email: bclaise@cisco.com 1305 Juergen Quittek 1306 NEC Europe Ltd. 1307 Adenauerplatz 6 1308 69225 Heidelberg 1309 Germany 1311 Phone: +49 6221 90511-15 1312 Email: quittek@ccrle.nec.de 1314 Intellectual Property Statement 1316 The IETF takes no position regarding the validity or scope of any 1317 Intellectual Property Rights or other rights that might be claimed to 1318 pertain to the implementation or use of the technology described in 1319 this document or the extent to which any license under such rights 1320 might or might not be available; nor does it represent that it has 1321 made any independent effort to identify any such rights. Information 1322 on the procedures with respect to rights in RFC documents can be 1323 found in BCP 78 and BCP 79. 1325 Copies of IPR disclosures made to the IETF Secretariat and any 1326 assurances of licenses to be made available, or the result of an 1327 attempt made to obtain a general license or permission for the use of 1328 such proprietary rights by implementers or users of this 1329 specification can be obtained from the IETF on-line IPR repository at 1330 http://www.ietf.org/ipr. 1332 The IETF invites any interested party to bring to its attention any 1333 copyrights, patents or patent applications, or other proprietary 1334 rights that may cover technology that may be required to implement 1335 this standard. Please address the information to the IETF at 1336 ietf-ipr@ietf.org. 1338 Disclaimer of Validity 1340 This document and the information contained herein are provided on an 1341 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1342 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1343 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1344 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1345 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1346 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1348 Copyright Statement 1350 Copyright (C) The Internet Society (2006). This document is subject 1351 to the rights, licenses and restrictions contained in BCP 78, and 1352 except as set forth therein, the authors retain all their rights. 1354 Acknowledgment 1356 Funding for the RFC Editor function is currently provided by the 1357 Internet Society.