idnits 2.17.1 draft-ietf-ipfix-architecture-05.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 1434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1419. ** 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 873 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 10, 2005) is 7045 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 312 -- Looks like a reference, but probably isn't: 'IPFIX-INFO' on line 433 ** 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 11, 2005 CAIDA | The University of Auckland 5 B. Claise 6 Cisco Systems, Inc. 7 J. Quittek 8 NEC Europe Ltd. 9 January 10, 2005 11 Architecture for IP Flow Information Export 12 draft-ietf-ipfix-architecture-05 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 11, 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. Architecture Issues . . . . . . . . . . . . . . . . . . . . 4 55 2. Changes/Issues from the -04 Draft . . . . . . . . . . . . . 5 56 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1 Document Scope . . . . . . . . . . . . . . . . . . . . . . 6 58 3.2 IPFIX Documents Overview . . . . . . . . . . . . . . . . . 6 59 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Examples of Flows . . . . . . . . . . . . . . . . . . . . . 11 61 6. IPFIX Reference Model . . . . . . . . . . . . . . . . . . . 12 62 7. IPFIX Functional and Logical Blocks . . . . . . . . . . . . 14 63 7.1 Metering Process . . . . . . . . . . . . . . . . . . . . . 14 64 7.1.1 Flow Record Expiration . . . . . . . . . . . . . . . . 14 65 7.2 Observation Point . . . . . . . . . . . . . . . . . . . . 15 66 7.3 Selection Criteria for Packets . . . . . . . . . . . . . . 15 67 7.3.1 Sampling Functions, Si . . . . . . . . . . . . . . . . 16 68 7.3.2 Filter Functions, Fi . . . . . . . . . . . . . . . . . 16 69 7.4 Observation Domain . . . . . . . . . . . . . . . . . . . . 16 70 7.5 Exporting Process . . . . . . . . . . . . . . . . . . . . 16 71 7.6 Collecting Process . . . . . . . . . . . . . . . . . . . . 17 72 7.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 8. Overview of the IPFIX Protocol . . . . . . . . . . . . . . . 19 74 8.1 Information Model Overview . . . . . . . . . . . . . . . . 20 75 8.2 Flow Records . . . . . . . . . . . . . . . . . . . . . . . 20 76 8.3 Control Information . . . . . . . . . . . . . . . . . . . 20 77 8.4 Reporting Responsibilities . . . . . . . . . . . . . . . . 21 78 9. IPFIX Protocol Details . . . . . . . . . . . . . . . . . . . 22 79 9.1 The IPFIX Basis Protocol . . . . . . . . . . . . . . . . . 22 80 9.2 IPFIX Protocol on the Collecting Process . . . . . . . . . 22 81 9.3 Support for Applications . . . . . . . . . . . . . . . . . 23 82 10. Export Models . . . . . . . . . . . . . . . . . . . . . . . 23 83 10.1 Export with Reliable Control Connection . . . . . . . . 23 84 10.2 Collector Failure Detection and Recovery . . . . . . . . 23 85 10.3 Collector Redundancy . . . . . . . . . . . . . . . . . . 24 86 11. IPFIX Flow Collection for Special Traffic . . . . . . . . . 24 87 12. IPFIX Flow Collection from Special Devices . . . . . . . . . 25 88 13. Security Considerations . . . . . . . . . . . . . . . . . . 25 89 13.1 Data Security . . . . . . . . . . . . . . . . . . . . . 25 90 13.1.1 Host-Based Security . . . . . . . . . . . . . . . . 26 91 13.1.2 Authentication-only . . . . . . . . . . . . . . . . 26 92 13.1.3 Encryption . . . . . . . . . . . . . . . . . . . . . 27 93 13.2 IPFIX End-point Authentication . . . . . . . . . . . . . 27 94 14. IPFIX Overload . . . . . . . . . . . . . . . . . . . . . . . 27 95 14.1 Denial of Service (DoS) Attack Prevention . . . . . . . 27 96 14.1.1 Network Under Attack . . . . . . . . . . . . . . . . 28 97 14.1.2 Generic DoS Attack on the IPFIX Device and 98 Collector . . . . . . . . . . . . . . . . . . . . . 28 99 14.1.3 IPFIX Specific DoS Attack . . . . . . . . . . . . . 28 100 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 101 15.1 Numbers used in the Protocol . . . . . . . . . . . . . . 28 102 15.2 Numbers used in the Information Model . . . . . . . . . 29 103 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 104 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 17.1 Normative References . . . . . . . . . . . . . . . . . . . 29 106 17.2 Non-normative References . . . . . . . . . . . . . . . . . 30 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 108 Intellectual Property and Copyright Statements . . . . . . . 32 110 1. Architecture Issues 112 ARCH-03: 114 Not clear how Options Template and Options Data should be used. 115 Add text to explain that 117 * data templates specify flow records, 119 * option templates specify options data records, and 121 * options data fields hold information which does not refer to 122 specific flows, e.g. config data or statistics. 124 Security Considerations. Can anyone offer more/better text for 125 this section? 127 ARCH-13: 129 To protect the data on the wire, three levels of granularity 130 should be supported ... I guess we need some more text here 132 ARCH-14: 134 Need references for TCP with MD5 options, and IP Authentication 135 Header, TCP with MD5 options, IP authentication header, GRE, 136 IPinIP and UTI traffic 138 ARCH-15: 140 * Dave Plonka and Benoit Claise have some concerns about Section 141 8 and Section 9: 143 * "Overview of the IPFIX protocol" is in the middle of the doc, 144 and this describes IPFIX generic tasks... like an 145 introduction. 147 * "Send control and data packets to the collector" should be: 148 "send the IPFIX Messages to the Collector" 150 * Section 9: IPFIX protocol details: can't we combine this 151 Section 9 with Section 8? 153 * Why do we explain the historic of the IPFIX evaluation process? 154 If we do, must we have the references for NetFlow, CRANE, LFAP, 155 RTFM. OR we could simply refer to RFC3917. 157 * "In the basis protocol Flow Records are defined by Templates, 158 where a Template is an ordered set of the Information 159 Elements". The notion of "basis protocol" has no meaning 160 unless we know about the evaluation process and that the 161 selected protocol was NetFlow v9. If we choose to describe the 162 evaluation process, we should say that the basis protocol = 163 NetFlow v9. Now, I'm not sure describing the full evaluation 164 process in the architecture is useful. 166 * Section 9.2 "Indicating Flow Record losses to the exporting 167 IPFIX Device and/or IPFIX users:" What are the IPFIX users? 168 IPFIX doesn't indicate the flow record losses back to the 169 exporting process! 171 * Section 9.3 "support for applications:" Not sure how it relates 172 to Section 9 "IPFIX protocol details" 174 * Conclusion:I think Section 8 and Section 9 are composed of very 175 old text (at the time Ganesh and Benoit wrote the first 176 version). We should do some rewrite. 178 ARCH-16: 180 Section 11 and Section 12: What is the goal of these sections? My 181 only conclusion is that we need to have a clear description of the 182 Information Elements. 184 ARCH-17: 186 Must separate normative versus informative reference (i.e. they 187 need to be in separate subsections). 189 ARCH-18: 191 Flow key(s) consistency between examples and definition: list of 192 keys, or set of keys 194 2. Changes/Issues from the -04 Draft 196 Terminology: 198 Added definition for "Information Element" 200 Flow Expiration: 202 Dropped comment about long-running flows; an IPFIX meter will 203 simply create new flows for them. 205 Data Loss on Collector Failure: 207 Dropped comment about the amount of data tat could be lost during 208 failover to a secondary collector. 210 Added new issues, ARCH-13 to ARCH-18: 212 3. Introduction 214 There are several applications e.g., usage-based accounting, traffic 215 profiling, traffic engineering, attack/intrusion detection, QoS 216 monitoring, that require flow-based IP traffic measurements. It is 217 therefore important to have a standard way of exporting information 218 related to IP flows. This document defines an architecture for IP 219 traffic flow monitoring, measuring and exporting. It provides a 220 high-level description of an IPFIX device's key components and their 221 functions. 223 3.1 Document Scope 225 This document defines the architecture for IPFIX. Its main 226 objectives are to: 228 o Describe the key IPFIX architectural components, consisting of (at 229 least) IPFIX devices and collectors communicating using the IPFIX 230 protocol. 232 o Define the IPFIX architectural requirements, e.g., recovery, 233 security, etc. 235 o Describe the characteristics of the IPFIX protocol. 237 Note that the IPFIX architecture does not provide for remote 238 configuration of an IPFIX device. Instead, IPFIX devices are 239 configured by other means. 241 3.2 IPFIX Documents Overview 243 The IPFIX protocol provides network administrators with access to IP 244 flow information. This document specifies the architecture for the 245 export of measured IP flow information out of an IPFIX exporting 246 process to a collecting process, per the requirements defined in 247 IPFIX-REQS [1]. The IPFIX protocol document IPFIX-PROTO [3] 248 specifies how IPFIX flow record data, options record data, and 249 templates are carried via a congestion- aware transport protocol from 250 IPFIX exporting process to IPFIX collecting process. IPFIX has a 251 formal description of IPFIX information elements (fields), their 252 name, type and additional semantic information, as specified in 253 IPFIX-INFO [2]. Finally IPFIX-AS [4] describes what type of 254 applications can use the IPFIX protocol and how they can use the 255 information provided. It furthermore shows how the IPFIX framework 256 relates to other architectures and frameworks. 258 Note that the IPFIX system does not provide for remote configuration 259 of an IPFIX device. Instead, IPFIX devices are configured by network 260 operations staff. 262 4. Terminology 264 The definitions of basic IPFIX terms such as IP Traffic Flow, 265 Exporting Process, Collecting Process, Observation Point, etc. are 266 semantically identical with those found in the IPFIX requirements 267 document IPFIX-REQS [1]. Some of the terms have been expanded for 268 more clarity when defining the protocol. Additional definitions 269 required for the architecture have also been defined. For the same 270 terms defined here and in IPFIX-PROTO [3] the definitions are 271 equivalent in both documents. 273 * Observation Point 275 An Observation Point is a location in the network where IP packets 276 can be observed. Examples include: a line to which a probe is 277 attached, a shared medium, such as an Ethernet-based LAN, a single 278 port of a router, or a set of interfaces (physical or logical) of 279 a router. 281 Note that one Observation Point may be a superset of several other 282 Observation Points. For example one Observation Point can be an 283 entire line card. That would be the superset of the individual 284 Observation Points at the line card's interfaces. 286 * Observation Domain 288 An Observation Domain is the largest set of Observation Points for 289 which Flow information can be aggregated by a Metering Process. 290 Each Observation Domain presents itself using a unique ID to the 291 Collecting Process to identify the IPFIX Messages it generates. 292 For example, a router line card may be an observation domain if it 293 is composed of several interfaces: each of which is an Observation 294 Point. Every Observation Point is associated with an Observation 295 Domain. 297 * IP Traffic Flow or Flow 299 There are several definitions of the term 'flow' being used by the 300 Internet community. Within the context of IPFIX we use the 301 following definition: 303 A Flow is defined as a set of IP packets passing an Observation 304 Point in the network during a certain time interval. All packets 305 belonging to a particular Flow have a set of common properties. 306 Each property is defined as the result of applying a function to 307 the values of: 309 1. One or more packet header field (e.g. destination IP 310 address), transport header field (e.g. destination port 311 number), or application header field (e.g. RTP header fields 312 [RFC1889]) 314 2. One or more characteristics of the packet itself (e.g. number 315 of MPLS labels) 317 3. One or more fields derived from packet treatment (e.g. next 318 hop IP address, output interface) 320 A packet is said to belong to a Flow if it completely satisfies 321 all the defined properties of the Flow. 323 This definition covers the range from a Flow containing all 324 packets observed at a network interface to a Flow consisting of 325 just a single packet between two applications with a specific 326 sequence number. 328 * Flow Key 330 Each of the fields which 332 1. Belong to the packet header (e.g. destination IP address) 334 2. Are a property of the packet itself (e.g. packet length) 336 3. Are derived from packet treatment (e.g. AS number) 338 and which are used to define a Flow are termed Flow Keys. 340 * Flow Record 342 A Flow Record contains information about a specific Flow that was 343 observed at an Observation Point. A Flow Record contains measured 344 properties of the Flow (e.g. the total number of bytes for all 345 the Flow's packets) and usually characteristic properties of the 346 Flow (e.g. source IP address). 348 * Metering Process 350 A Metering Process generates Flow Records. Input to the process 351 are packet headers observed at an Observation Point, and packet 352 treatment at the Observation Point Point (for example the selected 353 output interface). 355 The Metering Process consists of a set of functions that includes 356 packet header capturing, timestamping, sampling, classifying, and 357 maintaining Flow Records. 359 The maintenance of Flow Records may include creating new records, 360 updating existing ones, computing Flow statistics, deriving 361 further Flow properties, detecting Flow expiration, passing Flow 362 Records to the Exporting Process, and deleting Flow Records. 364 * Exporting Process 366 An Exporting Process sends Flow Records to one or more Collecting 367 Processes. The Flow Records are generated by one or more Metering 368 Processes. 370 * Exporter 372 A device which hosts one or more Exporting Processes is termed an 373 Exporter. 375 * IPFIX Device 377 An IPFIX Device hosts at least one Observation Point, a Metering 378 Process and an Exporting Process. Typically, corresponding 379 Observation Point(s), Metering Process(es) and Exporting 380 Process(es) are co-located at such a device, for example at a 381 router. 383 * Collecting Process 385 A Collecting Process receives Flow Records from one or more 386 Exporting Processes. The Collecting Process might process or 387 store received Flow Records, but such actions are out of scope for 388 this document. 390 * Collector 391 A device which hosts one or more Collecting Processes is termed a 392 Collector. 394 * Template 396 A Template is an ordered sequence of pairs, used to 397 completely identify the structure and semantics of a particular 398 set of information that needs to be communicated from an IPFIX 399 Device to a Collector. Each Template is uniquely identifiable by 400 means of a Template ID. 402 * Control Information, Data Stream 404 The information that needs to be exported from the IPFIX Device 405 can be classified into the following categories: 407 Control Information 409 This includes the Flow definition, selection criteria for 410 packets within the Flow sent by the Exporting Process, and any 411 IPFIX protocol messages. The Control Information carries all 412 the information needed for the end-points to understand the 413 IPFIX protocol, and specifically for the receiver (Collector) 414 to understand and interpret the data sent by the sender 415 (Exporter). 417 Data Stream 419 This includes Flow Records carrying the field values for the 420 various observed Flows at each of the Observation Points. 422 IPFIX Message 424 An IPFIX Message is a message originating at the Exporting Process 425 that carries the IPFIX records of this Exporting Process and whose 426 destination is a Collecting Process. An IPFIX Message is 427 encapsulated within a transport layer. 429 Information Element 431 An Information Element is a protocol and encoding independent 432 description of an attribute which may appear in an IPFIX Flow 433 Record. The IPFIX information model [IPFIX-INFO] defines the base 434 set of Information Elements for IPFIX. The type associated with 435 an Information Element indicates constraints on what it may 436 contain and also determine the valid encoding mechanisms for use 437 in IPFIX. 439 5. Examples of Flows 441 Some examples of Flows are listed below: 443 Example 1: The Flow Keys define the different fields by which Flows 444 are distinguished. The different combination of the field values 445 creates unique Flows. If the Flow Key is defined as {source IP 446 address, destination IP address, DSCP}, then all of these are 447 different Flows. 449 1. {198.18.40.1, 198.18.23.5, 4} 450 2. {198.18.40.23, 198.18.23.67, 4} 451 3. {198.18.40.23, 198.18.23.67, 2} 452 4. {198.18.20.200, 198.18.23.67, 4} 454 Example 2: A match function can be applied to all the packets that 455 pass through an Observation Point, in order to aggregate some values. 456 This could be done by defining the Flow Key as {source IP address, 457 destination IP address, DSCP} as in example 1 above, and applying a 458 function which masks out the least significant 8 bits of the source 459 IP address and destination IP address (i.e. the result is a /24 460 address). The four Flows from example 1 would now be aggregated into 461 three Flows by merging the Flows 1 and 2 into a single Flow. 463 1. {198.18.40.0/24, 198.18.23.0/24, 4} 464 2. {198.18.40.0/24, 198.18.23.0/24, 2} 465 3. {198.18.20.0/24, 198.18.23.0/24, 4} 467 Example 3: A filter defined by some field values can be applied on 468 all packets that pass the Observation Point, in order to select only 469 certain Flows. The filter is defined by choosing fixed values for 470 specific fields from the packet. 472 All the packets that go from a customer network 198.18.40.0/24 to 473 another customer network 198.18.23.0/24 with DSCP value of 4 define a 474 Flow. All other combinations don't define a Flow and are not taken 475 into account. The three Flows from example 2 would now be reduced to 476 one Flow by filtering away the second and the third Flow, leaving 477 only {198.18.40.0/24, 198.18.23.0/24, 4}. 479 The above examples can be thought of as a function F() taking as 480 input {source IP address, destination IP address, DSCP}. The 481 function selects only the packets which satisfy all three of the 482 following conditions: 484 1. Mask out the least significant 8 bits of source IP address, match 485 against 198.18.40.0. 487 2. Mask out the least significant 8 bits of destination IP address, 488 match against 198.18.23.0. 490 3. Only accept DSCP value equal to 4. 492 Depending on the values of {source IP address, destination IP 493 address, DSCP} of the different observed packets, the Metering 494 Process function F() would choose/filter/aggregate different sets of 495 packets, which would create different Flows. For example, various 496 combination of values of {source IP address, destination IP address, 497 DSCP}, F(source IP address, destination IP address, DSCP) would 498 result in the definition of one or more Flows. 500 6. IPFIX Reference Model 502 The figure below shows the reference model for IPFIX. This figure 503 covers the various possible scenarios that can exist in an IPFIX 504 system. 506 +----------------+ +----------------+ 507 |[*Application 1]| ..|[*Application n]| 508 +--------+-------+ +-------+--------+ 509 ^ ^ 510 ~ ~ 511 +~~~~~~~~~~+~~~~~~~~+ 512 ^ 513 ~ 514 +------------------------+ +-------+------------------+ 515 |IPFIX Device(1) | | Collector(1) | 516 |[Exporting Process(es)] |<----------->| [Collecting Process(es)] | 517 +------------------------+ +--------------------------+ 518 .... .... 519 +------------------------+ +---------------------------+ 520 |IPFIX Device(i) | | Collector(j) | 521 |[Obsv Point(s)] |<---------->| [Collecting Process(es)] | 522 |[Metering Process(es)] | +---->| [*Application(s)] | 523 |[Exporting Process(es)] | | +---------------------------+ 524 +------------------------+ . 525 .... . .... 526 +------------------------+ | +--------------------------+ 527 |IPFIX Device(m) | | | Collector(n) | 528 |[Obsv Point(s)] |<-----+---->| [Collecting Process(es)] | 529 |[Metering Process(es)] | | [*Application(s)] | 530 |[Exporting Process(es)] | +--------------------------+ 531 +------------------------+ 533 The various functional components are indicated within brackets []. 534 The functional components within [*] are not part of the IPFIX 535 architecture. The interfaces shown by "<-->" are defined by the 536 IPFIX architecture but those shown by "<~~>" are not. 538 Figure 3 540 The figure below shows a typical IPFIX Device where the IPFIX 541 components are shown in rectangular boxes. 543 +--------------------------------------------------+ 544 | IPFIX Device | 545 | +-----+ | 546 | +---......--+------------+---------> | | 547 | | | | | | 548 | +----+----+ +----+----+ | | | 549 | |Metering | |Metering | | E | | 550 | |Process 1| |Process N| | x | | 551 | |(Packet | |(Packet | | p | | 552 | | Level) | | Level) | | o | | 553 | +---------+ +---------+ | r | | 554 | ^ ^ | t | | 555 |+-------+-----------------------+-------+ | i | | 556 || | Observation Domain 1 | | | n | | 557 || +-----+------+ +-----+------+| | g | | 558 || |Obsv Point 1| ... |Obsv Point M|| | | | 559 || +------------+ +------------+| | | | 560 Packets|+-------^-------------------------^-----+ | | | Export 561 --->---+--------+----------.....----------+ | | | Pkts to 562 In | | +-------> 563 | . . . . . | | |Collector 564 | | | | 565 | +---......--+------------+---------> | | 566 | | | | | | 567 | +----+----+ +----+----+ | P | | 568 | |Metering | |Metering | | r | | 569 | |Process 1| |Process N| | o | | 570 | +---------+ +---------+ | c | | 571 | ^ ^ | e | | 572 |+-------+-----------------------+-------+ | s | | 573 || | Observation Domain K | | | s | | 574 || +-----+------+ +-----+------+| | | | 575 || |Obsv Point 1| ... |Obsv Point M|| | | | 576 || +------------+ +------------+| | | | 577 Packets|+-------^-------------------------^-----+ +-----+ | 578 --->---+--------+---------- ... ----------+ | 579 In | | 580 +--------------------------------------------------+ 582 Figure 4 584 7. IPFIX Functional and Logical Blocks 586 7.1 Metering Process 588 Every Observation Point in an IPFIX Device, participating in Flow 589 measurements, must be associated with at least one Metering Process. 590 Every packet coming into an Observation Point goes into each of the 591 Metering Processes associated with the Observation Point. Broadly, 592 each Metering Process observes the packets that pass an Observation 593 Point, does timestamping and classifies the packets into Flow(s) 594 based on the selection criteria. 596 The Metering Process is a functional block which manages all the 597 Flows generated from an Observation Domain. The typical functions of 598 a Metering Process may include: 600 o Maintain database(s) of all the Flows Records from an Observation 601 Domain. This includes creating new Flow Records, updating 602 existing ones, computing Flow Records statistics, deriving further 603 Flow properties, adding non-flow-specific information based on the 604 packet treatment (in some cases fields like AS numbers, router 605 state, etc.) 607 o Maintain statistics about the itself, such as Flows Records 608 generated, packet observed, etc. 610 7.1.1 Flow Record Expiration 612 A Flow Record is considered to have expired under the following 613 conditions: 615 1. If the Metering Process can deduce the end of a Flow, that Flow 616 Record should be exported when the end of the Flow is detected. 617 For example, a Flow generated by TCP traffic where the FIN or RST 618 bits indicate the end of the Flow Record. 620 2. If no packets belonging to the Flow have been observed for a 621 certain period of time. This time period should be configurable 622 at the Metering Process, with a minimum value of 0 seconds for 623 immediate expiration. Note that a zero timeout would report a 624 Flow as a sequence of single-packet Flows. 626 3. If the IPFIX Device experiences resource constraints, a Flow 627 Record may be prematurely expired (e.g. lack of memory to store 628 Flow Records) 630 4. For long-running Flows, the Metering Process should expire the 631 Flow Record on a regular basis or based on some expiration 632 policy. This periodicity or expiration policy should be 633 configurable at the Metering Process. When a the Record of a 634 long-running Flow is expired, that Flow Record may still be 635 maintained by the Metering Process so that, for further observed 636 packets of the same Flow Record, the Metering Process does not 637 need to create a new Flow Record. 639 7.2 Observation Point 641 A Flow Record can be better analyzed if the Observation Point from 642 which it was measured is known. As such it is recommended that IPFIX 643 Devices send this information to Collectors. In cases where there is 644 a single Observation Point or where the Observation Point information 645 is not relevant, the Metering Process may choose not to add the 646 Observation Point to the Flow Records. 648 7.3 Selection Criteria for Packets 650 A Metering Process may define rules so that only certain packets 651 within an incoming stream of packets are chosen for measurement at an 652 Observation Point. This may be done by one of the two methods 653 defined below or a combination of them, in either order. A 654 combination of each of these methods can be adopted to select the 655 packets, i.e. one can define a set of methods {F1, S1, F2, S2, S3} 656 executed in a specified sequence at an Observation Point to select 657 particular Flows. 659 The figure below shows the operations which may be applied as part of 660 a typical Metering Process. 662 packet header capturing 663 | 664 timestamping 665 | 666 v 667 +----->+ 668 | | 669 | sampling Si (1:1 in case of no sampling) 670 | | 671 | filtering Fi (select all when no criteria) 672 | | 673 +------+ 674 | 675 v 676 Flows 677 Figure 5 679 7.3.1 Sampling Functions, Si 681 A sampling function determines which packets within a stream of 682 incoming packets is selected for measurement, i.e. packets that 683 satisfy the sampling criteria for this Metering Process. 685 Example: sample every 100th packet that was received at an 686 Observation Point and collect the Flow Records selected by a 687 particular filter function. Choosing all the packets is a special 688 case where the sampling rate is 1:1. 690 7.3.2 Filter Functions, Fi 692 A Filter Function selects only those incoming packets that satisfy a 693 function on fields defined by the packet header fields, fields 694 obtained while doing the packet processing, or properties of the 695 packet itself. 697 Example: Mask/Match of the fields that define a filter. A filter 698 might be defined as {Protocol == TCP, Destination Port between 80 and 699 120}. 701 Several such filters could be used in any sequence to select packets. 702 Note that packets selected by a (sequence of) filter functions may be 703 further classified by other filter functions, i.e. the selected 704 packets may belong to several Flows, any or all of which are 705 exported. 707 7.4 Observation Domain 709 The Observation Domain is a logical block that presents a single 710 identity for a group of Observation Points within an IPFIX Device. 711 Each {Observation Point, Metering Process} pair belongs to a single 712 Observation Domain. An IPFIX Device could have multiple Observation 713 Domains, each of which has a subset of the total set of Observation 714 Points in it. Each Observation Domain must carry a unique ID within 715 the context of an IPFIX Device. Note that in case of multiple 716 Observation Domains, a unique ID per Observation Domain must be 717 transmitted as a parameter to the Exporting Function. That unique ID 718 is referred to as the IPFIX Source ID. 720 7.5 Exporting Process 722 The Exporting Process is the functional block that sends data to one 723 or more IPFIX Collectors using the IPFIX protocol. On one side the 724 Exporting Process interfaces with Metering Process to get Flow 725 Records, while on the other side it talks to a Collecting Process on 726 the Collector(s). 728 There may be additional rules defined within an Observation Domain so 729 that only certain Flows Records are exported. This may be done by 730 either one or a combination of Si, Fi, as described in the section on 731 "Selection Criteria for Packets". 733 Example: Only the Flow Records which meet the following selection 734 criteria are exported. 736 1. All Flow Records whose destination IP address matches 737 {198.18.33.5}. 739 2. Every other (i.e. sampling rate 1 in 2) Flow Record whose 740 destination IP address matches {198.18.11.30}. 742 7.6 Collecting Process 744 Collecting Processes use a Flow Record's Template ID to interpret 745 that Flow Record's Information Elements. To allow this, an IPFIX 746 Exporter must ensure that an IPFIX Collector knows the Template ID 747 for each incoming Flow Record. To interpret incoming Flow Records, 748 an IPFIX Collector may also need to know the function F() that was 749 used by the Metering Process for each Flow. 751 An IPFIX Collector may also use the selection criteria for packets to 752 interpret the Flow Records further. 754 The functions of the Collecting Process must include: 756 o Identifying, accepting and decoding the IPFIX Messages from 757 different pairs. 759 o Storing the Control Information and Flow Records received from an 760 IPFIX Device. 762 At a high level, the Collecting Process: 764 1. Receives and stores the Control Information. 766 2. Decodes and stores the Flow Records using the Control 767 Information. 769 7.7 Summary 770 The figure below shows the functions performed in sequence by the 771 various functional blocks in an IPFIX Device. 773 Packet(s) coming into Observation Point(s) 774 | | 775 v v 776 +----------------+-------------------------+ +-----+-------+ 777 | Metering Process on an | | | 778 | Observation Point | | | 779 | packet header capturing | | | 780 | | |...| Metering | 781 | timestamping | | Process N | 782 | | | | | 783 | +----->+ | | | 784 | | | | | | 785 | | sampling Si (1:1 in case of no | | | 786 | | | sampling) | | | 787 | | classifying Fi (select all when | | | 788 | | | no criteria) | | | 789 | +------+ | | | 790 | | | | | 791 | | Timing out Flows | | | 792 | | Handle resource overloads | | | 793 +--------|---------------------------------+ +-----|-------+ 794 | | 795 Flow Records (identified by Observation Domain) Flow Records 796 | | 797 +---------+---------------------------------+ 798 | 799 +--------------------|----------------------------------------------+ 800 | | Exporting Process | 801 |+-------------------|-------------------------------------------+ | 802 || v IPFIX Protocol | | 803 ||+-----------------------------+ +----------------------------+| | 804 |||Rules for | |Functions || | 805 ||| Picking/sending Templates | |-Packetize selected Control || | 806 ||| Picking/sending Flow Records|->| & data Information into || | 807 ||| Encoding Template & data | | IPFIX export packets. || | 808 ||| Selecting Flows to export(*)| |-Handle export errors || | 809 ||+-----------------------------+ +----------------------------+| | 810 |+----------------------------+----------------------------------+ | 811 | | | 812 | IPFIX exported packet | 813 | | | 814 | +------------+-----------------+ | 815 | | Anonymize export packet(*) | | 816 | +------------+-----------------+ | 817 | | | 818 | +------------+-----------------+ | 819 | | Transport Protocol | | 820 | +------------+-----------------+ | 821 | | | 822 +-----------------------------+-------------------------------------+ 823 | 824 v 825 IPFIX export packet to Collector 827 (*) indicates that the block is optional. 829 Figure 6 831 8. Overview of the IPFIX Protocol 833 An IPFIX Device consists of a set of co-operating processes that 834 implement the functional blocks described in the previous section. 835 Alternatively, an IPFIX Device can be viewed simply as a network 836 entity which implements the IPFIX protocol. At the IPFIX Device, the 837 protocol functionality resides in the Exporting Process. The IPFIX 838 Exporting Process gets Flow Records from a Metering Process, and 839 sends them to the Collector(s). 841 At a high level, an IPFIX Device performs the following tasks: 843 1. Encode Control Information into Templates. 845 2. Encode packets observed at the Observation Points into Flow 846 Records. 848 3. Packetize the selected Templates and Flow Records into IPFIX 849 Messages. 851 4. Send control and data packets to the Collector. 853 The IPFIX protocol communicates information from an IPFIX Exporter to 854 an IPFIX Collector. That information includes not only Flow Records, 855 but also information about the Metering Process. Such information 856 (referred to as Control Information) includes details of the data 857 fields in Flow Records. It may also include statistics from the 858 Metering Process, such as the number of packets lost (i.e. not 859 metered). 861 For details of the IPFIX protocol please refer to IPFIX-PROTO [3]. 863 8.1 Information Model Overview 865 The IP Flow Information eXport (IPFIX) protocol serves for 866 transmitting information related to measured IP traffic over the 867 Internet. The protocol specification in IPFIX-PROTO [3] defines how 868 Information Elements are transmitted. For Information Elements, it 869 specifies the encoding of a set of basic data types. However, the 870 list of fields that can be transmitted by the protocol, such as Flow 871 attributes (source IP address, number of packets, etc.) and 872 information about the Metering and Exporting Process (packet 873 Observation Point, sampling rate, Flow timeout interval, etc.), is 874 not specified in IPFIX-PROTO [3]. Instead, it is defined in the 875 IPFIX Information Model document IPFIX-INFO [2]. 877 The Information Model provides a complete description of the 878 properties of every IPFIX Information Element. It does this by 879 specifying each element's name, Field Type, data type, etc., and 880 providing a description of each element. Element descriptions give 881 the semantics of the element, i.e. say how it is derived from a Flow 882 or other information available within an IPFIX Device. 884 8.2 Flow Records 886 The following rules provide guidelines to be followed while encoding 887 the Flow Records information: 889 A Flow Record contains enough information so that the Collecting 890 Process can identify the corresponding . 893 The Exporting Process encodes a given Information Element (as 894 specified in IPFIX-INFO [2]), based on the encoding standards 895 prescribed by IPFIX-PROTO [3]. 897 8.3 Control Information 899 The following rules provide guidelines to be followed while encoding 900 the Control Information: 902 o Per-Flow Control Information should be encoded such that the 903 Collecting Process can capture the structure and semantics of the 904 corresponding Flow data for each of the Flows Records exported by 905 the IPFIX Device. 907 o Configuration Control Information is conveyed to a Collector so 908 that its Collecting Process can capture the structure and 909 semantics of the corresponding configuration data. The 910 configuration data which is also Control Information should carry 911 additional information on the Observation Domain within which the 912 configuration takes effect. 914 For example, sampling using the same sampling algorithm, say 1 in 100 915 packets, is configured on two Observation Points O1 and O2. The 916 configuration in this case may be encoded as {ID, configuration 917 domain (O1,O2), sampling algorithm, interval (1 in 100)}, where ID 918 uniquely identifies this configuration. The ID must be sent within 919 the Flow Records in order to be able to match the right configuration 920 control information 922 The Control Information is used by the Collecting Process to: 924 o Decode and interpret Flow Records. 926 o Understand the state of the Exporting Process. 928 Sending Control Information from the Exporting Process in a timely 929 and reliable manner is critical to the proper functioning of the 930 IPFIX Collecting Process. The following approaches may be taken for 931 the export of Control Information. 933 1. Send all the Control Information pertaining to Flow Records prior 934 to sending the Flow Records themselves. This includes any 935 incremental changes to the definition of the Flow Records. 937 2. Notify on a near real time basis the state of the IPFIX Device to 938 the Collecting Process. This includes all changes such as a 939 configuration change that affects the Flow behavior, changes to 940 Exporting Process resources that alter export rates, etc., which 941 the Collector needs to be aware of. 943 3. Since it is vital that a Collecting Process maintains accurate 944 knowledge of the Exporter's state, the export of the Control 945 Information should be done such that that it reaches the 946 Collector reliably. One way to achieve this would be to send the 947 Control Information over a reliable transport. 949 8.4 Reporting Responsibilities 951 From time to time an IPFIX Device may not be able to observe all the 952 packets reaching one of its Observation Points. This could occur if 953 a Metering Process finds itself temporarily short of resources, for 954 example it might run out of packet buffers for IPFIX export, or it 955 might detect errors in its underlying transport layer. 957 In such situations, the IPFIX Device must report to its Collector(s) 958 the number of packet losses that have occurred. 960 9. IPFIX Protocol Details 962 When the IPFIX Working Group was chartered there were existing common 963 practices in the area of Flow export, for example NetFlow, CRANE, 964 LFAP, RTFM, etc. IPFIX's charter required the Working Group to 965 consider those existing practices, and select the one that was the 966 closest fit to the IPFIX requirements IPFIX-REQS [1]. Additions or 967 modifications would then be made to the selected protocol to fit it 968 exactly into the IPFIX architecture. 970 9.1 The IPFIX Basis Protocol 972 The working group went through an extensive evaluation of the various 973 existing protocols that were available, weighing the level of 974 compliance with the requirements, and selected one of the candidates 975 as the basis for the IPFIX protocol. For more details of the 976 evaluation process please see IPFIX-EVAL [5]. 978 In the basis protocol Flow Records are defined by Templates, where a 979 Template is an ordered set of the Information Elements appearing in a 980 Flow Record, together with their field sizes within those records. 982 This approach provides the following advantages: 984 o Using the Template mechanism, new fields can be added to IPFIX 985 Flow Records without changing the structure of the export record 986 format. 988 o Templates that are sent to the Collecting Process carry structural 989 information about the exported Flow Record fields. Therefore, if 990 the Collector does not understand the semantics of new fields it 991 can ignore them, but still interpret the Flow Record. 993 o Because the template mechanism is flexible, it allows the export 994 of only the required fields from the Flows to the Collecting 995 Process. This helps to reduce the exported Flow data volume and 996 possibly provide memory savings at the Exporting Process and 997 Collecting Process. Sending only the required information can 998 also reduce network load. 1000 9.2 IPFIX Protocol on the Collecting Process 1002 The Collecting process is responsible for: 1004 1. Receiving and decoding Flow Records from the IPFIX Devices. 1006 2. Indicating Flow Record losses to the exporting IPFIX Device 1007 and/or IPFIX users. 1009 Complete details of the IPFIX protocol are given in IPFIX-PROTO [3]. 1011 9.3 Support for Applications 1013 Applications that use the information collected by IPFIX may be 1014 Billing or Intrusion Detection sub-systems, etc. These applications 1015 may be an integral part of the Collecting Process or they may be 1016 co-located with the Collecting Process. The way by which these 1017 applications interface with IPFIX system to get the desired 1018 information is out of scope for this document. 1020 10. Export Models 1022 10.1 Export with Reliable Control Connection 1024 As mentioned in the IPFIX-REQS [1] document, an IPFIX Device must be 1025 able to transport its Control Information and Data Stream over a 1026 congestion-aware transport protocol. 1028 If the network in which the IPFIX Device and Collecting Process are 1029 located does not guarantee reliability, at least the Control 1030 Information should be exported over a reliable transport. The Data 1031 Stream may be exported over a reliable or unreliable transport 1032 protocol. 1034 Possible transport protocols include: 1036 o SCTP: Supports reliable and unreliable transport. 1038 o TCP: Provides reliable transport only. 1040 o UDP: Provides unreliable transport only. Network operators would 1041 need to avoid congestion by keeping traffic within their own 1042 administrative domains. 1044 10.2 Collector Failure Detection and Recovery 1046 The transport connection (in the case of a connection oriented 1047 protocol) is pre-configured between the IPFIX Device and the 1048 Collector. The IPFIX protocol does not provide any mechanism for 1049 configuring the Metering or Exporting Processes. 1051 Once connected, an IPFIX Collector receives Control Information and 1052 uses that information to interpret Flow Records. The IPFIX Device 1053 should set a keepalive (e.g. the keepalive timeout in the case of 1054 TCP, the HEARTBEAT interval in the case of SCTP) to a sufficiently 1055 low value so that it can quickly detect a Collector failure. 1057 Collector failure refers to the crash or restart of the Collecting 1058 Process, or of the Collector itself. A Collector failure is detected 1059 at the IPFIX Device by the break in the connection oriented transport 1060 protocol session: depending on the transport protocol - the 1061 connection timeout mechanisms differ. On detecting a keepalive 1062 timeout, the IPFIX Device should stop sending the Flow Record export 1063 data to the Collector and try to reestablish the transport 1064 connection. This is valid for a single Collector scenario. If 1065 Collecting Process failover is supported by the Exporting Process the 1066 backup session may be opened in advance. 1068 There could be one or more secondary Collectors with priority 1069 assigned to them. The primary Collector crash is detected at the 1070 IPFIX Device by the break in control connection (depending on the 1071 transport protocol - the connection timeout mechanisms differ). On 1072 detecting loss of connectivity, the IPFIX Device opens a Data Stream 1073 with the secondary Collector of the next highest priority. That 1074 Collector might become the primary, or the Exporting Process might 1075 try to reestablish the original session. 1077 10.3 Collector Redundancy 1079 Configuring redundant Collectors is an alternative to configuring 1080 backup Collectors. In this model, all Collectors simultaneously 1081 receive the Control Information and Data Streams. Multiple {Control 1082 Information, Data Stream} pairs could be set up, each to a different 1083 Collector from the same IPFIX Device. Since the IPFIX protocol 1084 requires a congestion-aware transport, achieving redundancy using 1085 multicast is not an option. 1087 11. IPFIX Flow Collection for Special Traffic 1089 An IPFIX Device could be doing one or more of generating, receiving, 1090 altering special types of traffic which are listed below. 1092 Tunnel traffic: 1094 The IPFIX Device could be the head, midpoint or endpoint of a 1095 tunnel. In such cases the IPFIX Device could be handling GRE, 1096 IPinIP or UTI traffic. 1098 VPN traffic: 1100 The IPFIX Device could be a provider edge device which receives 1101 traffic from customer sites belonging to different Virtual Private 1102 Networks. 1104 In the cases above, there should be clear guidelines as to: 1106 o How and when to classify the packets as Flows in the IPFIX Device. 1108 o If multiple encapsulations are used to define Flows, how to convey 1109 the same fields (e.g. IP address) in different layers. 1111 o How to differentiate Flows based on different private domains. 1112 For example, overlapping IP addresses in Layer-3 VPNs. 1114 12. IPFIX Flow Collection from Special Devices 1116 IPFIX could be implemented on devices which perform one or more of 1117 the following special services: 1119 o Explicitly drop packets. For example a device which provides 1120 firewall service drops packets based on some administrative 1121 policy. 1123 o Alter the values of fields used as IPFIX Flow Keys of interest. 1124 For example a device which provides NAT service can change source 1125 and/or destination IP address. 1127 In the cases above, there should be clear guidelines as to: 1129 o How and when to classify the packets as Flows in the IPFIX Device. 1131 o What extra information needs be exported so that the Collector can 1132 make a clear interpretation of the received Flow Records. 1134 13. Security Considerations 1136 Flow information can be used for various purposes, such as usage 1137 accounting, traffic profiling, traffic engineering, and intrusion 1138 detection. The security requirement may differ significantly for 1139 such applications. To be able to satisfy the security needs of 1140 various IPFIX users, an IPFIX system must provide different levels of 1141 security protection. 1143 13.1 Data Security 1145 IPFIX data comprises Control Information and Data Stream generated by 1146 the IPFIX Device. 1148 The IPFIX data may exist in both the IPFIX Device and the Collector. 1149 In addition, the data is also transferred on the wire from the IPFIX 1150 Device to the Collector when it is exported. To provide security, 1151 the data should be protected from common network attacks. 1153 The protection of IPFIX data within the end system (IPFIX Device and 1154 Collector) is out of scope for this document. It is assumed that the 1155 end system operator will provide adequate security for the IPFIX 1156 data. 1158 The IPFIX architecture must allow different levels of protection to 1159 the IPFIX data on the wire. Wherever security functions are required 1160 it is recommended that users should leverage lower layers using 1161 either IPSEC or TLS, if these can successfully satisfy the security 1162 requirement of IPFIX data protection. 1164 To protect the data on the wire, three levels of granularity should 1165 be supported .. 1167 13.1.1 Host-Based Security 1169 Security may not be required when the transport between the IPFIX 1170 Device and the Collector is perceived as safe. This option allows 1171 the protocol to run most efficiently without extra overhead and an 1172 IPFIX system must support it. 1174 13.1.2 Authentication-only 1176 Authentication-only protection provides IPFIX users with the 1177 assurance of data integrity and authenticity. The data exchanged 1178 between the IPFIX Device and the Collector is protected by an 1179 authentication signature. Any modification of the IPFIX data will be 1180 detected by the recipient, resulting in discarding of the received 1181 data. However, the authentication-only option doesn't offer data 1182 confidentiality. 1184 The IPFIX user should not use authentication-only when sensitive or 1185 confidential information is being exchanged. An IPFIX solution 1186 should support this option. The authentication-only option should 1187 provide replay attack protection. Some means to achieve this level 1188 of security are: 1190 o TCP with MD5 options. 1192 o IP Authentication Header 1194 13.1.3 Encryption 1196 Data encryption provides the best protection for IPFIX data. The 1197 IPFIX data is encrypted at the sender and only the intended recipient 1198 can decrypt and have access to the data. This option must be used 1199 when the transport between the IPFIX Device and the Collector are 1200 unsafe and the IPFIX data needs to be protected. It is recommended 1201 that the underlying transport layer's security functions be used for 1202 this purpose. Some means to achieve this level of security are: 1204 o Encapsulating Security Payload. 1206 o Transport Layer Security Protocol 1208 The data encryption option adds overhead to the IPFIX data transfer. 1209 It may limit the rate that an Exporter can report its Flow Record to 1210 the Collector due to the resource requirement for running encryption. 1212 13.2 IPFIX End-point Authentication 1214 It is important to make sure that the IPFIX Device is talking to the 1215 "right" Collector rather than to a masquerading Collector. The same 1216 logic also holds true from the Collector point of view, i.e. it may 1217 want to make sure it is collecting the Flow Records from the "right" 1218 IPFIX Device. An IPFIX system should allow the end point 1219 authentication capability so that either one-way or mutual 1220 authentication can be performed between the IPFIX Device and 1221 Collector. 1223 The IPFIX architecture should use any existing transport protection 1224 protocols such as TLS or IPSEC to fulfill the authentication 1225 requirement. 1227 14. IPFIX Overload 1229 An IPFIX Device could become overloaded under various conditions. 1230 This may be because of exhaustion of internal resources used for Flow 1231 generation and/or export. Such overloading may cause loss of data 1232 from the Exporting Process, either from lack of export bandwidth 1233 (possibly caused by an unusually high number of observed Flows) or 1234 from network congestion in the path from Exporter to Collector. 1236 IPFIX Collectors should be able to detect the loss of exported Flow 1237 Records, and should at least record the number of lost Flow Records. 1239 14.1 Denial of Service (DoS) Attack Prevention 1241 Since one of the potential usages for IPFIX is for intrusion 1242 detection, it is important for the IPFIX architecture to support some 1243 kind of DoS resistance. 1245 14.1.1 Network Under Attack 1247 The Network itself may be under attack, resulting in an overwhelming 1248 number of IPFIX Messages. An IPFIX system should try to capture as 1249 much information as possible. However, when a large number of IPFIX 1250 Messages are generated in a short period of time, the IPFIX system 1251 may become overloaded. 1253 14.1.2 Generic DoS Attack on the IPFIX Device and Collector 1255 The IPFIX Device and Collector may be subject to generic DoS attacks, 1256 just as any system on any open network. These types of attacks are 1257 not IPFIX specific. Preventing and responding to such types of 1258 attacks are out of the scope of this document. 1260 14.1.3 IPFIX Specific DoS Attack 1262 There are some specific attacks on the IPFIX portion of the IPFIX 1263 Device or Collector. 1265 o The attacker could overwhelm the Collector with spoofed IPFIX 1266 export packets. One way to solve this problem is to periodically 1267 synchronize the sequence numbers of the Flow Records between the 1268 Exporting and Collecting Processes. 1270 o The attacker could provide false reports to the Collector by 1271 sending spoofed packets. 1273 The problems mentioned above can be solved to a large extent if the 1274 control packets are encrypted both ways. 1276 15. IANA Considerations 1278 The IPFIX Architecture, as set out in this document, has two sets of 1279 assigned numbers. Considerations for assigning them are discussed in 1280 this section, using the example policies as set out in the 1281 "Guidelines for IANA Considerations" document IANA-RFC [6]. 1283 15.1 Numbers used in the Protocol 1285 IPFIX Messages, as described in IPFIX-PROTO [3], use two fields with 1286 assigned values. These are the IPFIX Version Number, indicating 1287 which version of the IPFIX Protocol was used to export an IPFIX 1288 Message, and the IPFIX Template Number, indicating the type for each 1289 set of information within an IPFIX message. 1291 Changes in either IPFIX Version Number or IPFIX Template Number 1292 assignments require an IETF Consensus, i.e. they are to be made via 1293 RFCs approved by the IESG. 1295 15.2 Numbers used in the Information Model 1297 Fields of the IPFIX protocol carry information about traffic 1298 measurement. They are modeled as elements of the IPFIX information 1299 model IPFIX-INFO [2]. Each Information Element describes a field 1300 which may appear in an IPFIX Message. Within an IPFIX message the 1301 field type is indicated by its Field Type. 1303 Changes in IPFIX Field Type will be administered by IANA, subject to 1304 Expert Review, i.e. review by one of a group of experts designated 1305 by an IETF Operations and Management Area Director. Those experts 1306 will initially be drawn from the Working Group Chairs and document 1307 editors of the IPFIX and PSAMP Working Groups. 1309 16. Acknowledgements 1311 The document editors wish to thank all the people contributing to the 1312 discussion of this document on the mailing list, and the design teams 1313 for many valuable comments. In particular, the following made 1314 significant contributions: 1316 Tanja Zseby 1317 Paul Calato 1318 Dave Plonka 1319 Jeffrey Meyer 1320 K.C.Norseth 1321 Vamsi Valluri 1322 Cliff Wang 1323 Ram Gopal 1324 Jc Martin 1325 Carter Bullard 1326 Reinaldo Penno 1327 Simon Leinen 1328 Kevin Zhang 1329 Paul Aitken 1331 Special thanks to Dave Plonka for the multiple thorough reviews. 1333 17. References 1335 17.1 Normative References 1337 [1] Quittek, J., Zseby, T., Claise, B. and S. Zander, "Requirements 1338 for IP Flow Information Export", RFC RFC 3917, October 2004. 1340 [2] Meyer, J., Quittek, J. and S. Bryant, "IPFIX: Information 1341 Model", (work in progress), Internet Draft, 1342 draft-ietf-ipfix-info-06.txt, October 2004. 1344 [3] Claise, B., Bryant, S., Sadasivan, G. and M. Fullmer, "IPFIX: 1345 Protocol", (work in progress), Internet Draft, 1346 draft-ietf-ipfix-protocol-07.txt, December 2004. 1348 [4] Zseby, T., Boschi, E., Penno, R., Brownlee, N. and B. Claise, 1349 "IPFIX: Protocol", (work in progress), Internet Draft, 1350 draft-ietf-ipfix-protocol-03.txt, October 2004. 1352 17.2 Non-normative References 1354 [5] Leinen, S., "Evaluation of Candidate Protocols for IP Flow 1355 Information Export", RFC 3955, October 2004. 1357 [6] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1358 Considerations Section in RFCs", RFC 2434, October 1998. 1360 Authors' Addresses 1362 Ganesh Sadasivan 1363 Cisco Systems, Inc. 1364 170 West Tasman Drive 1365 San Jose, CA 95134 1366 USA 1368 Phone: +1 408 527-0251 1369 EMail: gsadasiv@cisco.com 1371 Nevil Brownlee 1372 CAIDA | The University of Auckland 1373 Private Bag 92019 1374 Auckland 1375 New Zealand 1377 Phone: +64 9 373 7599 x8941 1378 EMail: n.brownlee@auckland.ac.nz 1379 Benoit Claise 1380 Cisco Systems, Inc. 1381 De Kleetlaan 6a b1 1382 1831 Diegem 1383 Belgium 1385 Phone: +32 2 704 5622 1386 EMail: bclaise@cisco.com 1388 Juergen Quittek 1389 NEC Europe Ltd. 1390 Adenauerplatz 6 1391 69225 Heidelberg 1392 Germany 1394 Phone: +49 6221 90511-15 1395 EMail: quittek@ccrle.nec.de 1397 Intellectual Property Statement 1399 The IETF takes no position regarding the validity or scope of any 1400 Intellectual Property Rights or other rights that might be claimed to 1401 pertain to the implementation or use of the technology described in 1402 this document or the extent to which any license under such rights 1403 might or might not be available; nor does it represent that it has 1404 made any independent effort to identify any such rights. Information 1405 on the procedures with respect to rights in RFC documents can be 1406 found in BCP 78 and BCP 79. 1408 Copies of IPR disclosures made to the IETF Secretariat and any 1409 assurances of licenses to be made available, or the result of an 1410 attempt made to obtain a general license or permission for the use of 1411 such proprietary rights by implementers or users of this 1412 specification can be obtained from the IETF on-line IPR repository at 1413 http://www.ietf.org/ipr. 1415 The IETF invites any interested party to bring to its attention any 1416 copyrights, patents or patent applications, or other proprietary 1417 rights that may cover technology that may be required to implement 1418 this standard. Please address the information to the IETF at 1419 ietf-ipr@ietf.org. 1421 The IETF has been notified of intellectual property rights claimed in 1422 regard to some or all of the specification contained in this 1423 document. For more information consult the online list of claimed 1424 rights. 1426 Disclaimer of Validity 1428 This document and the information contained herein are provided on an 1429 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1430 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1431 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1432 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1433 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1434 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1436 Copyright Statement 1438 Copyright (C) The Internet Society (2005). This document is subject 1439 to the rights, licenses and restrictions contained in BCP 78, and 1440 except as set forth therein, the authors retain all their rights. 1442 Acknowledgment 1444 Funding for the RFC Editor function is currently provided by the 1445 Internet Society.