idnits 2.17.1 draft-ietf-ipfix-architecture-12.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 1358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1348. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 788 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 (September 6, 2006) is 6414 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') Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 7 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: March 10, 2007 CAIDA | The University of Auckland 6 B. Claise 7 Cisco Systems, Inc. 8 J. Quittek 9 NEC Europe Ltd. 10 September 6, 2006 12 Architecture for IP Flow Information Export 13 draft-ietf-ipfix-architecture-12 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 March 10, 2007. 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 . . . . . . . . . . . . . . . . . . . 11 58 5. IPFIX Functional and Logical Blocks . . . . . . . . . . . . 12 59 5.1 Metering Process . . . . . . . . . . . . . . . . . . . . . 12 60 5.1.1 Flow Expiration . . . . . . . . . . . . . . . . . . . 13 61 5.1.2 Flow Export . . . . . . . . . . . . . . . . . . . . . 13 62 5.2 Observation Point . . . . . . . . . . . . . . . . . . . . 14 63 5.3 Selection Criteria for Packets . . . . . . . . . . . . . . 14 64 5.3.1 Sampling Functions, Si . . . . . . . . . . . . . . . . 15 65 5.3.2 Filter Functions, Fi . . . . . . . . . . . . . . . . . 15 66 5.4 Observation Domain . . . . . . . . . . . . . . . . . . . . 16 67 5.5 Exporting Process . . . . . . . . . . . . . . . . . . . . 16 68 5.6 Collecting Process . . . . . . . . . . . . . . . . . . . . 16 69 5.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 6. Overview of the IPFIX Protocol . . . . . . . . . . . . . . . 18 71 6.1 Information Model Overview . . . . . . . . . . . . . . . . 19 72 6.2 Flow Records . . . . . . . . . . . . . . . . . . . . . . . 19 73 6.3 Control Information . . . . . . . . . . . . . . . . . . . 20 74 6.4 Reporting Responsibilities . . . . . . . . . . . . . . . . 21 75 7. IPFIX Protocol Details . . . . . . . . . . . . . . . . . . . 21 76 7.1 The IPFIX Basis Protocol . . . . . . . . . . . . . . . . . 21 77 7.2 IPFIX Protocol on the Collecting Process . . . . . . . . . 22 78 7.3 Support for Applications . . . . . . . . . . . . . . . . . 22 79 8. Export Models . . . . . . . . . . . . . . . . . . . . . . . 22 80 8.1 Export with Reliable Control Connection . . . . . . . . . 22 81 8.2 Collector Failure Detection and Recovery . . . . . . . . . 23 82 8.3 Collector Redundancy . . . . . . . . . . . . . . . . . . . 24 83 9. IPFIX Flow Collection in Special Situations . . . . . . . . 24 84 10. Security Considerations . . . . . . . . . . . . . . . . . . 25 85 10.1 Data Security . . . . . . . . . . . . . . . . . . . . . 25 86 10.1.1 Host-Based Security . . . . . . . . . . . . . . . . 25 87 10.1.2 Authentication-only . . . . . . . . . . . . . . . . 26 88 10.1.3 Encryption . . . . . . . . . . . . . . . . . . . . . 26 89 10.2 IPFIX End-point Authentication . . . . . . . . . . . . . 26 90 10.3 IPFIX Overload . . . . . . . . . . . . . . . . . . . . . 27 91 10.3.1 Denial of Service (DoS) Attack Prevention . . . . . 27 92 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 93 11.1 Numbers used in the Protocol . . . . . . . . . . . . . . 28 94 11.2 Numbers used in the Information Model . . . . . . . . . 28 95 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 96 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 97 13.1 Normative References . . . . . . . . . . . . . . . . . . 29 98 13.2 Informative References . . . . . . . . . . . . . . . . . 29 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 100 A. Changes/Issues from the -11 Draft . . . . . . . . . . . . . 30 101 Intellectual Property and Copyright Statements . . . . . . . 32 103 1. Introduction 105 There are several applications e.g., usage-based accounting, traffic 106 profiling, traffic engineering, attack/intrusion detection, QoS 107 monitoring, that require flow-based IP traffic measurements. It is 108 therefore important to have a standard way of exporting information 109 related to IP flows. This document defines an architecture for IP 110 traffic flow monitoring, measuring and exporting. It provides a 111 high-level description of an IPFIX device's key components and their 112 functions. 114 1.1 Document Scope 116 This document defines the architecture for IPFIX. Its main 117 objectives are to: 119 o Describe the key IPFIX architectural components, consisting of (at 120 least) IPFIX devices and collectors communicating using the IPFIX 121 protocol. 123 o Define the IPFIX architectural requirements, e.g., recovery, 124 security, etc. 126 o Describe the characteristics of the IPFIX protocol. 128 1.2 IPFIX Documents Overview 130 The IPFIX protocol provides network administrators with access to IP 131 flow information. This document specifies the architecture for the 132 export of measured IP flow information from an IPFIX exporting 133 process to a collecting process, per the requirements defined in 134 IPFIX-REQS [1]. The IPFIX protocol document IPFIX-PROTO [3] 135 specifies how IPFIX data records and templates are carried via a 136 congestion-aware transport protocol from IPFIX exporting process to 137 IPFIX collecting process. IPFIX has a formal description of IPFIX 138 information elements (fields), their name, type and additional 139 semantic information, as specified in IPFIX-INFO [2]. Finally 140 IPFIX-AS [4] describes what type of applications can use the IPFIX 141 protocol and how they can use the information provided. It 142 furthermore shows how the IPFIX framework relates to other 143 architectures and frameworks. 145 Note that the IPFIX system does not provide for remote configuration 146 of an IPFIX device. Instead, implementors must provide an effective 147 way to configure their IPFIX devices. 149 2. Terminology 151 The definitions of basic IPFIX terms such as IP Traffic Flow, 152 Exporting Process, Collecting Process, Observation Point, etc. are 153 semantically identical with those found in the IPFIX requirements 154 document IPFIX-REQS [1]. Some of the terms have been expanded for 155 more clarity when defining the protocol. Additional definitions 156 required for the architecture have also been defined. For the same 157 terms defined here and in IPFIX-PROTO [3] the definitions are 158 equivalent in both documents. 160 * Observation Point 162 An Observation Point is a location in the network where IP packets 163 can be observed. Examples include: a line to which a probe is 164 attached, a shared medium, such as an Ethernet-based LAN, a single 165 port of a router, or a set of interfaces (physical or logical) of 166 a router. 168 Note that every Observation Point is associated with an 169 Observation Domain (defined below), and that one Observation Point 170 may be a superset of several other Observation Points. For 171 example one Observation Point can be an entire line card. That 172 would be the superset of the individual Observation Points at the 173 line card's interfaces. 175 * Observation Domain 177 An Observation Domain is the largest set of Observation Points for 178 which Flow information can be aggregated by a Metering Process. 179 For example, a router line card may be an observation domain if it 180 is composed of several interfaces, each of which is an Observation 181 Point. Each Observation Domain presents itself to the Collecting 182 Process using an Observation Domain ID to identify the IPFIX 183 Messages it generates. Every Observation Point is associated with 184 an Observation Domain. It is recommended that Observation Domain 185 IDs are also unique per IPFIX Device. 187 * IP Traffic Flow or Flow 189 There are several definitions of the term 'flow' being used by the 190 Internet community. Within the context of IPFIX we use the 191 following definition: 193 A Flow is defined as a set of IP packets passing an Observation 194 Point in the network during a certain time interval. All packets 195 belonging to a particular Flow have a set of common properties. 196 Each property is defined as the result of applying a function to 197 the values of: 199 1. One or more packet header fields (e.g. destination IP 200 address), transport header fields (e.g. destination port 201 number), or application header field (e.g. RTP header fields) 202 RTP-HDRF [5]. 204 2. One or more characteristics of the packet itself (e.g. number 205 of MPLS labels) 207 3. One or more fields derived from packet treatment (e.g. next 208 hop IP address, output interface) 210 A packet is said to belong to a Flow if it completely satisfies 211 all the defined properties of the Flow. 213 This definition covers the range from a Flow containing all 214 packets observed at a network interface to a Flow consisting of 215 just a single packet between two applications. It includes 216 packets selected by a sampling mechanism. 218 * Flow Key 220 Each of the fields which 222 1. Belong to the packet header (e.g. destination IP address) 224 2. Are a property of the packet itself (e.g. packet length) 226 3. Are derived from packet treatment (e.g. AS number) 228 and which are used to define a Flow are termed Flow Keys. 230 * Flow Record 232 A Flow Record contains information about a specific Flow that was 233 observed at an Observation Point. A Flow Record contains measured 234 properties of the Flow (e.g. the total number of bytes for all the 235 Flow's packets) and usually characteristic properties of the Flow 236 (e.g. source IP address). 238 * Metering Process 240 The Metering Process generates Flow Records. Inputs to the 241 process are packet headers and characteristics observed at an 242 Observation Point, and packet treatment at the Observation Point 243 (for example the selected output interface). 245 The Metering Process consists of a set of functions that includes 246 packet header capturing, timestamping, sampling, classifying, and 247 maintaining Flow Records. 249 The maintenance of Flow Records may include creating new records, 250 updating existing ones, computing Flow statistics, deriving 251 further Flow properties, detecting Flow expiration, passing Flow 252 Records to the Exporting Process, and deleting Flow Records. 254 * Exporting Process 256 An Exporting Process sends Flow Records to one or more Collecting 257 Processes. The Flow Records are generated by one or more Metering 258 Processes. 260 * Exporter 262 A device which hosts one or more Exporting Processes is termed an 263 Exporter. 265 * IPFIX Device 267 An IPFIX Device hosts at least one Exporting Process. It may host 268 further Exporting processes and arbitrary numbers of Observation 269 Points and Metering Process. 271 * Collecting Process 273 A Collecting Process receives Flow Records from one or more 274 Exporting Processes. The Collecting Process might process or 275 store received Flow Records, but such actions are out of scope for 276 this document. 278 * Collector 280 A device which hosts one or more Collecting Processes is termed a 281 Collector. 283 * Template 285 A Template is an ordered sequence of pairs, used to 286 completely specify the structure and semantics of a particular set 287 of information that needs to be communicated from an IPFIX Device 288 to a Collector. Each Template is uniquely identifiable by means 289 of a Template ID. 291 * Control Information, Data Stream 293 The information that needs to be exported from the IPFIX Device 294 can be classified into the following categories: 296 Control Information 298 This includes the Flow definition, selection criteria for 299 packets within the Flow sent by the Exporting Process, and 300 templates describing the data to be exported. Control 301 Information carries all the information needed for the end- 302 points to understand the IPFIX protocol, and specifically for 303 the Collector to understand and interpret the data sent by the 304 sending Exporter. 306 Data Stream 308 This includes Flow Records carrying the field values for the 309 various observed Flows at each of the Observation Points. 311 IPFIX Message 313 An IPFIX Message is a message originating at the Exporting Process 314 that carries the IPFIX records of this Exporting Process and whose 315 destination is a Collecting Process. An IPFIX Message is 316 encapsulated at the transport layer. 318 Information Element 320 An Information Element is a protocol and encoding independent 321 description of an attribute which may appear in an IPFIX Record. 322 The IPFIX information model IPFIX-INFO [2] defines the base set of 323 Information Elements for IPFIX. The type associated with an 324 Information Element indicates constraints on what it may contain 325 and also determines the valid encoding mechanisms for use in 326 IPFIX. 328 3. Examples of Flows 330 Some examples of Flows are listed below. In the IPv4 examples we use 331 interface addresses in three different 26-bit (/26) subnets. In the 332 IPv6 examples we use 'mac addr-nn' in the low-order 64 bits to 333 indicate the IEEE MAC address of host interface nn. 335 Example 1: Flow Keys define the different fields by which Flows are 336 distinguished. The different combination of their field values 337 creates unique Flows. If {source IP address, destination IP address, 338 DSCP} are flow keys, then all of these are different Flows: 340 1. {192.0.2.1, 192.0.2.65, 4} 341 2. {192.0.2.23, 192.0.2.67, 4} 342 3. {192.0.2.23, 192.0.2.67, 2} 343 4. {192.0.2.129, 192.0.2.67, 4} 345 5. {2001:DB8::0:mac-addr-01, 2001:DB8::1:mac-addr-11, 4} 346 6. {2001:DB8::0:mac-addr-02, 2001:DB8::1:mac-addr-13, 4} 347 7. {2001:DB8::0:mac-addr-02, 2001:DB8::1:mac-addr-13, 2} 348 8. {2001:DB8::2:mac-addr-21, 2001:DB8::1:mac-addr-13, 4} 350 Example 2: A mask function can be applied to all the packets that 351 pass through an Observation Point, in order to aggregate some values. 352 This could be done by defining the set of Flow Keys as {source IP 353 address, destination IP address, DSCP} as in example 1 above, and 354 applying functions which mask out the source and destination IP 355 addresses (least significant 6 bits for IPv4, 64 bits for IPv6). The 356 eight Flows from example 1 would now be aggregated into six Flows by 357 merging the Flows 1+2 and 5+6 into single Flows: 359 1. {192.0.2.0/26, 192.0.2.64/26, 4} 360 2. {192.0.2.0/26, 192.0.2.64/26, 2} 361 3. {192.0.2.128/26, 192.0.2.64/26, 4} 363 4. {2001:DB8::0/64, 2001:DB8::1/64, 4} 364 5. {2001:DB8::0/64, 2001:DB8::1/64, 2} 365 6. {2001:DB8::2/64, 2001:DB8::1/64, 4} 367 Example 3: A filter defined by some Flow Key values can be applied on 368 all packets that pass the Observation Point, in order to select only 369 certain Flows. The filter is defined by choosing fixed values for 370 specific Keys from the packet. 372 All the packets that go from a customer network 192.0.2.0/26 to 373 another customer network 192.0.2.64/26 with DSCP value of 4 define a 374 Flow. All other combinations don't define a Flow and are not taken 375 into account. The three Flows from example 2 would now be reduced to 376 one Flow by filtering out Flows 2 and 3, leaving only Flow 1, 377 {192.0.2.0/26, 192.0.2.64/26, 4}. 379 Similarly, for the IPv6 packets in the examples above, one could 380 filter out Flows 5 and 6 to leave Flow 4. 382 The above examples can be thought of as a function F() taking as 383 input {source IP address, destination IP address, DSCP}. The 384 function selects only the packets which satisfy all three of the 385 following conditions: 387 1. Mask out the least significant 6 bits of source IP address, match 388 against 192.0.2.0. 390 2. Mask out the least significant 6 bits of destination IP address, 391 match against 192.0.2.64. 393 3. Only accept DSCP value equal to 4. 395 Depending on the values of {source IP address, destination IP 396 address, DSCP} of the different observed packets, the Metering 397 Process function F() would choose/filter/aggregate different sets of 398 packets, which would create different Flows. For example, for 399 various combinations of values of {source IP address, destination IP 400 address, DSCP}, F(source IP address, destination IP address, DSCP) 401 would result in the definition of one or more Flows. 403 4. IPFIX Reference Model 405 The figure below shows the reference model for IPFIX. This figure 406 covers the various possible scenarios that can exist in an IPFIX 407 system. 409 +----------------+ +----------------+ 410 |[*Application 1]| ... |[*Application n]| 411 +--------+-------+ +-------+--------+ 412 ^ ^ 413 | | 414 + = = = = -+- = = = = + 415 ^ 416 | 417 +------------------------+ +-------+------------------+ 418 |IPFIX Exporter | | Collector(1) | 419 |[Exporting Process(es)] |<---------->| [Collecting Process(es)] | 420 +------------------------+ +--------------------------+ 421 .... .... 422 +------------------------+ +---------------------------+ 423 |IPFIX Device(i) | | Collector(j) | 424 |[Observation Point(s)] |<--------->| [Collecting Process(es)] | 425 |[Metering Process(es)] | +---->| [*Application(s)] | 426 |[Exporting Process(es)] | | +---------------------------+ 427 +------------------------+ . 428 .... . .... 429 +------------------------+ | +--------------------------+ 430 |IPFIX Device(m) | | | Collector(n) | 431 |[Observation Point(s)] |<----+---->| [Collecting Process(es)] | 432 |[Metering Process(es)] | | [*Application(s)] | 433 |[Exporting Process(es)] | +--------------------------+ 434 +------------------------+ 436 The various functional components are indicated within brackets []. 437 The functional components within [*] are not part of the IPFIX 438 architecture. The interfaces shown by "<----->" are defined by the 439 IPFIX architecture but those shown by "<= = = =>" are not. 441 Figure 3 443 The figure below shows a typical IPFIX Device where the IPFIX 444 components are shown in rectangular boxes. 446 +--------------------------------------------------+ 447 | IPFIX Device | 448 | +-----+ | 449 | +------- ... ------------+---------> | | 450 | | | | | | 451 | +----+----+ +----+----+ | | | 452 | |Metering | |Metering | | E | | 453 | |Process 1| |Process N| | x | | 454 | +---------+ +---------+ | p | | 455 | ^ ^ | o | | 456 | +------+--------+ +---------+------+ | r | | 457 | | Obsv Domain 1 | | Obsv Domain N | | t | | 458 | |+-----+-------+| |+-------+------+| | i | | 459 | ||Obsv Pt 1..j || ... ||Obsv Pt j+1..M|| | n | | 460 | |+-------------+| |+--------------+| | g | | Export 461 Packets | +------^--------+ +---------^------+ | | | packets 462 --->----+--------+---------- ... ---------+ | | | to 463 In | | +---------> 464 | . . . . . | | |Collector 465 | | | | 466 | +------ ... -------------+---------> | | 467 | | | | | | 468 | +----+----+ +----+----+ | P | | 469 | |Metering | |Metering | | r | | 470 | |Process 1| |Process N| | o | | 471 | +---------+ +---------+ | c | | 472 | ^ ^ | e | | 473 | +------+--------+ +---------+------+ | s | | 474 | | Obsv Domain 1 | | Obsv Domain N | | s | | 475 | |+-----+-------+| |+-------+------+| | | | 476 | ||Obsv Pt 1..k || ... ||Obsv Pt k+1..M|| | | | 477 | |+-------------+| |+--------------+| | | | 478 Packets | +------^--------+ +---------^------+ +-----+ | 479 --->----+--------+---------- ... ---------+ | 480 In | | 481 +--------------------------------------------------+ 483 Figure 4 485 5. IPFIX Functional and Logical Blocks 487 5.1 Metering Process 489 Every Observation Point in an IPFIX Device, participating in Flow 490 measurements, must be associated with at least one Metering Process. 491 Every packet coming into an Observation Point goes into each of the 492 Metering Processes associated with the Observation Point. Broadly, 493 each Metering Process observes the packets that pass an Observation 494 Point, does timestamping and classifies the packets into Flow(s) 495 based on the selection criteria. 497 The Metering Process is a functional block which manages all the 498 Flows generated from an Observation Domain. The typical functions of 499 a Metering Process may include: 501 o Maintain database(s) of all the Flow Records from an Observation 502 Domain. This includes creating new Flow Records, updating 503 existing ones, computing Flow Records statistics, deriving further 504 Flow properties, adding non-flow-specific information based on the 505 packet treatment (in some cases fields like AS numbers, router 506 state, etc.) 508 o Maintain statistics about the Metering Process itself, such as 509 Flow Records generated, packets observed, etc. 511 5.1.1 Flow Expiration 513 A Flow is considered to have expired under the following conditions: 515 1. If no packets belonging to the Flow have been observed for a 516 certain period of time. This time period should be configurable 517 at the Metering Process, with a minimum value of 0 seconds for 518 immediate expiration. Note that a zero timeout would report a 519 Flow as a sequence of single-packet Flows. 521 2. If the IPFIX Device experiences resource constraints, a Flow may 522 be prematurely expired (e.g. lack of memory to store Flow 523 Records) 525 3. For long-running Flows, the Metering Process should expire the 526 Flow on a regular basis or based on some expiration policy. This 527 periodicity or expiration policy should be configurable at the 528 Metering Process. When a long-running Flow is expired, its Flow 529 Record may still be maintained by the Metering Process so that 530 the Metering Process does not need to create a new Flow Record 531 for further observed packets of the same Flow. 533 5.1.2 Flow Export 535 The Exporting Process decides when and whether to export an expired 536 Flow. A Flow can be exported because it expired for any of the 537 reasons mentioned in Flow Expiration section. For example: the 538 Exporting Process exports a portion of the expired Flows every 'x' 539 seconds. 541 For long-lasting Flows, the Exporting Process should export the Flow 542 Records on a regular basis or based on some export policy. This 543 periodicity or export policy should be configurable at the Exporting 544 Process. 546 5.2 Observation Point 548 A Flow Record can be better analysed if the Observation Point from 549 which it was measured is known. As such it is recommended that IPFIX 550 Devices send this information to Collectors. In cases where there is 551 a single Observation Point or where the Observation Point information 552 is not relevant, the Metering Process may choose not to add the 553 Observation Point information to the Flow Records. 555 5.3 Selection Criteria for Packets 557 A Metering Process may define rules so that only certain packets 558 within an incoming stream of packets are chosen for measurement at an 559 Observation Point. This may be done by one of the two methods 560 defined below or a combination of them, in either order. A 561 combination of each of these methods can be adopted to select the 562 packets, i.e. one can define a set of methods {F1, S1, F2, S2, S3} 563 executed in a specified sequence at an Observation Point to select 564 particular Flows. 566 The figure below shows the operations which may be applied as part of 567 a typical Metering Process. 569 packet header capturing 570 | 571 timestamping 572 | 573 v 574 +----->+ 575 | | 576 | sampling Si (1:1 in case of no sampling) 577 | | 578 | filtering Fi (select all when no criteria) 579 | | 580 +------+ 581 | 582 v 583 Flows 585 Figure 5 587 Note that packets could be selected before or after any IP 588 processing, i.e., before there is any IP checksum validation, IP 589 filtering, etc, or after one or more of these steps. This has an 590 impact on what kinds of traffic (or erroneous conditions) IPFIX can 591 observe. It is recommended that packets are selected after their 592 checksums have been verified. 594 5.3.1 Sampling Functions, Si 596 A sampling function determines which packets within a stream of 597 incoming packets are selected for measurement, i.e. packets that 598 satisfy the sampling criteria for this Metering Process. 600 Example: sample every 100th packet that was received at an 601 Observation Point. 603 Choosing all the packets is a special case where the sampling rate is 604 1:1. 606 5.3.2 Filter Functions, Fi 608 A Filter Function selects only those incoming packets that satisfy a 609 function on fields defined by the packet header fields, fields 610 obtained while doing the packet processing, or properties of the 611 packet itself. 613 Example: Mask/Match of the fields that define a filter. A filter 614 might be defined as {Protocol == TCP, Destination Port < 1024}. 616 Several such filters could be used in any sequence to select packets. 618 Note that packets selected by a (sequence of) filter functions may be 619 further classified by other filter functions, i.e. the selected 620 packets may belong to several Flows, any or all of which are 621 exported. 623 5.4 Observation Domain 625 The Observation Domain is a logical block that presents a single 626 identity for a group of Observation Points within an IPFIX Device. 627 Each {Observation Point, Metering Process} pair belongs to a single 628 Observation Domain. An IPFIX Device could have multiple Observation 629 Domains, each of which has a subset of the total set of Observation 630 Points in it. Each Observation Domain must carry a unique ID within 631 the context of an IPFIX Device. Note that in case of multiple 632 Observation Domains, a unique ID per Observation Domain must be 633 transmitted as a parameter to the Exporting Function. That unique ID 634 is referred to as the IPFIX Observation Domain ID. 636 5.5 Exporting Process 638 The Exporting Process is the functional block that sends data to one 639 or more IPFIX Collectors using the IPFIX protocol. On one side the 640 Exporting Process interfaces with Metering Process(es) to get Flow 641 Records, while on the other side it talks to a Collecting Process on 642 the Collector(s). 644 There may be additional rules defined within an Observation Domain so 645 that only certain Flow Records are exported. This may be done by 646 either one or a combination of Si, Fi, as described in the section on 647 "Selection Criteria for Packets". 649 Example: Only the Flow Records which meet the following selection 650 criteria are exported: 652 1. All Flow Records whose destination IP address matches 653 {192.0.33.5}. 655 2. Every other (i.e. sampling rate 1 in 2) Flow Record whose 656 destination IP address matches {192.0.11.30}. 658 5.6 Collecting Process 660 Collecting Processes use a Flow Record's Template ID to interpret 661 that Flow Record's Information Elements. To allow this, an IPFIX 662 Exporter must ensure that an IPFIX Collector knows the Template ID 663 for each incoming Flow Record. To interpret incoming Flow Records, 664 an IPFIX Collector may also need to know the function F() that was 665 used by the Metering Process for each Flow. 667 The functions of the Collecting Process must include: 669 o Identifying, accepting and decoding the IPFIX Messages from 670 different pairs. 672 o Storing the Control Information and Flow Records received from an 673 IPFIX Device. 675 At a high level, the Collecting Process: 677 1. Receives and stores the Control Information. 679 2. Decodes and stores the Flow Records using the Control 680 Information. 682 5.7 Summary 684 The figure below shows the functions performed in sequence by the 685 various functional blocks in an IPFIX Device. 687 Packet(s) coming in to Observation Point(s) 688 | | 689 v v 690 +----------------+-------------------------+ +-----+-------+ 691 | Metering Process on an | | | 692 | Observation Point | | | 693 | | | | 694 | packet header capturing | | | 695 | | |...| Metering | 696 | timestamping | | Process N | 697 | | | | | 698 | +----->+ | | | 699 | | | | | | 700 | | sampling Si (1:1 in case of no | | | 701 | | | sampling) | | | 702 | | filtering Fi (select all when | | | 703 | | | no criteria) | | | 704 | +------+ | | | 705 | | | | | 706 | | Timing out Flows | | | 707 | | Handle resource overloads | | | 708 +--------|---------------------------------+ +-----|-------+ 709 | | 710 Flow Records (identified by Observation Domain) Flow Records 711 | | 712 +---------+---------------------------------+ 713 | 714 +--------------------|----------------------------------------------+ 715 | | Exporting Process | 716 |+-------------------|-------------------------------------------+ | 717 || v IPFIX Protocol | | 718 ||+-----------------------------+ +----------------------------+| | 719 |||Rules for | |Functions || | 720 ||| Picking/sending Templates | |-Packetise selected Control || | 721 ||| Picking/sending Flow Records|->| & data Information into || | 722 ||| Encoding Template & data | | IPFIX export packets. || | 723 ||| Selecting Flows to export(*)| |-Handle export errors || | 724 ||+-----------------------------+ +----------------------------+| | 725 |+----------------------------+----------------------------------+ | 726 | | | 727 | exported IPFIX Messages | 728 | | | 729 | +------------+-----------------+ | 730 | | Anonymise export packet(*) | | 731 | +------------+-----------------+ | 732 | | | 733 | +------------+-----------------+ | 734 | | Transport Protocol | | 735 | +------------+-----------------+ | 736 | | | 737 +-----------------------------+-------------------------------------+ 738 | 739 v 740 IPFIX export packet to Collector 742 (*) indicates that the block is optional. 744 Figure 6 746 6. Overview of the IPFIX Protocol 748 An IPFIX Device consists of a set of co-operating processes that 749 implement the functional blocks described in the previous section. 750 Alternatively, an IPFIX Device can be viewed simply as a network 751 entity which implements the IPFIX protocol. At the IPFIX Device, the 752 protocol functionality resides in the Exporting Process. The IPFIX 753 Exporting Process gets Flow Records from a Metering Process, and 754 sends them to the Collector(s). 756 At a high level, an IPFIX Device performs the following tasks: 758 1. Encode Control Information into Templates. 760 2. Encode packets observed at the Observation Points into Flow 761 Records. 763 3. Packetise the selected Templates and Flow Records into IPFIX 764 Messages. 766 4. Send IPFIX Messages to the Collector. 768 The IPFIX protocol communicates information from an IPFIX Exporter to 769 an IPFIX Collector. That information includes not only Flow Records, 770 but also information about the Metering Process. Such information 771 (referred to as Control Information) includes details of the data 772 fields in Flow Records. It may also include statistics from the 773 Metering Process, such as the number of packets lost (i.e. not 774 metered). 776 For details of the IPFIX protocol please refer to IPFIX-PROTO [3]. 778 6.1 Information Model Overview 780 The IP Flow Information eXport (IPFIX) protocol serves for 781 transmitting information related to measured IP traffic over the 782 Internet. The protocol specification in IPFIX-PROTO [3] defines how 783 Information Elements are transmitted. For Information Elements, it 784 specifies the encoding of a set of basic data types. However, the 785 list of fields that can be transmitted by the protocol, such as Flow 786 attributes (source IP address, number of packets, etc.) and 787 information about the Metering and Exporting Process (packet 788 Observation Point, sampling rate, Flow timeout interval, etc.), is 789 not specified in IPFIX-PROTO [3]. Instead, it is defined in the 790 IPFIX Information Model document IPFIX-INFO [2]. 792 The Information Model provides a complete description of the 793 properties of every IPFIX Information Element. It does this by 794 specifying each element's name, Field Type, data type, etc., and 795 providing a description of each element. Element descriptions give 796 the semantics of the element, i.e. say how it is derived from a Flow 797 or other information available within an IPFIX Device. 799 6.2 Flow Records 801 The following rules provide guidelines to be followed while encoding 802 the Flow Records information: 804 A Flow Record contains enough information so that the Collecting 805 Process can identify the corresponding . 808 The Exporting Process encodes a given Information Element (as 809 specified in IPFIX-INFO [2]), based on the encoding standards 810 prescribed by IPFIX-PROTO [3]. 812 6.3 Control Information 814 The following rules provide guidelines to be followed while encoding 815 the Control Information: 817 o Per-Flow Control Information should be encoded such that the 818 Collecting Process can capture the structure and semantics of the 819 corresponding Flow data for each of the Flow Records exported by 820 the IPFIX Device. 822 o Configuration Control Information is conveyed to a Collector so 823 that its Collecting Process can capture the structure and 824 semantics of the corresponding configuration data. The 825 configuration data which is also Control Information should carry 826 additional information on the Observation Domain within which the 827 configuration takes effect. 829 For example, sampling using the same sampling algorithm, say 1 in 100 830 packets, is configured on two Observation Points O1 and O2. The 831 configuration in this case may be encoded as {ID, configuration 832 domain (O1,O2), sampling algorithm, interval (1 in 100)}, where ID is 833 the Observation Domain ID for the domain containing O1 and O2. The 834 Observation Domain ID uniquely identifies this configuration, and 835 must be sent within the Flow Records in order to be able to match the 836 right configuration control information. 838 The Control Information is used by the Collecting Process to: 840 o Decode and interpret Flow Records. 842 o Understand the state of the Exporting Process. 844 Sending Control Information from the Exporting Process in a timely 845 and reliable manner is critical to the proper functioning of the 846 IPFIX Collecting Process. The following approaches may be taken for 847 the export of Control Information: 849 1. Send all the Control Information pertaining to Flow Records prior 850 to sending the Flow Records themselves. This includes any 851 incremental changes to the definition of the Flow Records. 853 2. Notify on a near real time basis the state of the IPFIX Device to 854 the Collecting Process. This includes all changes such as a 855 configuration change that affects the Flow behaviour, changes to 856 Exporting Process resources that alter export rates, etc., which 857 the Collector needs to be aware of. 859 3. Since it is vital that a Collecting Process maintains accurate 860 knowledge of the Exporter's state, the export of the Control 861 Information should be done such that it reaches the Collector 862 reliably. One way to achieve this is to send the Control 863 Information over a reliable transport. 865 6.4 Reporting Responsibilities 867 From time to time an IPFIX Device may not be able to observe all the 868 packets reaching one of its Observation Points. This could occur if 869 a Metering Process finds itself temporarily short of resources. For 870 example it might run out of packet buffers for IPFIX export. 872 In such situations, the IPFIX Device should attempt to count the 873 number of packet losses that have occurred, and report them to its 874 Collector(s). If it is not possible to count losses accurately, e.g. 875 when transport layer (i.e. non-IPFIX) errors are detected, the IPFIX 876 device should report this fact, and perhaps indicate the time period 877 during which some packets might not have been observed. 879 7. IPFIX Protocol Details 881 When the IPFIX Working Group was chartered there were existing common 882 practices in the area of Flow export, for example NetFlow, CRANE, 883 LFAP, RTFM, etc. IPFIX's charter required the Working Group to 884 consider those existing practices, and select the one that was the 885 closest fit to the IPFIX requirements IPFIX-REQS [1]. Additions or 886 modifications would then be made to the selected protocol to fit it 887 exactly into the IPFIX architecture. 889 7.1 The IPFIX Basis Protocol 891 The Working Group went through an extensive evaluation of the various 892 existing protocols that were available, weighing the level of 893 compliance with the requirements, and selected one of the candidates 894 as the basis for the IPFIX protocol. For more details of the 895 evaluation process please see IPFIX-EVAL [6]. 897 In the basis protocol Flow Records are defined by Templates, where a 898 Template is an ordered set of the Information Elements appearing in a 899 Flow Record, together with their field sizes within those records. 901 This approach provides the following advantages: 903 o Using the Template mechanism, new fields can be added to IPFIX 904 Flow Records without changing the structure of the export record 905 format. 907 o Templates that are sent to the Collecting Process carry structural 908 information about the exported Flow Record fields. Therefore, if 909 the Collector does not understand the semantics of new fields it 910 can ignore them, but still interpret the Flow Record. 912 o Because the template mechanism is flexible, it allows the export 913 of only the required fields from the Flows to the Collecting 914 Process. This helps to reduce the exported Flow data volume and 915 possibly provide memory savings at the Exporting Process and 916 Collecting Process. Sending only the required information can 917 also reduce network load. 919 7.2 IPFIX Protocol on the Collecting Process 921 The Collecting Process is responsible for: 923 1. Receiving and decoding Flow Records from the IPFIX Devices. 925 2. Reporting on the loss of Flow Records sent to the Collecting 926 Process by an IPFIX Exporting Process. 928 Complete details of the IPFIX protocol are given in IPFIX-PROTO [3]. 930 7.3 Support for Applications 932 Applications that use the information collected by IPFIX may be 933 Billing or Intrusion Detection sub-systems, etc. These applications 934 may be an integral part of the Collecting Process or they may be co- 935 located with the Collecting Process. The way by which these 936 applications interface with IPFIX systems to get the desired 937 information is out of scope for this document. 939 8. Export Models 941 8.1 Export with Reliable Control Connection 943 As mentioned in the IPFIX-REQS [1] document, an IPFIX Device must be 944 able to transport its Control Information and Data Stream over a 945 congestion-aware transport protocol. 947 If the network in which the IPFIX Device and Collecting Process are 948 located does not guarantee reliability, at least the Control 949 Information should be exported over a reliable transport. The Data 950 Stream may be exported over a reliable or unreliable transport 951 protocol. 953 Possible transport protocols include: 955 o SCTP: Supports reliable and unreliable transport. 957 o TCP: Provides reliable transport only. 959 o UDP: Provides unreliable transport only. Network operators would 960 need to avoid congestion by keeping traffic within their own 961 administrative domains. For example, one could use a dedicated 962 network (or Ethernet link) to carry IPFIX traffic from Exporter to 963 Collector. 965 8.2 Collector Failure Detection and Recovery 967 The transport connection (in the case of a connection oriented 968 protocol) is pre-configured between the IPFIX Device and the 969 Collector. The IPFIX protocol does not provide any mechanism for 970 configuring the Exporting and Collecting Processes. 972 Once connected, an IPFIX Collector receives Control Information and 973 uses that information to interpret Flow Records. The IPFIX Device 974 should set a keepalive (e.g. the keepalive timeout in the case of 975 TCP, the HEARTBEAT interval in the case of SCTP) to a sufficiently 976 low value so that it can quickly detect a Collector failure. Note, 977 however, that extremely short keepalive intervals can incorrectly 978 abort the connection during transient periods of congestion. They 979 can also cause some level of additional network load during otherwise 980 idle periods. 982 Collector failure refers to the crash or restart of the Collecting 983 Process, or of the Collector itself. A Collector failure is detected 984 at the IPFIX Device by the break in the connection oriented transport 985 protocol session, depending on the transport protocol - the 986 connection timeout mechanisms differ. On detecting a keepalive 987 timeout in a single Collector scenario, the IPFIX Device should stop 988 sending Flow Records to the Collector and try to reestablish the 989 transport connection. If Collecting Process failover is supported by 990 the Exporting Process, backup session(s) may be opened in advance, 991 and Control Information sent to it. 993 There could be one or more secondary Collectors with priority 994 assigned to them. The primary Collector crash is detected at the 995 IPFIX Device. On detecting loss of connectivity, the IPFIX Device 996 opens a Data Stream with the secondary Collector of the next highest 997 priority. If that secondary was not opened in advance, both the 998 Control Information and Data Stream must be sent to it. That 999 Collector might then become the primary, or the Exporting Process 1000 might try to reestablish the original session. 1002 8.3 Collector Redundancy 1004 Configuring redundant Collectors is an alternative to configuring 1005 backup Collectors. In this model, all Collectors simultaneously 1006 receive the Control Information and Data Streams. Multiple {Control 1007 Information, Data Stream} pairs could be sent, each to a different 1008 Collector from the same IPFIX Device. Since the IPFIX protocol 1009 requires a congestion-aware transport, achieving redundancy using 1010 multicast is not an option. 1012 9. IPFIX Flow Collection in Special Situations 1014 An IPFIX Device could be doing one or more of generating, receiving, 1015 altering special types of traffic which are listed below. 1017 Tunnel traffic: 1019 The IPFIX Device could be the head, midpoint or endpoint of a 1020 tunnel. In such cases the IPFIX Device could be handling GRE, 1021 IPinIP or UTI traffic. 1023 VPN traffic: 1025 The IPFIX Device could be a provider edge device which receives 1026 traffic from customer sites belonging to different Virtual Private 1027 Networks. 1029 Similarly, IPFIX could be implemented on devices which perform one or 1030 more of the following special services: 1032 o Explicitly drop packets. For example a device which provides 1033 firewall service drops packets based on some administrative 1034 policy. 1036 o Alter the values of fields used as IPFIX Flow Keys of interest. 1037 For example a device which provides NAT service can change source 1038 and/or destination IP address. 1040 In cases such as those listed above, there should be clear guidelines 1041 as to: 1043 o How and when to classify the packets as Flows in the IPFIX Device. 1045 o If multiple encapsulations are used to define Flows, how to convey 1046 the same fields (e.g. IP address) in different layers. 1048 o How to differentiate Flows based on different private domains. 1049 For example, overlapping IP addresses in Layer-3 VPNs. 1051 o What extra information needs be exported so that the Collector can 1052 make a clear interpretation of the received Flow Records. 1054 10. Security Considerations 1056 Flow information can be used for various purposes, such as usage 1057 accounting, traffic profiling, traffic engineering, and intrusion 1058 detection. The security requirement may differ significantly for 1059 such applications. To be able to satisfy the security needs of 1060 various IPFIX users, an IPFIX system must provide different levels of 1061 security protection. 1063 10.1 Data Security 1065 IPFIX data comprises Control Information and Data Stream generated by 1066 the IPFIX Device. 1068 The IPFIX data may exist in both the IPFIX Device and the Collector. 1069 In addition, the data is also transferred on the wire from the IPFIX 1070 Device to the Collector when it is exported. To provide security, 1071 the data should be protected from common network attacks. 1073 The protection of IPFIX data within the end system (IPFIX Device and 1074 Collector) is out of scope for this document. It is assumed that the 1075 end system operator will provide adequate security for the IPFIX 1076 data. 1078 The IPFIX architecture must allow different levels of protection to 1079 the IPFIX data on the wire. Wherever security functions are required 1080 it is recommended that users should leverage lower layers using 1081 either IPsec or TLS, if these can successfully satisfy the security 1082 requirement of IPFIX data protection. 1084 To protect the data on the wire, three levels of granularity should 1085 be supported; these are described in the following subsections. 1087 10.1.1 Host-Based Security 1089 Security may not be required when the transport between the IPFIX 1090 Device and the Collector is perceived as safe. This option allows 1091 the protocol to run most efficiently without extra overhead and an 1092 IPFIX system must support it. 1094 10.1.2 Authentication-only 1096 Authentication-only protection provides IPFIX users with the 1097 assurance of data integrity and authenticity. The data exchanged 1098 between the IPFIX Device and the Collector is protected by an 1099 authentication signature. Any modification of the IPFIX data will be 1100 detected by the recipient, resulting in discarding of the received 1101 data. However, the authentication-only option doesn't offer data 1102 confidentiality. 1104 The IPFIX user should not use authentication-only when sensitive or 1105 confidential information is being exchanged. An IPFIX solution 1106 should support this option. The authentication-only option should 1107 provide replay attack protection. One way to achieve this level of 1108 security would be: 1110 o IP Authentication Header 1112 10.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 Records to 1128 the Collector due to the resource requirement for running encryption. 1130 10.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 fulfil the authentication 1143 requirement. 1145 10.3 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 10.3.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 10.3.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 10.3.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 10.3.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 synchronise 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, thereby providing more 1193 information that the Collector could use to identify and ignore 1194 spoofed data packets. 1196 11. IANA Considerations 1198 The IPFIX Architecture, as set out in this document, has two sets of 1199 assigned numbers, as outlined in the following subsections. 1201 11.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 Set ID, indicating the type for each set of 1207 information within an IPFIX message. 1209 Values for the IPFIX Version Number and the IPFIX Set ID, together 1210 with the considerations for assigning them, are defined in IPFIX- 1211 PROTO [3] 1213 11.2 Numbers used in the Information Model 1215 Fields of the IPFIX protocol carry information about traffic 1216 measurement. They are modelled 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 Values for the IPFIX Information Element IDs, together with the 1222 considerations for assigning them, are defined in IPFIX-INFO [2]. 1224 12. Acknowledgements 1226 The document editors wish to thank all the people contributing to the 1227 discussion of this document on the mailing list, and the design teams 1228 for many valuable comments. In particular, the following made 1229 significant contributions: 1231 Tanja Zseby 1232 Paul Calato 1233 Dave Plonka 1234 Jeffrey Meyer 1235 K.C.Norseth 1236 Vamsi Valluri 1237 Cliff Wang 1238 Ram Gopal 1239 Jc Martin 1240 Carter Bullard 1241 Reinaldo Penno 1242 Simon Leinen 1243 Kevin Zhang 1244 Paul Aitken 1245 Brian Trammell 1247 Special thanks to Dave Plonka for the multiple thorough reviews. 1249 13. References 1251 13.1 Normative References 1253 [1] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements 1254 for IP Flow Information Export", RFC RFC 3917, October 2004. 1256 [2] Meyer, J., Quittek, J., and S. Bryant, "IPFIX: Information 1257 Model", (work in progress), Internet Draft, 1258 draft-ietf-ipfix-info-08.txt, October 2004. 1260 [3] Claise, B., Bryant, S., Sadasivan, G., and M. Fullmer, "IPFIX: 1261 Protocol", (work in progress), Internet Draft, 1262 draft-ietf-ipfix-protocol-10.txt, December 2004. 1264 [4] Zseby, T., Boschi, E., Penno, R., Brownlee, N., and B. Claise, 1265 "IPFIX: Protocol", (work in progress), Internet Draft, 1266 draft-ietf-ipfix-as-05.txt, October 2004. 1268 13.2 Informative References 1270 [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1271 "RTP: A Transport Protocol for Real-Time Applications", 1272 RFC 3550, Julyy 2003. 1274 [6] Leinen, S., "Evaluation of Candidate Protocols for IP Flow 1275 Information Export", RFC 3955, October 2004. 1277 Authors' Addresses 1279 Ganesh Sadasivan 1280 Cisco Systems, Inc. 1281 170 West Tasman Drive 1282 San Jose, CA 95134 1283 USA 1285 Phone: +1 408 527-0251 1286 Email: gsadasiv@cisco.com 1288 Nevil Brownlee 1289 CAIDA | The University of Auckland 1290 Private Bag 92019 1291 Auckland 1292 New Zealand 1294 Phone: +64 9 373 7599 x88941 1295 Email: n.brownlee@auckland.ac.nz 1297 Benoit Claise 1298 Cisco Systems, Inc. 1299 De Kleetlaan 6a b1 1300 1831 Diegem 1301 Belgium 1303 Phone: +32 2 704 5622 1304 Email: bclaise@cisco.com 1306 Juergen Quittek 1307 NEC Europe Ltd. 1308 Adenauerplatz 6 1309 69225 Heidelberg 1310 Germany 1312 Phone: +49 6221 90511-15 1313 Email: quittek@ccrle.nec.de 1315 Appendix A. Changes/Issues from the -11 Draft 1317 Flow Examples 1318 This section has been extended to include IPv6 examples as well as 1319 IPv4. 1321 Editorial Improvements: 1323 Mask/Match example 'Destination Port between 80 and 120' changed 1324 to 'Destination Port < 1024' 1326 Intellectual Property Statement 1328 The IETF takes no position regarding the validity or scope of any 1329 Intellectual Property Rights or other rights that might be claimed to 1330 pertain to the implementation or use of the technology described in 1331 this document or the extent to which any license under such rights 1332 might or might not be available; nor does it represent that it has 1333 made any independent effort to identify any such rights. Information 1334 on the procedures with respect to rights in RFC documents can be 1335 found in BCP 78 and BCP 79. 1337 Copies of IPR disclosures made to the IETF Secretariat and any 1338 assurances of licenses to be made available, or the result of an 1339 attempt made to obtain a general license or permission for the use of 1340 such proprietary rights by implementers or users of this 1341 specification can be obtained from the IETF on-line IPR repository at 1342 http://www.ietf.org/ipr. 1344 The IETF invites any interested party to bring to its attention any 1345 copyrights, patents or patent applications, or other proprietary 1346 rights that may cover technology that may be required to implement 1347 this standard. Please address the information to the IETF at 1348 ietf-ipr@ietf.org. 1350 Disclaimer of Validity 1352 This document and the information contained herein are provided on an 1353 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1354 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1355 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1356 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1357 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1358 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1360 Copyright Statement 1362 Copyright (C) The Internet Society (2006). This document is subject 1363 to the rights, licenses and restrictions contained in BCP 78, and 1364 except as set forth therein, the authors retain all their rights. 1366 Acknowledgment 1368 Funding for the RFC Editor function is currently provided by the 1369 Internet Society.