idnits 2.17.1 draft-ietf-ipfix-architecture-06.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.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1338. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == 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 797 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 (January 2005) is 7041 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: 'RFC1889' on line 233 -- Looks like a reference, but probably isn't: 'IPFIX-INFO' on line 355 ** Downref: Normative reference to an Informational RFC: RFC 3917 (ref. '1') == Outdated reference: A later version (-15) exists of draft-ietf-ipfix-info-06 == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-07 == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-03 -- Duplicate reference: draft-ietf-ipfix-protocol, mentioned in '4', was also mentioned in '3'. -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '6') (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Flow Information Export WG G. Sadasivan 2 (ipfix) Cisco Systems, Inc. 3 Internet-Draft N. Brownlee 4 Expires: July 5, 2005 CAIDA | The University of Auckland 5 B. Claise 6 Cisco Systems, Inc. 7 J. Quittek 8 NEC Europe Ltd. 9 January 2005 11 Architecture for IP Flow Information Export 12 draft-ietf-ipfix-architecture-06 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on July 5, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This memo defines the IP Flow Information eXport (IPFIX) architecture 48 for the selective monitoring of IP flows, and for the export of 49 measured IP flow information from an IPFIX device to a collector, as 50 per the requirements set out in the IPFIX requirements document. 52 Table of Contents 54 1. Changes/Issues from the -05 Draft . . . . . . . . . . . . . 4 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1 Document Scope . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2 IPFIX Documents Overview . . . . . . . . . . . . . . . . . 5 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Examples of Flows . . . . . . . . . . . . . . . . . . . . . 9 60 5. IPFIX Reference Model . . . . . . . . . . . . . . . . . . . 11 61 6. IPFIX Functional and Logical Blocks . . . . . . . . . . . . 12 62 6.1 Metering Process . . . . . . . . . . . . . . . . . . . . . 12 63 6.1.1 Flow Record Expiration . . . . . . . . . . . . . . . . 13 64 6.2 Observation Point . . . . . . . . . . . . . . . . . . . . 13 65 6.3 Selection Criteria for Packets . . . . . . . . . . . . . . 14 66 6.3.1 Sampling Functions, Si . . . . . . . . . . . . . . . . 14 67 6.3.2 Filter Functions, Fi . . . . . . . . . . . . . . . . . 15 68 6.4 Observation Domain . . . . . . . . . . . . . . . . . . . . 15 69 6.5 Exporting Process . . . . . . . . . . . . . . . . . . . . 15 70 6.6 Collecting Process . . . . . . . . . . . . . . . . . . . . 16 71 6.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 7. Overview of the IPFIX Protocol . . . . . . . . . . . . . . . 18 73 7.1 Information Model Overview . . . . . . . . . . . . . . . . 18 74 7.2 Flow Records . . . . . . . . . . . . . . . . . . . . . . . 19 75 7.3 Control Information . . . . . . . . . . . . . . . . . . . 19 76 7.4 Reporting Responsibilities . . . . . . . . . . . . . . . . 20 77 8. IPFIX Protocol Details . . . . . . . . . . . . . . . . . . . 20 78 8.1 The IPFIX Basis Protocol . . . . . . . . . . . . . . . . . 20 79 8.2 IPFIX Protocol on the Collecting Process . . . . . . . . . 21 80 8.3 Support for Applications . . . . . . . . . . . . . . . . . 21 81 9. Export Models . . . . . . . . . . . . . . . . . . . . . . . 22 82 9.1 Export with Reliable Control Connection . . . . . . . . . 22 83 9.2 Collector Failure Detection and Recovery . . . . . . . . . 22 84 9.3 Collector Redundancy . . . . . . . . . . . . . . . . . . . 23 85 10. IPFIX Flow Collection in Special Situations . . . . . . . . 23 86 11. Security Considerations . . . . . . . . . . . . . . . . . . 24 87 11.1 Data Security . . . . . . . . . . . . . . . . . . . . . 24 88 11.1.1 Host-Based Security . . . . . . . . . . . . . . . . 25 89 11.1.2 Authentication-only . . . . . . . . . . . . . . . . 25 90 11.1.3 Encryption . . . . . . . . . . . . . . . . . . . . . 25 91 11.2 IPFIX End-point Authentication . . . . . . . . . . . . . 26 92 12. IPFIX Overload . . . . . . . . . . . . . . . . . . . . . . . 26 93 12.1 Denial of Service (DoS) Attack Prevention . . . . . . . 26 94 12.1.1 Network Under Attack . . . . . . . . . . . . . . . . 26 95 12.1.2 Generic DoS Attack on the IPFIX Device and 96 Collector . . . . . . . . . . . . . . . . . . . . . 26 97 12.1.3 IPFIX Specific DoS Attack . . . . . . . . . . . . . 27 98 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 99 13.1 Numbers used in the Protocol . . . . . . . . . . . . . . 27 100 13.2 Numbers used in the Information Model . . . . . . . . . 27 101 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 102 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 103 15.1 Normative References . . . . . . . . . . . . . . . . . . 28 104 15.2 Non-normative References . . . . . . . . . . . . . . . . 28 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 106 Intellectual Property and Copyright Statements . . . . . . . 30 108 1. Changes/Issues from the -05 Draft 110 Flow Keys: 112 Agreed that each field used in defining a flow is a Flow Key. A 113 flow is therefore defined by a set of Flow Keys. Text changed to 114 say 'set of Flow Keys' where neccessary. 116 Special Traffic and Devices: 118 These sections pointed out that IPFIX can be implemented in 119 devices other than switches and routers, and that in such cases 120 one needs a clear description of the information elements used in 121 such devices. These two sections have been combined to produce a 122 shorter description of 'IPFIX in Special Situations.' 124 Editorial Changes: 126 A few errors (from early sections of text) have been corrected so 127 that they match the Protocol and Info Model drafts. 129 Architecture issues: 131 All the issues in draft-05 are now closed. 133 2. Introduction 135 There are several applications e.g., usage-based accounting, traffic 136 profiling, traffic engineering, attack/intrusion detection, QoS 137 monitoring, that require flow-based IP traffic measurements. It is 138 therefore important to have a standard way of exporting information 139 related to IP flows. This document defines an architecture for IP 140 traffic flow monitoring, measuring and exporting. It provides a 141 high-level description of an IPFIX device's key components and their 142 functions. 144 2.1 Document Scope 146 This document defines the architecture for IPFIX. Its main 147 objectives are to: 149 o Describe the key IPFIX architectural components, consisting of (at 150 least) IPFIX devices and collectors communicating using the IPFIX 151 protocol. 153 o Define the IPFIX architectural requirements, e.g., recovery, 154 security, etc. 156 o Describe the characteristics of the IPFIX protocol. 158 Note that the IPFIX architecture does not provide for remote 159 configuration of an IPFIX device. Instead, IPFIX devices are 160 configured by other means. 162 2.2 IPFIX Documents Overview 164 The IPFIX protocol provides network administrators with access to IP 165 flow information. This document specifies the architecture for the 166 export of measured IP flow information out of an IPFIX exporting 167 process to a collecting process, per the requirements defined in 168 IPFIX-REQS [1]. The IPFIX protocol document IPFIX-PROTO [3] 169 specifies how IPFIX flow record data, options record data, and 170 templates are carried via a congestion- aware transport protocol from 171 IPFIX exporting process to IPFIX collecting process. IPFIX has a 172 formal description of IPFIX information elements (fields), their 173 name, type and additional semantic information, as specified in 174 IPFIX-INFO [2]. Finally IPFIX-AS [4] describes what type of 175 applications can use the IPFIX protocol and how they can use the 176 information provided. It furthermore shows how the IPFIX framework 177 relates to other architectures and frameworks. 179 Note that the IPFIX system does not provide for remote configuration 180 of an IPFIX device. Instead, IPFIX devices are configured by network 181 operations staff. 183 3. Terminology 185 The definitions of basic IPFIX terms such as IP Traffic Flow, 186 Exporting Process, Collecting Process, Observation Point, etc. are 187 semantically identical with those found in the IPFIX requirements 188 document IPFIX-REQS [1]. Some of the terms have been expanded for 189 more clarity when defining the protocol. Additional definitions 190 required for the architecture have also been defined. For the same 191 terms defined here and in IPFIX-PROTO [3] the definitions are 192 equivalent in both documents. 194 * Observation Point 196 An Observation Point is a location in the network where IP packets 197 can be observed. Examples include: a line to which a probe is 198 attached, a shared medium, such as an Ethernet-based LAN, a single 199 port of a router, or a set of interfaces (physical or logical) of 200 a router. 202 Note that one Observation Point may be a superset of several other 203 Observation Points. For example one Observation Point can be an 204 entire line card. That would be the superset of the individual 205 Observation Points at the line card's interfaces. 207 * Observation Domain 209 An Observation Domain is the largest set of Observation Points for 210 which Flow information can be aggregated by a Metering Process. 211 Each Observation Domain presents itself using a unique ID to the 212 Collecting Process to identify the IPFIX Messages it generates. 213 For example, a router line card may be an observation domain if it 214 is composed of several interfaces: each of which is an Observation 215 Point. Every Observation Point is associated with an Observation 216 Domain. 218 * IP Traffic Flow or Flow 220 There are several definitions of the term 'flow' being used by the 221 Internet community. Within the context of IPFIX we use the 222 following definition: 224 A Flow is defined as a set of IP packets passing an Observation 225 Point in the network during a certain time interval. All packets 226 belonging to a particular Flow have a set of common properties. 227 Each property is defined as the result of applying a function to 228 the values of: 230 1. One or more packet header field (e.g. destination IP 231 address), transport header field (e.g. destination port 232 number), or application header field (e.g. RTP header fields 233 [RFC1889]) 235 2. One or more characteristics of the packet itself (e.g. number 236 of MPLS labels) 238 3. One or more fields derived from packet treatment (e.g. next 239 hop IP address, output interface) 241 A packet is said to belong to a Flow if it completely satisfies 242 all the defined properties of the Flow. 244 This definition covers the range from a Flow containing all 245 packets observed at a network interface to a Flow consisting of 246 just a single packet between two applications with a specific 247 sequence number. 249 * Flow Key 251 Each of the fields which 253 1. Belong to the packet header (e.g. destination IP address) 255 2. Are a property of the packet itself (e.g. packet length) 257 3. Are derived from packet treatment (e.g. AS number) 259 and which are used to define a Flow are termed Flow Keys. 261 * Flow Record 263 A Flow Record contains information about a specific Flow that was 264 observed at an Observation Point. A Flow Record contains measured 265 properties of the Flow (e.g. the total number of bytes for all 266 the Flow's packets) and usually characteristic properties of the 267 Flow (e.g. source IP address). 269 * Metering Process 271 A Metering Process generates Flow Records. Input to the process 272 are packet headers observed at an Observation Point, and packet 273 treatment at the Observation Point Point (for example the selected 274 output interface). 276 The Metering Process consists of a set of functions that includes 277 packet header capturing, timestamping, sampling, classifying, and 278 maintaining Flow Records. 280 The maintenance of Flow Records may include creating new records, 281 updating existing ones, computing Flow statistics, deriving 282 further Flow properties, detecting Flow expiration, passing Flow 283 Records to the Exporting Process, and deleting Flow Records. 285 * Exporting Process 287 An Exporting Process sends Flow Records to one or more Collecting 288 Processes. The Flow Records are generated by one or more Metering 289 Processes. 291 * Exporter 293 A device which hosts one or more Exporting Processes is termed an 294 Exporter. 296 * IPFIX Device 298 An IPFIX Device hosts at least one Observation Point, a Metering 299 Process and an Exporting Process. Typically, corresponding 300 Observation Point(s), Metering Process(es) and Exporting 301 Process(es) are co-located at such a device, for example at a 302 router. 304 * Collecting Process 306 A Collecting Process receives Flow Records from one or more 307 Exporting Processes. The Collecting Process might process or 308 store received Flow Records, but such actions are out of scope for 309 this document. 311 * Collector 313 A device which hosts one or more Collecting Processes is termed a 314 Collector. 316 * Template 318 A Template is an ordered sequence of pairs, used to 319 completely identify the structure and semantics of a particular 320 set of information that needs to be communicated from an IPFIX 321 Device to a Collector. Each Template is uniquely identifiable by 322 means of a Template ID. 324 * Control Information, Data Stream 326 The information that needs to be exported from the IPFIX Device 327 can be classified into the following categories: 329 Control Information 331 This includes the Flow definition, selection criteria for 332 packets within the Flow sent by the Exporting Process, and any 333 IPFIX protocol messages. The Control Information carries all 334 the information needed for the end-points to understand the 335 IPFIX protocol, and specifically for the receiver (Collector) 336 to understand and interpret the data sent by the sender 337 (Exporter). 339 Data Stream 341 This includes Flow Records carrying the field values for the 342 various observed Flows at each of the Observation Points. 344 IPFIX Message 346 An IPFIX Message is a message originating at the Exporting Process 347 that carries the IPFIX records of this Exporting Process and whose 348 destination is a Collecting Process. An IPFIX Message is 349 encapsulated within a transport layer. 351 Information Element 353 An Information Element is a protocol and encoding independent 354 description of an attribute which may appear in an IPFIX Flow 355 Record. The IPFIX information model [IPFIX-INFO] defines the base 356 set of Information Elements for IPFIX. The type associated with 357 an Information Element indicates constraints on what it may 358 contain and also determine the valid encoding mechanisms for use 359 in IPFIX. 361 4. Examples of Flows 363 Some examples of Flows are listed below: 365 Example 1: The Flow Keys define the different fields by which Flows 366 are distinguished. The different combination of the field values 367 creates unique Flows. If the set of Flow Keys is {source IP address, 368 destination IP address, DSCP}, then all of these are different Flows. 370 1. {198.18.40.1, 198.18.23.5, 4} 371 2. {198.18.40.23, 198.18.23.67, 4} 372 3. {198.18.40.23, 198.18.23.67, 2} 373 4. {198.18.20.200, 198.18.23.67, 4} 375 Example 2: A match function can be applied to all the packets that 376 pass through an Observation Point, in order to aggregate some values. 377 This could be done by defining the set of Flow Keys as {source IP 378 address, destination IP address, DSCP} as in example 1 above, and 379 applying a function which masks out the least significant 8 bits of 380 the source IP address and destination IP address (i.e. the result is 381 a /24 address). The four Flows from example 1 would now be 382 aggregated into three Flows by merging the Flows 1 and 2 into a 383 single Flow. 385 1. {198.18.40.0/24, 198.18.23.0/24, 4} 386 2. {198.18.40.0/24, 198.18.23.0/24, 2} 387 3. {198.18.20.0/24, 198.18.23.0/24, 4} 389 Example 3: A filter defined by some field values can be applied on 390 all packets that pass the Observation Point, in order to select only 391 certain Flows. The filter is defined by choosing fixed values for 392 specific fields from the packet. 394 All the packets that go from a customer network 198.18.40.0/24 to 395 another customer network 198.18.23.0/24 with DSCP value of 4 define a 396 Flow. All other combinations don't define a Flow and are not taken 397 into account. The three Flows from example 2 would now be reduced to 398 one Flow by filtering away the second and the third Flow, leaving 399 only {198.18.40.0/24, 198.18.23.0/24, 4}. 401 The above examples can be thought of as a function F() taking as 402 input {source IP address, destination IP address, DSCP}. The 403 function selects only the packets which satisfy all three of the 404 following conditions: 406 1. Mask out the least significant 8 bits of source IP address, match 407 against 198.18.40.0. 409 2. Mask out the least significant 8 bits of destination IP address, 410 match against 198.18.23.0. 412 3. Only accept DSCP value equal to 4. 414 Depending on the values of {source IP address, destination IP 415 address, DSCP} of the different observed packets, the Metering 416 Process function F() would choose/filter/aggregate different sets of 417 packets, which would create different Flows. For example, various 418 combination of values of {source IP address, destination IP address, 419 DSCP}, F(source IP address, destination IP address, DSCP) would 420 result in the definition of one or more Flows. 422 5. IPFIX Reference Model 424 The figure below shows the reference model for IPFIX. This figure 425 covers the various possible scenarios that can exist in an IPFIX 426 system. 428 +----------------+ +----------------+ 429 |[*Application 1]| ..|[*Application n]| 430 +--------+-------+ +-------+--------+ 431 ^ ^ 432 ~ ~ 433 +~~~~~~~~~~+~~~~~~~~+ 434 ^ 435 ~ 436 +------------------------+ +-------+------------------+ 437 |IPFIX Device(1) | | Collector(1) | 438 |[Exporting Process(es)] |<----------->| [Collecting Process(es)] | 439 +------------------------+ +--------------------------+ 440 .... .... 441 +------------------------+ +---------------------------+ 442 |IPFIX Device(i) | | Collector(j) | 443 |[Obsv Point(s)] |<---------->| [Collecting Process(es)] | 444 |[Metering Process(es)] | +---->| [*Application(s)] | 445 |[Exporting Process(es)] | | +---------------------------+ 446 +------------------------+ . 447 .... . .... 448 +------------------------+ | +--------------------------+ 449 |IPFIX Device(m) | | | Collector(n) | 450 |[Obsv Point(s)] |<-----+---->| [Collecting Process(es)] | 451 |[Metering Process(es)] | | [*Application(s)] | 452 |[Exporting Process(es)] | +--------------------------+ 453 +------------------------+ 455 The various functional components are indicated within brackets []. 456 The functional components within [*] are not part of the IPFIX 457 architecture. The interfaces shown by "<-->" are defined by the 458 IPFIX architecture but those shown by "<~~>" are not. 460 Figure 3 462 The figure below shows a typical IPFIX Device where the IPFIX 463 components are shown in rectangular boxes. 465 +--------------------------------------------------+ 466 | IPFIX Device | 467 | +-----+ | 468 | +---......--+------------+---------> | | 469 | | | | | | 470 | +----+----+ +----+----+ | | | 471 | |Metering | |Metering | | E | | 472 | |Process 1| |Process N| | x | | 473 | |(Packet | |(Packet | | p | | 474 | | Level) | | Level) | | o | | 475 | +---------+ +---------+ | r | | 476 | ^ ^ | t | | 477 |+-------+-----------------------+-------+ | i | | 478 || | Observation Domain 1 | | | n | | 479 || +-----+------+ +-----+------+| | g | | 480 || |Obsv Point 1| ... |Obsv Point M|| | | | 481 || +------------+ +------------+| | | | 482 Packets|+-------^-------------------------^-----+ | | | Export 483 --->---+--------+----------.....----------+ | | | Pkts to 484 In | | +-------> 485 | . . . . . | | |Collector 486 | | | | 487 | +---......--+------------+---------> | | 488 | | | | | | 489 | +----+----+ +----+----+ | P | | 490 | |Metering | |Metering | | r | | 491 | |Process 1| |Process N| | o | | 492 | +---------+ +---------+ | c | | 493 | ^ ^ | e | | 494 |+-------+-----------------------+-------+ | s | | 495 || | Observation Domain K | | | s | | 496 || +-----+------+ +-----+------+| | | | 497 || |Obsv Point 1| ... |Obsv Point M|| | | | 498 || +------------+ +------------+| | | | 499 Packets|+-------^-------------------------^-----+ +-----+ | 500 --->---+--------+---------- ... ----------+ | 501 In | | 502 +--------------------------------------------------+ 504 Figure 4 506 6. IPFIX Functional and Logical Blocks 508 6.1 Metering Process 510 Every Observation Point in an IPFIX Device, participating in Flow 511 measurements, must be associated with at least one Metering Process. 512 Every packet coming into an Observation Point goes into each of the 513 Metering Processes associated with the Observation Point. Broadly, 514 each Metering Process observes the packets that pass an Observation 515 Point, does timestamping and classifies the packets into Flow(s) 516 based on the selection criteria. 518 The Metering Process is a functional block which manages all the 519 Flows generated from an Observation Domain. The typical functions of 520 a Metering Process may include: 522 o Maintain database(s) of all the Flows Records from an Observation 523 Domain. This includes creating new Flow Records, updating 524 existing ones, computing Flow Records statistics, deriving further 525 Flow properties, adding non-flow-specific information based on the 526 packet treatment (in some cases fields like AS numbers, router 527 state, etc.) 529 o Maintain statistics about the itself, such as Flows Records 530 generated, packet observed, etc. 532 6.1.1 Flow Record Expiration 534 A Flow Record is considered to have expired under the following 535 conditions: 537 1. If the Metering Process can deduce the end of a Flow, that Flow 538 Record should be exported when the end of the Flow is detected. 539 For example, a Flow generated by TCP traffic where the FIN or RST 540 bits indicate the end of the Flow Record. 542 2. If no packets belonging to the Flow have been observed for a 543 certain period of time. This time period should be configurable 544 at the Metering Process, with a minimum value of 0 seconds for 545 immediate expiration. Note that a zero timeout would report a 546 Flow as a sequence of single-packet Flows. 548 3. If the IPFIX Device experiences resource constraints, a Flow 549 Record may be prematurely expired (e.g. lack of memory to store 550 Flow Records) 552 4. For long-running Flows, the Metering Process should expire the 553 Flow Record on a regular basis or based on some expiration 554 policy. This periodicity or expiration policy should be 555 configurable at the Metering Process. When a the Record of a 556 long-running Flow is expired, that Flow Record may still be 557 maintained by the Metering Process so that, for further observed 558 packets of the same Flow Record, the Metering Process does not 559 need to create a new Flow Record. 561 6.2 Observation Point 563 A Flow Record can be better analyzed if the Observation Point from 564 which it was measured is known. As such it is recommended that IPFIX 565 Devices send this information to Collectors. In cases where there is 566 a single Observation Point or where the Observation Point information 567 is not relevant, the Metering Process may choose not to add the 568 Observation Point to the Flow Records. 570 6.3 Selection Criteria for Packets 572 A Metering Process may define rules so that only certain packets 573 within an incoming stream of packets are chosen for measurement at an 574 Observation Point. This may be done by one of the two methods 575 defined below or a combination of them, in either order. A 576 combination of each of these methods can be adopted to select the 577 packets, i.e. one can define a set of methods {F1, S1, F2, S2, S3} 578 executed in a specified sequence at an Observation Point to select 579 particular Flows. 581 The figure below shows the operations which may be applied as part of 582 a typical Metering Process. 584 packet header capturing 585 | 586 timestamping 587 | 588 v 589 +----->+ 590 | | 591 | sampling Si (1:1 in case of no sampling) 592 | | 593 | filtering Fi (select all when no criteria) 594 | | 595 +------+ 596 | 597 v 598 Flows 600 Figure 5 602 6.3.1 Sampling Functions, Si 604 A sampling function determines which packets within a stream of 605 incoming packets is selected for measurement, i.e. packets that 606 satisfy the sampling criteria for this Metering Process. 608 Example: sample every 100th packet that was received at an 609 Observation Point and collect the Flow Records selected by a 610 particular filter function. Choosing all the packets is a special 611 case where the sampling rate is 1:1. 613 6.3.2 Filter Functions, Fi 615 A Filter Function selects only those incoming packets that satisfy a 616 function on fields defined by the packet header fields, fields 617 obtained while doing the packet processing, or properties of the 618 packet itself. 620 Example: Mask/Match of the fields that define a filter. A filter 621 might be defined as {Protocol == TCP, Destination Port between 80 and 622 120}. 624 Several such filters could be used in any sequence to select packets. 625 Note that packets selected by a (sequence of) filter functions may be 626 further classified by other filter functions, i.e. the selected 627 packets may belong to several Flows, any or all of which are 628 exported. 630 6.4 Observation Domain 632 The Observation Domain is a logical block that presents a single 633 identity for a group of Observation Points within an IPFIX Device. 634 Each {Observation Point, Metering Process} pair belongs to a single 635 Observation Domain. An IPFIX Device could have multiple Observation 636 Domains, each of which has a subset of the total set of Observation 637 Points in it. Each Observation Domain must carry a unique ID within 638 the context of an IPFIX Device. Note that in case of multiple 639 Observation Domains, a unique ID per Observation Domain must be 640 transmitted as a parameter to the Exporting Function. That unique ID 641 is referred to as the IPFIX Source ID. 643 6.5 Exporting Process 645 The Exporting Process is the functional block that sends data to one 646 or more IPFIX Collectors using the IPFIX protocol. On one side the 647 Exporting Process interfaces with Metering Process to get Flow 648 Records, while on the other side it talks to a Collecting Process on 649 the Collector(s). 651 There may be additional rules defined within an Observation Domain so 652 that only certain Flows Records are exported. This may be done by 653 either one or a combination of Si, Fi, as described in the section on 654 "Selection Criteria for Packets". 656 Example: Only the Flow Records which meet the following selection 657 criteria are exported. 659 1. All Flow Records whose destination IP address matches 660 {198.18.33.5}. 662 2. Every other (i.e. sampling rate 1 in 2) Flow Record whose 663 destination IP address matches {198.18.11.30}. 665 6.6 Collecting Process 667 Collecting Processes use a Flow Record's Template ID to interpret 668 that Flow Record's Information Elements. To allow this, an IPFIX 669 Exporter must ensure that an IPFIX Collector knows the Template ID 670 for each incoming Flow Record. To interpret incoming Flow Records, 671 an IPFIX Collector may also need to know the function F() that was 672 used by the Metering Process for each Flow. 674 An IPFIX Collector may also use the selection criteria for packets to 675 interpret the Flow Records further. 677 The functions of the Collecting Process must include: 679 o Identifying, accepting and decoding the IPFIX Messages from 680 different pairs. 682 o Storing the Control Information and Flow Records received from an 683 IPFIX Device. 685 At a high level, the Collecting Process: 687 1. Receives and stores the Control Information. 689 2. Decodes and stores the Flow Records using the Control 690 Information. 692 6.7 Summary 694 The figure below shows the functions performed in sequence by the 695 various functional blocks in an IPFIX Device. 697 Packet(s) coming into Observation Point(s) 698 | | 699 v v 700 +----------------+-------------------------+ +-----+-------+ 701 | Metering Process on an | | | 702 | Observation Point | | | 703 | packet header capturing | | | 704 | | |...| Metering | 705 | timestamping | | Process N | 706 | | | | | 707 | +----->+ | | | 708 | | | | | | 709 | | sampling Si (1:1 in case of no | | | 710 | | | sampling) | | | 711 | | classifying Fi (select all when | | | 712 | | | no criteria) | | | 713 | +------+ | | | 714 | | | | | 715 | | Timing out Flows | | | 716 | | Handle resource overloads | | | 717 +--------|---------------------------------+ +-----|-------+ 718 | | 719 Flow Records (identified by Observation Domain) Flow Records 720 | | 721 +---------+---------------------------------+ 722 | 723 +--------------------|----------------------------------------------+ 724 | | Exporting Process | 725 |+-------------------|-------------------------------------------+ | 726 || v IPFIX Protocol | | 727 ||+-----------------------------+ +----------------------------+| | 728 |||Rules for | |Functions || | 729 ||| Picking/sending Templates | |-Packetize selected Control || | 730 ||| Picking/sending Flow Records|->| & data Information into || | 731 ||| Encoding Template & data | | IPFIX export packets. || | 732 ||| Selecting Flows to export(*)| |-Handle export errors || | 733 ||+-----------------------------+ +----------------------------+| | 734 |+----------------------------+----------------------------------+ | 735 | | | 736 | IPFIX exported packet | 737 | | | 738 | +------------+-----------------+ | 739 | | Anonymize export packet(*) | | 740 | +------------+-----------------+ | 741 | | | 742 | +------------+-----------------+ | 743 | | Transport Protocol | | 744 | +------------+-----------------+ | 745 | | | 746 +-----------------------------+-------------------------------------+ 747 | 748 v 749 IPFIX export packet to Collector 751 (*) indicates that the block is optional. 753 Figure 6 755 7. Overview of the IPFIX Protocol 757 An IPFIX Device consists of a set of co-operating processes that 758 implement the functional blocks described in the previous section. 759 Alternatively, an IPFIX Device can be viewed simply as a network 760 entity which implements the IPFIX protocol. At the IPFIX Device, the 761 protocol functionality resides in the Exporting Process. The IPFIX 762 Exporting Process gets Flow Records from a Metering Process, and 763 sends them to the Collector(s). 765 At a high level, an IPFIX Device performs the following tasks: 767 1. Encode Control Information into Templates. 769 2. Encode packets observed at the Observation Points into Flow 770 Records. 772 3. Packetize the selected Templates and Flow Records into IPFIX 773 Messages. 775 4. Send IPFIX Messages to the Collector. 777 The IPFIX protocol communicates information from an IPFIX Exporter to 778 an IPFIX Collector. That information includes not only Flow Records, 779 but also information about the Metering Process. Such information 780 (referred to as Control Information) includes details of the data 781 fields in Flow Records. It may also include statistics from the 782 Metering Process, such as the number of packets lost (i.e. not 783 metered). 785 For details of the IPFIX protocol please refer to IPFIX-PROTO [3]. 787 7.1 Information Model Overview 789 The IP Flow Information eXport (IPFIX) protocol serves for 790 transmitting information related to measured IP traffic over the 791 Internet. The protocol specification in IPFIX-PROTO [3] defines how 792 Information Elements are transmitted. For Information Elements, it 793 specifies the encoding of a set of basic data types. However, the 794 list of fields that can be transmitted by the protocol, such as Flow 795 attributes (source IP address, number of packets, etc.) and 796 information about the Metering and Exporting Process (packet 797 Observation Point, sampling rate, Flow timeout interval, etc.), is 798 not specified in IPFIX-PROTO [3]. Instead, it is defined in the 799 IPFIX Information Model document IPFIX-INFO [2]. 801 The Information Model provides a complete description of the 802 properties of every IPFIX Information Element. It does this by 803 specifying each element's name, Field Type, data type, etc., and 804 providing a description of each element. Element descriptions give 805 the semantics of the element, i.e. say how it is derived from a Flow 806 or other information available within an IPFIX Device. 808 7.2 Flow Records 810 The following rules provide guidelines to be followed while encoding 811 the Flow Records information: 813 A Flow Record contains enough information so that the Collecting 814 Process can identify the corresponding . 817 The Exporting Process encodes a given Information Element (as 818 specified in IPFIX-INFO [2]), based on the encoding standards 819 prescribed by IPFIX-PROTO [3]. 821 7.3 Control Information 823 The following rules provide guidelines to be followed while encoding 824 the Control Information: 826 o Per-Flow Control Information should be encoded such that the 827 Collecting Process can capture the structure and semantics of the 828 corresponding Flow data for each of the Flows Records exported by 829 the IPFIX Device. 831 o Configuration Control Information is conveyed to a Collector so 832 that its Collecting Process can capture the structure and 833 semantics of the corresponding configuration data. The 834 configuration data which is also Control Information should carry 835 additional information on the Observation Domain within which the 836 configuration takes effect. 838 For example, sampling using the same sampling algorithm, say 1 in 100 839 packets, is configured on two Observation Points O1 and O2. The 840 configuration in this case may be encoded as {ID, configuration 841 domain (O1,O2), sampling algorithm, interval (1 in 100)}, where ID 842 uniquely identifies this configuration. The ID must be sent within 843 the Flow Records in order to be able to match the right configuration 844 control information 846 The Control Information is used by the Collecting Process to: 848 o Decode and interpret Flow Records. 850 o Understand the state of the Exporting Process. 852 Sending Control Information from the Exporting Process in a timely 853 and reliable manner is critical to the proper functioning of the 854 IPFIX Collecting Process. The following approaches may be taken for 855 the export of Control Information. 857 1. Send all the Control Information pertaining to Flow Records prior 858 to sending the Flow Records themselves. This includes any 859 incremental changes to the definition of the Flow Records. 861 2. Notify on a near real time basis the state of the IPFIX Device to 862 the Collecting Process. This includes all changes such as a 863 configuration change that affects the Flow behavior, changes to 864 Exporting Process resources that alter export rates, etc., which 865 the Collector needs to be aware of. 867 3. Since it is vital that a Collecting Process maintains accurate 868 knowledge of the Exporter's state, the export of the Control 869 Information should be done such that that it reaches the 870 Collector reliably. One way to achieve this would be to send the 871 Control Information over a reliable transport. 873 7.4 Reporting Responsibilities 875 From time to time an IPFIX Device may not be able to observe all the 876 packets reaching one of its Observation Points. This could occur if 877 a Metering Process finds itself temporarily short of resources, for 878 example it might run out of packet buffers for IPFIX export, or it 879 might detect errors in its underlying transport layer. 881 In such situations, the IPFIX Device must report to its Collector(s) 882 the number of packet losses that have occurred. 884 8. IPFIX Protocol Details 886 When the IPFIX Working Group was chartered there were existing common 887 practices in the area of Flow export, for example NetFlow, CRANE, 888 LFAP, RTFM, etc. IPFIX's charter required the Working Group to 889 consider those existing practices, and select the one that was the 890 closest fit to the IPFIX requirements IPFIX-REQS [1]. Additions or 891 modifications would then be made to the selected protocol to fit it 892 exactly into the IPFIX architecture. 894 8.1 The IPFIX Basis Protocol 896 The working group went through an extensive evaluation of the various 897 existing protocols that were available, weighing the level of 898 compliance with the requirements, and selected one of the candidates 899 as the basis for the IPFIX protocol. For more details of the 900 evaluation process please see IPFIX-EVAL [5]. 902 In the basis protocol Flow Records are defined by Templates, where a 903 Template is an ordered set of the Information Elements appearing in a 904 Flow Record, together with their field sizes within those records. 906 This approach provides the following advantages: 908 o Using the Template mechanism, new fields can be added to IPFIX 909 Flow Records without changing the structure of the export record 910 format. 912 o Templates that are sent to the Collecting Process carry structural 913 information about the exported Flow Record fields. Therefore, if 914 the Collector does not understand the semantics of new fields it 915 can ignore them, but still interpret the Flow Record. 917 o Because the template mechanism is flexible, it allows the export 918 of only the required fields from the Flows to the Collecting 919 Process. This helps to reduce the exported Flow data volume and 920 possibly provide memory savings at the Exporting Process and 921 Collecting Process. Sending only the required information can 922 also reduce network load. 924 8.2 IPFIX Protocol on the Collecting Process 926 The Collecting process is responsible for: 928 1. Receiving and decoding Flow Records from the IPFIX Devices. 930 2. Indicating Flow Record losses to the IPFIX Collecting Process. 932 Complete details of the IPFIX protocol are given in IPFIX-PROTO [3]. 934 8.3 Support for Applications 936 Applications that use the information collected by IPFIX may be 937 Billing or Intrusion Detection sub-systems, etc. These applications 938 may be an integral part of the Collecting Process or they may be 939 co-located with the Collecting Process. The way by which these 940 applications interface with IPFIX system to get the desired 941 information is out of scope for this document. 943 9. Export Models 945 9.1 Export with Reliable Control Connection 947 As mentioned in the IPFIX-REQS [1] document, an IPFIX Device must be 948 able to transport its Control Information and Data Stream over a 949 congestion-aware transport protocol. 951 If the network in which the IPFIX Device and Collecting Process are 952 located does not guarantee reliability, at least the Control 953 Information should be exported over a reliable transport. The Data 954 Stream may be exported over a reliable or unreliable transport 955 protocol. 957 Possible transport protocols include: 959 o SCTP: Supports reliable and unreliable transport. 961 o TCP: Provides reliable transport only. 963 o UDP: Provides unreliable transport only. Network operators would 964 need to avoid congestion by keeping traffic within their own 965 administrative domains. 967 9.2 Collector Failure Detection and Recovery 969 The transport connection (in the case of a connection oriented 970 protocol) is pre-configured between the IPFIX Device and the 971 Collector. The IPFIX protocol does not provide any mechanism for 972 configuring the Metering or Exporting Processes. 974 Once connected, an IPFIX Collector receives Control Information and 975 uses that information to interpret Flow Records. The IPFIX Device 976 should set a keepalive (e.g. the keepalive timeout in the case of 977 TCP, the HEARTBEAT interval in the case of SCTP) to a sufficiently 978 low value so that it can quickly detect a Collector failure. 980 Collector failure refers to the crash or restart of the Collecting 981 Process, or of the Collector itself. A Collector failure is detected 982 at the IPFIX Device by the break in the connection oriented transport 983 protocol session: depending on the transport protocol - the 984 connection timeout mechanisms differ. On detecting a keepalive 985 timeout, the IPFIX Device should stop sending the Flow Record export 986 data to the Collector and try to reestablish the transport 987 connection. This is valid for a single Collector scenario. If 988 Collecting Process failover is supported by the Exporting Process the 989 backup session may be opened in advance. 991 There could be one or more secondary Collectors with priority 992 assigned to them. The primary Collector crash is detected at the 993 IPFIX Device by the break in control connection (depending on the 994 transport protocol - the connection timeout mechanisms differ). On 995 detecting loss of connectivity, the IPFIX Device opens a Data Stream 996 with the secondary Collector of the next highest priority. That 997 Collector might become the primary, or the Exporting Process might 998 try to reestablish the original session. 1000 9.3 Collector Redundancy 1002 Configuring redundant Collectors is an alternative to configuring 1003 backup Collectors. In this model, all Collectors simultaneously 1004 receive the Control Information and Data Streams. Multiple {Control 1005 Information, Data Stream} pairs could be set up, each to a different 1006 Collector from the same IPFIX Device. Since the IPFIX protocol 1007 requires a congestion-aware transport, achieving redundancy using 1008 multicast is not an option. 1010 10. IPFIX Flow Collection in Special Situations 1012 An IPFIX Device could be doing one or more of generating, receiving, 1013 altering special types of traffic which are listed below. 1015 Tunnel traffic: 1017 The IPFIX Device could be the head, midpoint or endpoint of a 1018 tunnel. In such cases the IPFIX Device could be handling GRE, 1019 IPinIP or UTI traffic. 1021 VPN traffic: 1023 The IPFIX Device could be a provider edge device which receives 1024 traffic from customer sites belonging to different Virtual Private 1025 Networks. 1027 Similarly, IPFIX could be implemented on devices which perform one or 1028 more of the following special services: 1030 o Explicitly drop packets. For example a device which provides 1031 firewall service drops packets based on some administrative 1032 policy. 1034 o Alter the values of fields used as IPFIX Flow Keys of interest. 1035 For example a device which provides NAT service can change source 1036 and/or destination IP address. 1038 In cases such as those listed above, there should be clear guidelines 1039 as to: 1041 o How and when to classify the packets as Flows in the IPFIX Device. 1043 o If multiple encapsulations are used to define Flows, how to convey 1044 the same fields (e.g. IP address) in different layers. 1046 o How to differentiate Flows based on different private domains. 1047 For example, overlapping IP addresses in Layer-3 VPNs. 1049 o What extra information needs be exported so that the Collector can 1050 make a clear interpretation of the received Flow Records. 1052 11. Security Considerations 1054 Flow information can be used for various purposes, such as usage 1055 accounting, traffic profiling, traffic engineering, and intrusion 1056 detection. The security requirement may differ significantly for 1057 such applications. To be able to satisfy the security needs of 1058 various IPFIX users, an IPFIX system must provide different levels of 1059 security protection. 1061 11.1 Data Security 1063 IPFIX data comprises Control Information and Data Stream generated by 1064 the IPFIX Device. 1066 The IPFIX data may exist in both the IPFIX Device and the Collector. 1067 In addition, the data is also transferred on the wire from the IPFIX 1068 Device to the Collector when it is exported. To provide security, 1069 the data should be protected from common network attacks. 1071 The protection of IPFIX data within the end system (IPFIX Device and 1072 Collector) is out of scope for this document. It is assumed that the 1073 end system operator will provide adequate security for the IPFIX 1074 data. 1076 The IPFIX architecture must allow different levels of protection to 1077 the IPFIX data on the wire. Wherever security functions are required 1078 it is recommended that users should leverage lower layers using 1079 either IPSEC or TLS, if these can successfully satisfy the security 1080 requirement of IPFIX data protection. 1082 To protect the data on the wire, three levels of granularity should 1083 be supported .. 1085 11.1.1 Host-Based Security 1087 Security may not be required when the transport between the IPFIX 1088 Device and the Collector is perceived as safe. This option allows 1089 the protocol to run most efficiently without extra overhead and an 1090 IPFIX system must support it. 1092 11.1.2 Authentication-only 1094 Authentication-only protection provides IPFIX users with the 1095 assurance of data integrity and authenticity. The data exchanged 1096 between the IPFIX Device and the Collector is protected by an 1097 authentication signature. Any modification of the IPFIX data will be 1098 detected by the recipient, resulting in discarding of the received 1099 data. However, the authentication-only option doesn't offer data 1100 confidentiality. 1102 The IPFIX user should not use authentication-only when sensitive or 1103 confidential information is being exchanged. An IPFIX solution 1104 should support this option. The authentication-only option should 1105 provide replay attack protection. Some means to achieve this level 1106 of security are: 1108 o TCP with MD5 options. 1110 o IP Authentication Header 1112 11.1.3 Encryption 1114 Data encryption provides the best protection for IPFIX data. The 1115 IPFIX data is encrypted at the sender and only the intended recipient 1116 can decrypt and have access to the data. This option must be used 1117 when the transport between the IPFIX Device and the Collector are 1118 unsafe and the IPFIX data needs to be protected. It is recommended 1119 that the underlying transport layer's security functions be used for 1120 this purpose. Some means to achieve this level of security are: 1122 o Encapsulating Security Payload. 1124 o Transport Layer Security Protocol 1126 The data encryption option adds overhead to the IPFIX data transfer. 1127 It may limit the rate that an Exporter can report its Flow Record to 1128 the Collector due to the resource requirement for running encryption. 1130 11.2 IPFIX End-point Authentication 1132 It is important to make sure that the IPFIX Device is talking to the 1133 "right" Collector rather than to a masquerading Collector. The same 1134 logic also holds true from the Collector point of view, i.e. it may 1135 want to make sure it is collecting the Flow Records from the "right" 1136 IPFIX Device. An IPFIX system should allow the end point 1137 authentication capability so that either one-way or mutual 1138 authentication can be performed between the IPFIX Device and 1139 Collector. 1141 The IPFIX architecture should use any existing transport protection 1142 protocols such as TLS or IPSEC to fulfill the authentication 1143 requirement. 1145 12. IPFIX Overload 1147 An IPFIX Device could become overloaded under various conditions. 1148 This may be because of exhaustion of internal resources used for Flow 1149 generation and/or export. Such overloading may cause loss of data 1150 from the Exporting Process, either from lack of export bandwidth 1151 (possibly caused by an unusually high number of observed Flows) or 1152 from network congestion in the path from Exporter to Collector. 1154 IPFIX Collectors should be able to detect the loss of exported Flow 1155 Records, and should at least record the number of lost Flow Records. 1157 12.1 Denial of Service (DoS) Attack Prevention 1159 Since one of the potential usages for IPFIX is for intrusion 1160 detection, it is important for the IPFIX architecture to support some 1161 kind of DoS resistance. 1163 12.1.1 Network Under Attack 1165 The Network itself may be under attack, resulting in an overwhelming 1166 number of IPFIX Messages. An IPFIX system should try to capture as 1167 much information as possible. However, when a large number of IPFIX 1168 Messages are generated in a short period of time, the IPFIX system 1169 may become overloaded. 1171 12.1.2 Generic DoS Attack on the IPFIX Device and Collector 1173 The IPFIX Device and Collector may be subject to generic DoS attacks, 1174 just as any system on any open network. These types of attacks are 1175 not IPFIX specific. Preventing and responding to such types of 1176 attacks are out of the scope of this document. 1178 12.1.3 IPFIX Specific DoS Attack 1180 There are some specific attacks on the IPFIX portion of the IPFIX 1181 Device or Collector. 1183 o The attacker could overwhelm the Collector with spoofed IPFIX 1184 export packets. One way to solve this problem is to periodically 1185 synchronize the sequence numbers of the Flow Records between the 1186 Exporting and Collecting Processes. 1188 o The attacker could provide false reports to the Collector by 1189 sending spoofed packets. 1191 The problems mentioned above can be solved to a large extent if the 1192 control packets are encrypted both ways. 1194 13. IANA Considerations 1196 The IPFIX Architecture, as set out in this document, has two sets of 1197 assigned numbers. Considerations for assigning them are discussed in 1198 this section, using the example policies as set out in the 1199 "Guidelines for IANA Considerations" document IANA-RFC [6]. 1201 13.1 Numbers used in the Protocol 1203 IPFIX Messages, as described in IPFIX-PROTO [3], use two fields with 1204 assigned values. These are the IPFIX Version Number, indicating 1205 which version of the IPFIX Protocol was used to export an IPFIX 1206 Message, and the IPFIX Template Number, indicating the type for each 1207 set of information within an IPFIX message. 1209 Changes in either IPFIX Version Number or IPFIX Template Number 1210 assignments require an IETF Consensus, i.e. they are to be made via 1211 RFCs approved by the IESG. 1213 13.2 Numbers used in the Information Model 1215 Fields of the IPFIX protocol carry information about traffic 1216 measurement. They are modeled as elements of the IPFIX information 1217 model IPFIX-INFO [2]. Each Information Element describes a field 1218 which may appear in an IPFIX Message. Within an IPFIX message the 1219 field type is indicated by its Field Type. 1221 Changes in IPFIX Field Type will be administered by IANA, subject to 1222 Expert Review, i.e. review by one of a group of experts designated 1223 by an IETF Operations and Management Area Director. Those experts 1224 will initially be drawn from the Working Group Chairs and document 1225 editors of the IPFIX and PSAMP Working Groups. 1227 14. Acknowledgements 1229 The document editors wish to thank all the people contributing to the 1230 discussion of this document on the mailing list, and the design teams 1231 for many valuable comments. In particular, the following made 1232 significant contributions: 1234 Tanja Zseby 1235 Paul Calato 1236 Dave Plonka 1237 Jeffrey Meyer 1238 K.C.Norseth 1239 Vamsi Valluri 1240 Cliff Wang 1241 Ram Gopal 1242 Jc Martin 1243 Carter Bullard 1244 Reinaldo Penno 1245 Simon Leinen 1246 Kevin Zhang 1247 Paul Aitken 1249 Special thanks to Dave Plonka for the multiple thorough reviews. 1251 15. References 1253 15.1 Normative References 1255 [1] Quittek, J., Zseby, T., Claise, B. and S. Zander, "Requirements 1256 for IP Flow Information Export", RFC RFC 3917, October 2004. 1258 [2] Meyer, J., Quittek, J. and S. Bryant, "IPFIX: Information 1259 Model", (work in progress), Internet Draft, 1260 draft-ietf-ipfix-info-06.txt, October 2004. 1262 [3] Claise, B., Bryant, S., Sadasivan, G. and M. Fullmer, "IPFIX: 1263 Protocol", (work in progress), Internet Draft, 1264 draft-ietf-ipfix-protocol-07.txt, December 2004. 1266 [4] Zseby, T., Boschi, E., Penno, R., Brownlee, N. and B. Claise, 1267 "IPFIX: Protocol", (work in progress), Internet Draft, 1268 draft-ietf-ipfix-protocol-03.txt, October 2004. 1270 15.2 Non-normative References 1272 [5] Leinen, S., "Evaluation of Candidate Protocols for IP Flow 1273 Information Export", RFC 3955, October 2004. 1275 [6] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1276 Considerations Section in RFCs", RFC 2434, October 1998. 1278 Authors' Addresses 1280 Ganesh Sadasivan 1281 Cisco Systems, Inc. 1282 170 West Tasman Drive 1283 San Jose, CA 95134 1284 USA 1286 Phone: +1 408 527-0251 1287 Email: gsadasiv@cisco.com 1289 Nevil Brownlee 1290 CAIDA | The University of Auckland 1291 Private Bag 92019 1292 Auckland 1293 New Zealand 1295 Phone: +64 9 373 7599 x8941 1296 Email: n.brownlee@auckland.ac.nz 1298 Benoit Claise 1299 Cisco Systems, Inc. 1300 De Kleetlaan 6a b1 1301 1831 Diegem 1302 Belgium 1304 Phone: +32 2 704 5622 1305 Email: bclaise@cisco.com 1307 Juergen Quittek 1308 NEC Europe Ltd. 1309 Adenauerplatz 6 1310 69225 Heidelberg 1311 Germany 1313 Phone: +49 6221 90511-15 1314 Email: quittek@ccrle.nec.de 1316 Intellectual Property Statement 1318 The IETF takes no position regarding the validity or scope of any 1319 Intellectual Property Rights or other rights that might be claimed to 1320 pertain to the implementation or use of the technology described in 1321 this document or the extent to which any license under such rights 1322 might or might not be available; nor does it represent that it has 1323 made any independent effort to identify any such rights. Information 1324 on the procedures with respect to rights in RFC documents can be 1325 found in BCP 78 and BCP 79. 1327 Copies of IPR disclosures made to the IETF Secretariat and any 1328 assurances of licenses to be made available, or the result of an 1329 attempt made to obtain a general license or permission for the use of 1330 such proprietary rights by implementers or users of this 1331 specification can be obtained from the IETF on-line IPR repository at 1332 http://www.ietf.org/ipr. 1334 The IETF invites any interested party to bring to its attention any 1335 copyrights, patents or patent applications, or other proprietary 1336 rights that may cover technology that may be required to implement 1337 this standard. Please address the information to the IETF at 1338 ietf-ipr@ietf.org. 1340 The IETF has been notified of intellectual property rights claimed in 1341 regard to some or all of the specification contained in this 1342 document. For more information consult the online list of claimed 1343 rights. 1345 Disclaimer of Validity 1347 This document and the information contained herein are provided on an 1348 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1349 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1350 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1351 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1352 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1353 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1355 Copyright Statement 1357 Copyright (C) The Internet Society (2005). This document is subject 1358 to the rights, licenses and restrictions contained in BCP 78, and 1359 except as set forth therein, the authors retain all their rights. 1361 Acknowledgment 1363 Funding for the RFC Editor function is currently provided by the 1364 Internet Society.