idnits 2.17.1 draft-ietf-ipfix-architecture-04.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 1404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1389. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 193: '... MUST vs must:...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 9, 2004) is 7138 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 288 ** Downref: Normative reference to an Informational draft: draft-ietf-ipfix-reqs (ref. '1') ** Downref: Normative reference to an Informational draft: draft-leinen-ipfix-eval-contrib (ref. '2') == Outdated reference: A later version (-15) exists of draft-ietf-ipfix-info-03 == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-03 ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 8 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: April 9, 2005 CAIDA | The University of Auckland 5 B. Claise 6 Cisco Systems, Inc. 7 J. Quittek 8 NEC Europe Ltd. 9 October 9, 2004 11 Architecture for IP Flow Information Export 12 draft-ietf-ipfix-architecture-04 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 April 9, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). 45 Abstract 47 This memo defines the IPFIX architecture for the selective monitoring 48 of IP flows, and for the export of measured IP flow information from 49 an IPFIX device to a collector, as per the requirements set out in 50 the IPFIX requirements document. 52 Table of Contents 54 1. Architecture Issues . . . . . . . . . . . . . . . . . . . . 4 55 2. Changes/Issues from the -03 Draft . . . . . . . . . . . . . 5 56 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Examples of Flows . . . . . . . . . . . . . . . . . . . . . 10 60 7. IPFIX Reference Model . . . . . . . . . . . . . . . . . . . 12 61 8. IPFIX Functional and Logical Blocks . . . . . . . . . . . . 13 62 8.1 Metering Process . . . . . . . . . . . . . . . . . . . . . 13 63 8.1.1 Flow Expiration and Export . . . . . . . . . . . . . . 14 64 8.2 Observation Point . . . . . . . . . . . . . . . . . . . . 15 65 8.3 Selection Criteria for Packets . . . . . . . . . . . . . . 15 66 8.3.1 Filter Functions, Fi . . . . . . . . . . . . . . . . . 15 67 8.3.2 Sampling Functions, Si . . . . . . . . . . . . . . . . 16 68 8.4 Observation Domain . . . . . . . . . . . . . . . . . . . . 16 69 8.5 Exporting Process . . . . . . . . . . . . . . . . . . . . 16 70 8.6 Collecting Process . . . . . . . . . . . . . . . . . . . . 17 71 8.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 9. Overview of the IPFIX Protocol . . . . . . . . . . . . . . . 19 73 9.1 Information Model Overview . . . . . . . . . . . . . . . . 19 74 9.2 Flow records . . . . . . . . . . . . . . . . . . . . . . . 20 75 9.3 Control Information . . . . . . . . . . . . . . . . . . . 20 76 9.4 Exporting Control Information . . . . . . . . . . . . . . 20 77 9.5 Reporting Responsibilities . . . . . . . . . . . . . . . . 21 78 10. IPFIX Protocol Details . . . . . . . . . . . . . . . . . . . 21 79 10.1 The IPFIX Basis Protocol . . . . . . . . . . . . . . . . 21 80 10.2 IPFIX Protocol on the Collecting Process . . . . . . . . 22 81 10.3 Support for Applications . . . . . . . . . . . . . . . . 22 82 11. Export Models . . . . . . . . . . . . . . . . . . . . . . . 23 83 11.1 Export with Reliable Control Connection . . . . . . . . 23 84 11.2 Collector Failure Detection and Recovery . . . . . . . . 23 85 11.3 Collector Redundancy . . . . . . . . . . . . . . . . . . 24 86 12. IPFIX Flow Collection for Special Traffic . . . . . . . . . 24 87 13. IPFIX Flow Collection from Special Devices . . . . . . . . . 25 88 14. Security Considerations . . . . . . . . . . . . . . . . . . 25 89 14.1 Data Security . . . . . . . . . . . . . . . . . . . . . 25 90 14.1.1 No Security . . . . . . . . . . . . . . . . . . . . 26 91 14.1.2 Authentication-only . . . . . . . . . . . . . . . . 26 92 14.1.3 Encryption . . . . . . . . . . . . . . . . . . . . . 26 93 14.2 IPFIX End-point Authentication . . . . . . . . . . . . . 27 94 15. IPFIX Overload . . . . . . . . . . . . . . . . . . . . . . . 27 95 15.1 Denial of Service (DoS) Attack Prevention . . . . . . . 27 96 15.1.1 Network Under Attack . . . . . . . . . . . . . . . . 27 97 15.1.2 Generic DoS Attack on the IPFIX System . . . . . . . 28 98 15.1.3 IPFIX Specific DoS Attack . . . . . . . . . . . . . 28 99 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 100 16.1 Numbers used in the Protocol . . . . . . . . . . . . . . 28 101 16.2 Numbers used in the Information Model . . . . . . . . . 29 102 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 103 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 105 Intellectual Property and Copyright Statements . . . . . . . 32 107 1. Architecture Issues 109 ARCH-01: 111 Reduce confusion between 'information element' and 'field:' use 112 'field' when it referring to an element's field within a packet, 113 use 'information element' everywhere else. (DONE) 115 ARCH-02: 117 Add 'Exporter' to terminology section (then we'll have Exporter, 118 Collector, Device. (DONE) 120 ARCH-03: 122 Not clear how Options Template and Options Data should be used. 123 Add text to explain that 125 * data templates specify flow records, 127 * option templates specify options data records, and 129 * options data fields hold information which does not refer to 130 specific flows, e.g. config data or statistics. 132 ARCH-04: 134 Make sure Terminology definitions are consistent with protocol 135 (and requirements) drafts. (DONE) 137 ARCH-05: 139 Change IP addresses in 'Flows' examples to use "documentation 140 prefixes," as per RFC 3330. (DONE, using 198.18/15, network 141 interconnect testing) 143 ARCH-06: 145 Flow aggregates. Remove text, remove Flow Recording Process from 146 'reference model' diagram. (DONE) 148 ARCH-07: 150 There is no `Collecting Process' section. Add one to section 7.5, 151 using relevant text from sections 7.1 and 9.2. (DONE) 153 ARCH-08: 155 There is no Information Model Overview section. Add one. 157 * Info Model defines fields for flow records and option data 158 records 160 * Protocol document describes how fields are encoded in IPFIX 161 messages 163 * Other systems - e.g. PSAMP - may add data or options fields; 164 need to decide on ranges of element ids for each protocol. 166 (DONE) 168 ARCH-09: 170 IPFIX System Overview section needs rewriting. (DONE) 172 ARCH-10: 174 No mention of transport protocols. Need to say "IPFIX designed to 175 be independent of transport, see protocol document for 176 advantages/costs of various protocols." (DONE) 178 ARCH-11: 180 Need text for IANA Considerations section. Nevil and Benoit 181 agreed to write some, including ranges for IPFIX, PSAMP, etc. 183 Suggest the IPFIX chairs and document editors review requests for 184 new field ID numbers. (DONE) 186 ARCH-12: 188 Security Considerations. Can anyone offer more/better text for 189 this section? 191 2. Changes/Issues from the -03 Draft 193 MUST vs must: 195 Since this will be an informational RFC, we now use 196 must/may/should instead of MUST/MAY/SHOULD. 198 Capitals for IPFIX terms: 200 Text changed so that these terms use lower-case before the 201 'terminology' section, where they're defined. After that we 202 always upper-case their first letters. 204 Small editorial changes: 206 Lots of these to fix typos, reorder sections to improve document 207 structure, etc. 209 3. Introduction 211 There are several applications e.g., usage-based accounting, traffic 212 profiling, traffic engineering, attack/intrusion detection, QoS 213 monitoring, that require flow-based IP traffic measurements. It is 214 therefore important to have a standard way of exporting information 215 related to IP flows. This document defines an architecture for IP 216 traffic flow monitoring, measuring and exporting. It provides a 217 high-level description of an IPFIX device's key components and their 218 functions. 220 4. Scope 222 This document defines the architecture for IPFIX. Its main 223 objectives are to: 225 o Describe the key architectural components of IPFIX systems, 226 consisting of (at least) IPFIX exporters and collectors 227 communicating using the IPFIX protocol. 229 o Define the architectural requirements, e.g., recovery, security, 230 etc., for an IPFIX system. 232 o Describe the characteristics of the IPFIX (flow export) protocol. 234 Note that the IPFIX system does not provide for remote configuration 235 of an IPFIX device. Instead, IPFIX devices are configured by network 236 operations staff. 238 5. Terminology 240 The definitions of basic IPFIX terms such as IP Traffic Flow, 241 Exporting Process, Collecting Process, Observation Point, etc. are 242 semantically identical with those found in the IPFIX requirements 243 document IPFIX-REQS [1]. Some of the terms have been expanded for 244 more clarity when defining the protocol. Additional terms required 245 for the architecture have also been defined. For the same terms 246 defined here and in IPFIX-PROTO [4] the definitions are equivalent in 247 both documents. 249 * Observation Point 251 An Observation Point is a location in the network where IP packets 252 can be observed. Examples include: a line to which a probe is 253 attached, a shared medium, such as an Ethernet-based LAN, a single 254 port of a router, or a set of interfaces (physical or logical) of 255 a router. 257 Note that one Observation Point may be a superset of several other 258 Observation Points. For example one Observation Point can be an 259 entire line card. That would be the superset of the individual 260 Observation Points at the line card's interfaces. 262 * Observation Domain 264 The set of Observation Points which is the largest aggregatable 265 set of Flow information at the Metering Process is termed an 266 Observation Domain. Each Observation Domain presents itself using 267 a unique ID to the Collecting Process to identify the IPFIX 268 Messages it generates. For example, a router line card may be 269 composed of several interfaces with each interface being an 270 Observation Point. Every Observation Point is associated with an 271 Observation Domain. 273 * IP Traffic Flow or Flow 275 There are several definitions of the term 'flow' being used by the 276 Internet community. Within the context of IPFIX we use the 277 following definition: 279 A Flow is defined as a set of IP packets passing an Observation 280 Point in the network during a certain time interval. All packets 281 belonging to a particular Flow have a set of common properties. 282 Each property is defined as the result of applying a function to 283 the values of: 285 1. One or more packet header field (e.g. destination IP 286 address), transport header field (e.g. destination port 287 number), or application header field (e.g. RTP header fields 288 [RFC1889]) 290 2. One or more characteristics of the packet itself (e.g. number 291 of MPLS labels) 293 3. One or more fields derived from packet treatment (e.g. next 294 hop IP address, output interface) 296 A packet is said to belong to a Flow if it completely satisfies 297 all the defined properties of the Flow. 299 This definition covers the range from a Flow containing all 300 packets observed at a network interface to a Flow consisting of 301 just a single packet between two applications with a specific 302 sequence number. 304 * Flow Key 306 Each of the fields which 308 1. Belong to the packet header (e.g. destination IP address) 310 2. Are a property of the packet itself (e.g. packet length) 312 3. Are derived from packet treatment (e.g. AS number) 314 and which are used to define a Flow are termed Flow Keys. 316 * Flow Record 318 A Flow Record contains information about a specific Flow that was 319 observed at an Observation Point. A Flow Record contains measured 320 properties of the Flow (e.g. the total number of bytes for all 321 the Flow's packets) and usually characteristic properties of the 322 Flow (e.g. source IP address). 324 * Metering Process 326 A Metering Process generates Flow Records. Input to the process 327 are packet headers observed at an Observation Point, and packet 328 treatment at the Observation Point. 330 The Metering Process consists of a set of functions that includes 331 packet header capturing, timestamping, sampling, classifying, and 332 maintaining Flow Records. 334 The maintenance of Flow Records may include creating new records, 335 updating existing ones, computing Flow statistics, deriving 336 further Flow properties, detecting Flow expiration, passing Flow 337 Records to the Exporting Process, and deleting Flow Records. 339 * Exporting Process 341 An Exporting Process sends Flow Records to one or more Collecting 342 Processes. The Flow Records are generated by one or more Metering 343 Processes. 345 * Exporter 347 A device which hosts one or more Exporting Processes is termed an 348 Exporter. 350 * IPFIX Device 352 An IPFIX Device hosts at least one Observation Point, a Metering 353 Process and an Exporting Process. Typically, corresponding 354 Observation Point(s), Metering Process(es) and Exporting 355 Process(es) are co-located at such a device, for example at a 356 router. 358 * Collecting Process 360 A Collecting Process receives Flow Records from one or more 361 Exporting Processes. The Collecting Process might process or 362 store received Flow Records, but such actions are out of scope for 363 this document. 365 * Collector 367 A device which hosts one or more Collecting Processes is termed a 368 Collector. 370 * Template 372 A Template is an ordered sequence of pairs, used to 373 completely identify the structure and semantics of a particular 374 set of information that needs to be communicated from an IPFIX 375 Device to a Collector. Each Template is uniquely identifiable by 376 means of a Template ID. 378 * Control Information, Data Stream 380 The information that needs to be exported from the IPFIX Device 381 can be classified into the following categories: 383 Control Information 384 This includes the Flow definition, selection criteria for 385 packets within the Flow sent by the Exporting Process, and any 386 IPFIX protocol messages. The Control Information carries all 387 the information needed for the end-points to understand the 388 IPFIX protocol, and specifically for the receiver (Collector) 389 to understand and interpret the data sent by the sender 390 (Exporter). 392 Data Stream 394 This includes Flow Records carrying the field values for the 395 various observed Flows at each of the Observation Points. 397 IPFIX Message 399 An IPFIX Message is a message originating at the Exporting 400 Process that carries the IPFIX records of this Exporting 401 Process and whose destination is a Collecting Process. An 402 IPFIX Message is encapsulated within a transport layer header. 404 6. Examples of Flows 406 Some examples of Flows are listed below: 408 Example 1: To create Flows, the different fields to distinguish Flows 409 are defined. The different combination of the field values creates 410 unique Flows. If the Flow Key is defined as {source IP address, 411 destination IP address, DSCP}, then all of these are different Flows. 413 1. {198.18.40.1, 198.18.23.5, 4} 414 2. {198.18.40.23, 198.18.23.67, 4} 415 3. {198.18.40.23, 198.18.23.67, 2} 416 4. {198.18.20.200, 198.18.23.67, 4} 418 Example 2: To create Flows, a match function can be applied to all 419 the packets that pass through an Observation Point, in order to 420 aggregate some values. This could be done by defining the Flow Key 421 as {source IP address, destination IP address, DSCP} as in example 1 422 above, and applying a function which masks out the least significant 423 8 bits of the source IP address and destination IP address (i.e. the 424 result is a /24 address). The four Flows from example 1 would now be 425 aggregated into three Flows by merging the Flows 1 and 2 into a 426 single Flow. 428 1. {198.18.40.0/24, 198.18.23.0/24, 4} 429 2. {198.18.40.0/24, 198.18.23.0/24, 2} 430 3. {198.18.20.0/24, 198.18.23.0/24, 4} 432 Example 3: To create Flows, a filter defined by some field values can 433 be applied on all packets that pass the Observation Point, in order 434 to select only certain Flows. The filter is defined by choosing 435 fixed values for specific fields from the packet. 437 All the packets that go from a customer network 198.18.40.0/24 to 438 another customer network 198.18.23.0/24 with DSCP value of 4 define a 439 Flow. All other combinations don't define a Flow and are not taken 440 into account. The three Flows from example 2 would now be reduced to 441 one Flow by filtering away the second and the third Flow, leaving 442 only {198.18.40.0/24, 198.18.23.0/24, 4}. 444 The above example can be thought of as a function F() taking as input 445 {source IP address, destination IP address, DSCP}. The function 446 selects only the packets which satisfy all three of the following 447 conditions: 449 1. Mask out the least significant 8 bits of source IP address, match 450 against 198.18.40.0. 452 2. Mask out the least significant 8 bits of destination IP address, 453 match against 198.18.23.0. 455 3. Only accept DSCP value equal to 4. 457 Depending on the values of {source IP address, destination IP 458 address, DSCP} of the different observed packets, the Metering 459 Process function F() would choose/filter/aggregate different sets of 460 packets, which would create different Flows. For example, various 461 combination of values of {source IP address, destination IP address, 462 DSCP}, F(source IP address, destination IP address, DSCP) would 463 result in the definition of one or more Flows. 465 7. IPFIX Reference Model 467 The figure below shows the reference model for IPFIX. This figure 468 covers the various possible scenarios that can exist in an IPFIX 469 system. 471 +----------------+ +----------------+ 472 |[*Application 1]| ..|[*Application n]| 473 +--------+-------+ +-------+--------+ 474 ^ ^ 475 ~ ~ 476 +~~~~~~~~~~+~~~~~~~~+ 477 ^ 478 ~ 479 +------------------------+ +-------+------------------+ 480 |IPFIX Device(1) | | Collector(1) | 481 |[Exporting Process(es)] |<----------->| [Collecting Process(es)] | 482 +------------------------+ +--------------------------+ 483 .... .... 484 +------------------------+ +---------------------------+ 485 |IPFIX Device(i) | | Collector(j) | 486 |[Obsv Point(s)] |<---------->| [Collecting Process(es)] | 487 |[Metering Process(es)] | +---->| [*Application(s)] | 488 |[Exporting Process(es)] | | +---------------------------+ 489 +------------------------+ . 490 .... . .... 491 +------------------------+ | +--------------------------+ 492 |IPFIX Device(m) | | | Collector(n) | 493 |[Obsv Point(s)] |<-----+---->| [Collecting Process(es)] | 494 |[Metering Process(es)] | | [*Application(s)] | 495 |[Exporting Process(es)] | +--------------------------+ 496 +------------------------+ 498 The various functional components are indicated within brackets []. 499 The functional components within [*] are not part of the IPFIX 500 framework. The interfaces shown by "<-->" are defined by the IPFIX 501 framework but those shown by "<~~>" are not. 503 The figure below shows a typical IPFIX Device. 505 +--------------------------------------------------+ 506 | IPFIX Device | 507 | +-----+ | 508 | +---......--+------------+---------> | | 509 | | | | | | 510 | +----+----+ +----+----+ | | | 511 | |Metering | |Metering | | E | | 512 | |Process 1| |Process N| | x | | 513 | |(Packet | |(Packet | | p | | 514 | | Level) | | Level) | | o | | 515 | +---------+ +---------+ | r | | 516 | ^ ^ | t | | 517 |+-------+-----------------------+-------+ | i | | 518 || | Observation Domain 1 | | | n | | 519 || +-----+------+ +-----+------+| | g | | 520 || |Obsv Point 1| ... |Obsv Point M|| | | | 521 || +------------+ +------------+| | | | 522 Packets|+-------^-------------------------^-----+ | | | Export 523 --->---+--------+----------.....----------+ | | | Pkts to 524 In | | +-------> 525 | . . . . . | | |Collector 526 | | | | 527 | +---......--+------------+---------> | | 528 | | | | | | 529 | +----+----+ +----+----+ | P | | 530 | |Metering | |Metering | | r | | 531 | |Process 1| |Process N| | o | | 532 | +---------+ +---------+ | c | | 533 | ^ ^ | e | | 534 |+-------+-----------------------+-------+ | s | | 535 || | Observation Domain K | | | s | | 536 || +-----+------+ +-----+------+| | | | 537 || |Obsv Point 1| ... |Obsv Point M|| | | | 538 || +------------+ +------------+| | | | 539 Packets|+-------^-------------------------^-----+ +-----+ | 540 --->---+--------+---------- ... ----------+ | 541 In | | 542 +--------------------------------------------------+ 544 In the above figure the IPFIX components are shown in rectangular 545 boxes. Note that in case of multiple Observation Domains, a unique 546 ID per Observation Domain must be transmitted as a parameter to the 547 exporting function. That unique ID is referred to as the IPFIX 548 Soutrce ID. The Exporting Process includes IPFIX protocol and 549 underlying transport layer. 551 8. IPFIX Functional and Logical Blocks 553 8.1 Metering Process 555 Every Observation Point in an IPFIX Device, participating in Flow 556 measurements, must be associated with at least one Metering Process. 557 Every packet coming into an Observation Point goes into each of the 558 Metering Processes associated with the Observation Point. Broadly, 559 each Metering Process extracts the packet headers that come into an 560 Observation Point, does timestamping and classifies the packet into 561 Flow(s) based on the selection criteria. 563 The Metering Process is a functional block which manages all the 564 Flows generated from an Observation Domain. The typical functions of 565 a Metering Process may include: 567 o Maintain database(s) of all the Flows Records from an Observation 568 Domain. This includes creating new Flow Records, updating 569 existing ones, computing Flow Records statistics, deriving further 570 Flow properties, adding non-flow-specific information based on the 571 packet treatment (in some cases fields like AS numbers, router 572 state, etc.) 574 o Maintain aggregate statistics like flows generated, flows exported 575 etc. 577 8.1.1 Flow Expiration and Export 579 A Flow is considered to have expired, and may be exported, under the 580 following conditions: 582 1. If the Metering Process can deduce the end of a Flow, that Flow 583 should be exported when the end of the Flow is detected. For 584 example, a Flow generated by TCP traffic where the FIN or RST 585 bits indicate the end of the Flow. 587 2. If no packets belonging to the Flow have been observed for a 588 certain period of time. This time period should be configurable 589 at the Metering Process, with a minimum value of 0 seconds for 590 immediate expiration. Note that a zero timeout would report a 591 Flow as a sequence of single-packet Flows. 593 3. If the IPFIX Device experiences resource constraints, a Flow may 594 be prematurely expired (e.g. lack of memory to store Flow 595 Records) 597 4. For long-running Flows, the Exporting Process should export the 598 Flow Records on a regular basis or based on some export policy. 599 This periodicity or export policy should be configurable at the 600 Metering Process. 602 When a long-running Flow is exported, that Flow may still be 603 maintained by the Metering Process so that, for incoming packets 604 which continue to come on the same Flow, the Metering Process does 605 not need to create a new Flow. 607 8.2 Observation Point 609 A Flow Record can be better analyzed if the Observation Point from 610 which it was measured is known. As such it is recommended that 611 Exporters send this information to Collectors. In cases where there 612 is a single Observation Point or where the Observation Point 613 information is not relevant, the Metering Process may choose not to 614 add this to the Flow Records. 616 8.3 Selection Criteria for Packets 618 A Metering Process may define rules so that only certain packets 619 within an incoming stream of packets are chosen for measurement at an 620 Observation Point. This may be done by one of the two methods 621 defined below or a combination of them. A combination of each of 622 these methods can be adopted to select the packets, i.e. one can 623 define a set of methods {F1, S1, F2, S2, S3} executed in a specified 624 sequence at an Observation Point to select particular Flows. 626 The figure below shows the operations which may be applied as part of 627 a typical Metering Process. 629 packet header capturing 630 | 631 timestamping 632 | 633 v 634 +----->+ 635 | | 636 | sampling Si (1:1 in case of no sampling) 637 | | 638 | filtering Fi (select all when no criteria) 639 | | 640 +------+ 641 | 642 v 643 Flows 645 8.3.1 Filter Functions, Fi 647 A Filter Function selects only those incoming packets that satisfy a 648 function on fields defined by the packet header fields, fields 649 obtained while doing the packet processing, or properties of the 650 packet itself. 652 Example: Mask/Match of the fields that define a filter. A filter 653 might be defined as {Protocol == TCP, Destination Port between 80 and 654 120}. 656 Several such filters could be used in any sequence to select packets. 657 Note that packets selected by a (sequence of) filter functions may be 658 further classified by other filter functions, i.e. the selected 659 packets may belong to several Flows, all of which are exported. 661 8.3.2 Sampling Functions, Si 663 A sampling function determines which packets within a stream of 664 incoming packets is selected for measurement, i.e. packets that 665 satisfy the sampling criteria for this Metering Process. 667 Example: sample every 100th packet that was received at an 668 Observation Point and collect the Flow Records selected by a 669 particular filter function. Choosing all the packets is a special 670 case where the sampling rate is 1:1. 672 Note that filtering and sampling functions may also be used in an 673 Exporting Process to select Flow Records to be exported. 675 8.4 Observation Domain 677 The Observation Domain is a logical block that presents a single 678 identity for a group of Observation Points within an IPFIX Device. 679 Each {Observation Point, Metering Process} pair belongs to a single 680 Observation Domain. An IPFIX Device could have multiple Observation 681 Domains each of which has a subset of the total set of Observation 682 Points in it. Each Observation Domain must carry a unique ID within 683 the context of an IPFIX Device. 685 8.5 Exporting Process 687 The Exporting Process is the functional block that sends data to one 688 or more IPFIX Collectors using the IPFIX protocol. On one side it 689 interfaces with Metering Process to get Flow Records, while on the 690 other side the Exporting Process talks to a Collecting Process on the 691 Collector(s). 693 There may be additional rules defined within the context Observation 694 Domain so that only certain Flows Records are picked up for export. 695 This may be done by either one or a combination of Si, Fi, as 696 described in the section on "Selection Criteria for Packets". 698 Example: Only the Flow Records which meet the following selection 699 criteria are exported. 701 1. All Flow Records whose destination IP address matches 702 {198.18.33.5}. 704 2. Every other (.i.e. sampling rate 1 in 2) Flow Record whose 705 destination IP address matches {198.18.11.30}. 707 8.6 Collecting Process 709 Collecting Processes use a Flow Record's Template ID to interpret 710 that Record's Information Elements. To allow this, an IPFIX Exporter 711 must ensure that an IPFIX Collector knows the Template ID for each 712 incoming Flow Record. To interpret incoming Flow Records, an IPFIX 713 Collector may also need to know the function F() that was used by the 714 Metering Process for each Flow. 716 An IPFIX Collector may also use the selection criteria for packets to 717 interpret the Flow Records further. 719 The functions of the Collecting Process must include: 721 o Identifying, accepting and decoding the IPFIX Messages from 722 different pairs. 724 o Storing the Control Information and Flow Records received from an 725 IPFIX Device. 727 At a high level, the IPFIX protocol at the Collecting Process: 729 1. Receives and stores the Control Information. 731 2. Decodes and stores the Flow Records using the Control 732 Information. 734 3. May optionally monitor the status of the Collecting Process and 735 execute a failover should any problem arise. 737 8.7 Summary 739 The figure below shows the functions performed in sequence by the 740 various functional blocks in an IPFIX Device. 742 Packet(s) coming into Observation Point(s) 743 | | 744 v v 745 +----------------+-------------------------+ +-----+-------+ 746 | Metering Process on an | | | 747 | Observation Point | | | 748 | packet header capturing | | | 749 | | | | Metering | 750 | timestamping | | Process | 751 | | | | on an | 752 | +----->+ | | Observation | 753 | | | | | Point | 754 | | sampling Si (1:1 in case of no | | | 755 | | | sampling) | | | 756 | | classifying Fi (select all when | | | 757 | | | no criteria) | | | 758 | +------+ | | | 759 | | | | | 760 | | Timing out Flows | | | 761 | | Handle resource overloads | | | 762 +--------|---------------------------------+ +-----|-------+ 763 | | 764 Flow Records (identified by Observation Domain) Flow Records 765 | | 766 +---------+---------------------------------+ 767 | 768 +--------------------|----------------------------------------------+ 769 | | Exporting Process | 770 |+-------------------|-------------------------------------------+ | 771 || v IPFIX Protocol | | 772 ||+-----------------------------+ +----------------------------+| | 773 |||Rules for | |Functions || | 774 ||| Picking/sending Templates | |-Packetize selected Control || | 775 ||| Picking/sending Flow Records|->| & data Information into || | 776 ||| Encoding Template & data | | IPFIX export packet. ||--> 777 ||| Selecting Flows to export(*)| |-Handle export errors || | 778 ||+-----------------------------+ +----------------------------+| | 779 |+----------------------------+----------------------------------+ | 780 | | | 781 | IPFIX exported packet | 782 | | | 783 | +------------+-----------------+ | 784 | | Anonymize export packet(*) | | 785 | +------------+-----------------+ | 786 | | | 787 | +------------+-----------------+ | 788 | | Transport Protocol | | 789 | +------------+-----------------+ | 790 | | | 791 +-----------------------------+-------------------------------------+ 792 | 793 v 794 IPFIX export packet to Collector 796 (*) indicates that the block is optional. 798 9. Overview of the IPFIX Protocol 800 An IPFIX Device consists of a set of co-operating processes that 801 implement the functional blocks described in the previous section. 802 Alternatively, an IPFIX Device can be viewed simply as a network 803 entity which implements the IPFIX protocol. At the IPFIX Device, the 804 protocol functionality resides in the Exporting Process. The IPFIX 805 Exporting Process gets Flow Records from a Metering Process, and 806 carries them to the Collector(s). 808 At a high level, an IPFIX Device performs the following tasks: 810 1. Encode Control Information into Templates. 812 2. Encode packets observed at the Observation Points into Flow 813 Records. 815 3. Packetize the selected Templates and Flow Records into IPFIX 816 Messages. 818 4. Send control and data packets to the Collector. 820 The IPFIX protocol communicates information from an IPFIX Exporter to 821 an IPFIX Collector. That information includes not only Flow Records, 822 but also information about the Metering Process. Such information 823 (referred to as Control Information) includes details of the data 824 fields in Flow Records. It may also include statistics from the 825 Metering Process, such as the number of packets lost (i.e. not 826 metered). 828 For details of the IPFIX protocol please refer to IPFIX-PROTO [4]. 830 9.1 Information Model Overview 832 The IP Flow Information eXport (IPFIX) protocol serves for 833 transmitting information related to measured IP traffic over the 834 Internet. The protocol specification in IPFIX-PROTO [4] defines how 835 information elements are transmitted. For information elements, it 836 specifies the encoding of a set of basic data types. However, the 837 list of fields that can be transmitted by the protocol, such as flow 838 attributes (source IP address, number of packets, etc.) and 839 information about the metering and exporting process (packet 840 observation point, sampling rate, flow timeout interval, etc.), is 841 not specified in IPFIX-PROTO [4]. Instead, it is defined in the 842 IPFIX Information Model document IPFIX-INFO [3]. 844 The Information Model provides a complete description of the 845 properties of every IPFIX information element. It does this by 846 specifying each element's name, Field Type, data type, etc., and 847 providing a description of each element. Element descriptions give 848 the semantics of the element, i.e. say how it is derived from a Flow 849 or other information available within an IPFIX Device. 851 9.2 Flow records 853 The following rules provide guidelines to be followed while encoding 854 the Flow's information: 856 A Flow Record contains enough information so that the Collecting 857 Process can identify the corresponding . 860 The Exporter encodes a given field (as specified in IPFIX-INFO [3], 861 based on the encoding standards prescribed by IPFIX-PROTO [4]. 863 9.3 Control Information 865 The following rules provide guidelines to be followed while encoding 866 the Control Information: 868 o Per-Flow Control Information should be encoded such that the 869 Collecting Process can capture the structure and semantics of the 870 corresponding Flow data for each of the Flows exported by the 871 IPFIX Device. 873 o Configuration Control Information is conveyed to a Collector so 874 that its Collecting Process can capture the structure and 875 semantics of the corresponding configuration data. The 876 configuration data which is also Control Information should carry 877 additional information on the Observation Domain within which the 878 configuration takes effect. For example, sampling using the same 879 sampling algorithm, say 1 in 100 packets, is configured on two 880 Observation Points O1 and O2. The configuration in this case may 881 be encoded as , where ID uniquely identifies this 883 configuration. 885 9.4 Exporting Control Information 887 The Control Information is used by the Collecting Process to: 889 o Decode and interpret Flow Records. 891 o Understand the state of the Exporting Process. 893 Sending Control Information from the Exporting Process in a timely 894 and reliable manner is critical to the proper functioning of the 895 IPFIX Collecting Process. The following approaches may be taken for 896 the export of Control Information. 898 1. Send all the Control Information pertaining to Flow Records prior 899 to sending the Flow Records themselves. This includes any 900 incremental changes to the definition of the Flow Records. 902 2. Notify on a near real time basis the state of the IPFIX Device to 903 the Collecting Process. This includes all changes such as a 904 configuration change that affects the Flow behavior, changes to 905 Exporting Process resources that alter export rates, etc., which 906 the Collector needs to be aware of. 908 3. Since it is vital that a Collecting Process maintains accurate 909 knowledge of the Exporter's state, the export of the Control 910 Information should be done such that that it reaches the 911 Collector reliably. One way to achieve this would be to send the 912 Control Information over a reliable transport. 914 9.5 Reporting Responsibilities 916 From time to time an IPFIX Device may not be able to observe all the 917 packets reaching one of its Observation Points. This could occur if 918 a Metering Process finds itself temporarily short of resources, for 919 example it might run out of packet buffers for IPFIX export, or it 920 might detect errors in its underlying transport layer. 922 In such situations, the IPFIX Device must report to its Collector(s) 923 the number of packet losses that have occurred. 925 10. IPFIX Protocol Details 927 When the IPFIX Working Group was chartered there were existing common 928 practices in the area of Flow export, for example NetFlow, CRANE, 929 LFAP, RTFM, etc. IPFIX's charter required the Working Group to 930 consider those existing practices, and select the one that was the 931 closest fit to the IPFIX requirements IPFIX-REQS [1]. Additions or 932 modifications would then be made to the selected protocol to fit it 933 exactly into the IPFIX architecture. 935 10.1 The IPFIX Basis Protocol 937 The working group went through an extensive evaluation of the various 938 existing protocols that were available, weighing the level of 939 compliance with the requirements, and selected one of the candidates 940 as the basis for the IPFIX protocol. For more details of the 941 evaluation process please see IPFIX-EVAL [2]. 943 In the basis protocol Flow Records are defined by Templates, where a 944 Template is an ordered set of the information elements appearing in a 945 Flow Record, together with their field sizes within those records. 947 This approach provides the following advantages: 949 o Using the Template mechanism, new fields can be added to IPFIX 950 Flow Records without changing the structure of the export record 951 format. 953 o Templates that are sent to the Collecting Process carry structural 954 information about the exported Flow Record fields. Therefore, if 955 the Collector does not understand the semantics of new fields it 956 can ignore them, but still interpret the Flow Record. 958 o Because the template mechanism is flexible, it allows the export 959 of only the required fields from the Flows to the Collecting 960 Process. This helps to reduce the exported Flow data volume and 961 possibly provide memory savings at the Exporting Process and 962 Collecting Process. Sending only the required information can 963 also reduce network load. 965 10.2 IPFIX Protocol on the Collecting Process 967 The Collecting process is responsible for: 969 1. Receiving and decoding Flow Records from the IPFIX Devices. 971 2. Indicating Flow Record losses to the exporting IPFIX Device 972 and/or IPFIX users. 974 3. Optionally notifying status and overload conditions to the IPFIX 975 Device. 977 Complete details of the IPFIX protocol are given in IPFIX-PROTO [4]. 979 10.3 Support for Applications 981 Applications that use the information collected by IPFIX may be 982 Billing or Intrusion Detection sub-systems, etc. These applications 983 may be an integral part of the Collecting Process or they may be 984 co-located with the Collecting Process. The way by which these 985 applications interface with IPFIX system to get the desired 986 information is out of scope for this document. 988 11. Export Models 990 11.1 Export with Reliable Control Connection 992 As mentioned in the IPFIX-REQS [1] document, an IPFIX Device must be 993 able to transport its Control Information and Data Stream over a 994 congestion-aware transport protocol. 996 If the network in which the IPFIX Device and Collecting Process are 997 located does not guarantee reliability, at least the Control 998 Information should be exported over a reliable transport. The Data 999 Stream may be exported over a reliable or unreliable transport 1000 protocol. 1002 Possible transport protocols include: 1004 o SCTP: Supports reliable and unreliable transport. Some of SCTP's 1005 features (e.g. session failover) may prove unfamiliar to IPFIX 1006 implementors. 1008 o TCP: Provides reliable transport only. Simple to implement, may 1009 require large buffers to cope with periods of network congestion. 1011 o UDP: Provides unreliable transport only. Network operators would 1012 need to avoid congestion by keeping traffic within their own 1013 administrative domains. 1015 11.2 Collector Failure Detection and Recovery 1017 The transport connection (in the case of a connection oriented 1018 protocol) is pre-configured between the IPFIX Device and the 1019 Collector. The IPFIX protocol does not provide any mechanism for 1020 configuring the Metering or Exporting Processes. 1022 Once connected, an IPFIX Collector receives Control Information and 1023 uses that information to interpret Flow Records. The IPFIX Device 1024 should set a keepalive (e.g. the keepalive timeout in the case of 1025 TCP, the HEARTBEAT interval in the case of SCTP, or an IPFIX protocol 1026 level keepalive if any) to a sufficiently low value so that it can 1027 quickly detect a Collector failure. 1029 Collector failure refers to the crash or restart of the Collecting 1030 Process, or of the Collector itself. A Collector failure is detected 1031 at the IPFIX Device by the break in control connection (depending on 1032 the transport protocol - the connection timeout mechanisms differ). 1033 On detecting a keepalive timeout, the IPFIX Device should stop 1034 sending the Flow export data to the Collector and try to reestablish 1035 the transport connection. This is valid for a single Collector 1036 scenario. If there are multiple Collectors for the same IPFIX 1037 Device, the IPFIX Device opens control connections to each of the 1038 Collectors. However, data gets sent only to one of the Collectors 1039 which is chosen as the primary. 1041 There could be one or more Collectors configured as secondary and a 1042 priority assigned to them. The primary Collector crash is detected 1043 at the IPFIX Device by the break in control connection (depending on 1044 the transport protocol - the connection timeout mechanisms differ). 1045 On detecting loss of connectivity, the IPFIX Device opens a Data 1046 Stream with the secondary Collector of the next highest priority. 1047 That Collector now becomes the primary. The maximum export data loss 1048 would be the amount of data exported in the time between when the 1049 loss of connectivity to the Collector happened, and the time at which 1050 this was detected by the IPFIX Device. 1052 11.3 Collector Redundancy 1054 Since the IPFIX protocol requires a congestion-aware transport, 1055 achieving redundancy using multicast is not an option. Multiple 1056 pairs could be set up, each to a 1057 different Collector from the same IPFIX Device. The Control and data 1058 Information would then be replicated on each of the Control 1059 Information and Data Streams. 1061 12. IPFIX Flow Collection for Special Traffic 1063 An IPFIX Device could be doing one or more of generating, receiving, 1064 altering special types of traffic which are listed below. 1066 Tunnel traffic: 1068 The IPFIX Device could be the head, midpoint or endpoint of a 1069 tunnel. In such cases the IPFIX could be handling GRE, IPinIP or 1070 UTI traffic. 1072 VPN traffic: 1074 The IPFIX Device could be a provider edge device which receives 1075 traffic from customer sites belonging to different Virtual Private 1076 Networks. 1078 In the cases above, there should be clear guidelines as to: 1080 o How and when to classify the packets as Flows in the IPFIX Device. 1082 o If multiple encapsulations are used to define Flows, how to convey 1083 the same fields (e.g. IP address) in different layers. 1085 o How to differentiate Flows based on different private domains. 1086 For example, overlapping IP addresses in Layer-3 VPNs 1088 13. IPFIX Flow Collection from Special Devices 1090 IPFIX could be implemented on devices which perform one or more of 1091 the following special services: 1093 o Explicitly drop packets. For example a device which provides 1094 firewall service drops packets based on some administrative 1095 policy. 1097 o Alter the values of fields used as IPFIX Flow keys of interest. 1098 For example a device which provides NAT service can change source 1099 or(and) destination IP address. 1101 In the cases above, there should be clear guidelines as to: 1103 o How and when to classify the packets as Flows in the IPFIX Device. 1105 o What extra information be exported so that the Collector can make 1106 a clear interpretation of the received Flow Records. 1108 14. Security Considerations 1110 IP Flow information can be used for various purposes, such as usage 1111 accounting, traffic profiling, traffic engineering, and intrusion 1112 detection. The security requirement may differ significantly for 1113 such applications. To be able to satisfy the security needs of 1114 various IPFIX users, an IPFIX system must provide different levels of 1115 security protection. 1117 14.1 Data Security 1119 IPFIX data comprises Control Information and Data Stream generated by 1120 the IPFIX Device. 1122 The IPFIX data may exist in both the IPFIX Device and the Collector. 1123 In addition, the data is also transferred on the wire from the IPFIX 1124 Device to the Collector when it is exported. To provide security, 1125 the data should be protected from common network attacks. 1127 The protection of IPFIX data within the end system (IPFIX Device and 1128 Collector) is out of scope for this document. It is assumed that the 1129 end system operator will provide adequate security for the IPFIX 1130 data. 1132 The IPFIX architecture must allow different levels of protection to 1133 the IPFIX data on the wire. Wherever security functions are required 1134 it is recommended that users should leverage lower layers using 1135 either IPSEC or TLS, if these can successfully satisfy the security 1136 requirement of IPFIX data protection. 1138 To protect the data on the wire, three levels of granularity should 1139 be supported .. 1141 14.1.1 No Security 1143 Security may not be required when the transport between the IPFIX 1144 Device and the Collector is perceived as safe. This option allows 1145 the protocol to run most efficiently without extra overhead and an 1146 IPFIX system must support it. 1148 14.1.2 Authentication-only 1150 Authentication-only protection provides IPFIX users with the 1151 assurance of data integrity and authenticity. The data exchanged 1152 between the IPFIX Device and the Collector is protected by an 1153 authentication signature. Any modification of the IPFIX data will be 1154 detected by the recipient, resulting in discarding of the received 1155 data. However, the authentication-only option doesn't offer data 1156 confidentiality. 1158 The IPFIX user should avoid use authentication-only when sensitive or 1159 confidential information is being exchanged. An IPFIX solution 1160 should support this option. The authentication-only option should 1161 provide replay attack protection. Some means to achieve this level 1162 of security are: 1164 o TCP with MD5 options. 1166 o IP Authentication Header 1168 14.1.3 Encryption 1170 Data encryption provides the best protection for IPFIX data. The 1171 IPFIX data is encrypted at the sender and only the intended recipient 1172 can decrypt and have access to the data. This option must be used 1173 when the transport between the IPFIX Device and the Collector are 1174 unsafe and the IPFIX data needs to be protected. It is recommended 1175 that the underlying transport layer's security functions be used for 1176 this purpose. Some means to achieve this level of security are: 1178 o Encapsulating Security Payload. 1180 o Transport Layer Security Protocol 1182 The data encryption option adds overhead to the IPFIX data transfer. 1183 It may limit the rate that an Exporter can report its Flow to the 1184 Collector due to the resource requirement for running encryption. 1186 14.2 IPFIX End-point Authentication 1188 It is important to make sure that the IPFIX Device is talking to the 1189 "right" Collector rather than to a masquerading Collector. The same 1190 logic also holds true from the Collector point of view, i.e. it may 1191 want to make sure it is collecting the Flow information from the 1192 "right" IPFIX Device. An IPFIX system should allow the end point 1193 authentication capability so that either one-way or mutual 1194 authentication can be performed between the IPFIX Device and 1195 Collector. 1197 The IPFIX architecture should use any existing transport protection 1198 protocols such as TLS or IPSEC to fulfill the authentication 1199 requirement. 1201 15. IPFIX Overload 1203 An IPFIX Device could become overloaded under various conditions. 1204 This may be because of exhaustion of internal resources used for Flow 1205 generation and/or export. Such overloading may cause loss of data 1206 from the Exporting Process, either from lack of export bandwidth 1207 (possibly caused by an unusually high number of observed Flows) or 1208 from network congestion in the path from Exporter to Collector. 1210 IPFIX Collectors should be able to detect the loss of exported Flow 1211 Records, and should at least record the number of lost Flow Records. 1213 15.1 Denial of Service (DoS) Attack Prevention 1215 Since one of the potential usages for IPFIX is for intrusion 1216 detection, it is important for the IPFIX architecture to support some 1217 kind of DoS resistance. 1219 15.1.1 Network Under Attack 1221 The Network itself may be under attack, resulting in an overwhelming 1222 number of IPFIX Messages. An IPFIX system should try to capture as 1223 much information as possible. However, when a large number of IPFIX 1224 Messages are generated in a short period of time, the IPFIX system 1225 may become overloaded. 1227 15.1.2 Generic DoS Attack on the IPFIX System 1229 The IPFIX system may subject to generic DoS attacks, just as any 1230 system on any open network. These types of attacks are not IPFIX 1231 specific. Preventing and responding to such types of attacks are out 1232 of the scope of this document. 1234 15.1.3 IPFIX Specific DoS Attack 1236 There are some specific attacks on the IPFIX portion of the IPFIX 1237 Device or Collector. 1239 o The attacker could pound the Collector with spoofed IPFIX export 1240 packets. One way to solve this problem is to periodically 1241 synchronize the sequence numbers of the Flow Records between the 1242 Exporting and Collecting Processes. 1244 o The attacker could provide false reports to the IPFIX Device by 1245 sending spoofed control packets. 1247 The problems mentioned above can be solved to a large extent if the 1248 control packets are encrypted both ways. 1250 16. IANA Considerations 1252 The IPFIX Architecture, as set out in this document, has two sets of 1253 assigned numbers. Considerations for assigning them are discussed in 1254 this section, using the example policies as set out in the 1255 "Guidelines for IANA Considerations" document IANA-RFC [5]. 1257 16.1 Numbers used in the Protocol 1259 IPFIX Messages, as described in IPFIX-PROTO [4], use two fields with 1260 assigned values. These are the IPFIX Version Number, indicating 1261 which version of the IPFIX Protocol was used to export an IPFIX 1262 Message, and the IPFIX Template Number, indicating the type for each 1263 set of information within an IPFIX message. 1265 Changes in either IPFIX Version Number or IPFIX Template Number 1266 assignments require an IETF Consensus, i.e. they are to be made via 1267 RFCs approved by the IESG. 1269 16.2 Numbers used in the Information Model 1271 Fields of the IPFIX protocol carry information about traffic 1272 measurement. They are modeled as elements of the IPFIX information 1273 model IPFIX-INFO [3]. Each information element describes a field 1274 which may appear in an IPFIX Message. Within an IPFIX message the 1275 field type is indicated by its Field Type. 1277 Changes in IPFIX Field Type will be administered by IANA, subject to 1278 Expert Review, i.e. review by one of a group of experts designated 1279 by an IETF Operations and Management Area Director. Those experts 1280 will initially be drawn from the Working Group Chairs and document 1281 editors of the IPFIX and PSAMP Working Groups. 1283 17. Acknowledgements 1285 The document editors wish to thank all the people contributing to the 1286 discussion of this document on the mailing list, and the design teams 1287 for many valuable comments. In particular, the following made 1288 significant contributions: 1290 Tanja Zseby 1291 Paul Calato 1292 Dave Plonka 1293 Jeffrey Meyer 1294 Benoit Claise 1295 Ganesh Sadasivan 1296 K.C.Norseth 1297 Vamsi Valluri 1298 Cliff Wang 1299 Ram Gopal 1300 Jc Martin 1301 Carter Bullard 1302 Juergen Quittek 1303 Reinaldo Penno 1304 Nevil Brownlee 1305 Simon Leinen 1306 Kevin Zhang 1308 18 References 1310 [1] Quittek, J., Zseby, T. and B. Claise, "Requirements for IP Flow 1311 Information Export", (work in progress), Internet Draft, 1312 draft-ietf-ipfix-reqs-16.txt, June 2004. 1314 [2] Leinen, S., "Evaluation of Candidate Protocols for IP Flow 1315 Information Export", (work in progress), Internet Draft, 1316 draft-leinen-ipfix-eval-contrib-03.txt, May 2004. 1318 [3] Quittek, J., Meyer, J. and P. Calato, "IPFIX: Information 1319 Model", (work in progress), Internet Draft, 1320 draft-ietf-ipfix-info-03.txt, February 2004. 1322 [4] Fulmer, M., Claise, B., Calato, P. and R. Penno, "IPFIX: 1323 Protocol", (work in progress), Internet Draft, 1324 draft-ietf-ipfix-protocol-03.txt, January 2004. 1326 [5] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1327 Considerations Section in RFCs", RFC 2434, October 1998. 1329 Authors' Addresses 1331 Ganesh Sadasivan 1332 Cisco Systems, Inc. 1333 170 West Tasman Drive 1334 San Jose, CA 95134 1335 USA 1337 Phone: +1 408 527-0251 1338 EMail: gsadasiv@cisco.com 1340 Nevil Brownlee 1341 CAIDA | The University of Auckland 1342 Private Bag 92019 1343 Auckland 1344 New Zealand 1346 Phone: +64 9 373 7599 x8941 1347 EMail: n.brownlee@auckland.ac.nz 1349 Benoit Claise 1350 Cisco Systems, Inc. 1351 De Kleetlaan 6a b1 1352 1831 Diegem 1353 Belgium 1355 Phone: +32 2 704 5622 1356 EMail: bclaise@cisco.com 1357 Juergen Quittek 1358 NEC Europe Ltd. 1359 Adenauerplatz 6 1360 69225 Heidelberg 1361 Germany 1363 Phone: +49 6221 90511-15 1364 EMail: quittek@ccrle.nec.de 1365 URI: 1367 Intellectual Property Statement 1369 The IETF takes no position regarding the validity or scope of any 1370 Intellectual Property Rights or other rights that might be claimed to 1371 pertain to the implementation or use of the technology described in 1372 this document or the extent to which any license under such rights 1373 might or might not be available; nor does it represent that it has 1374 made any independent effort to identify any such rights. Information 1375 on the procedures with respect to rights in RFC documents can be 1376 found in BCP 78 and BCP 79. 1378 Copies of IPR disclosures made to the IETF Secretariat and any 1379 assurances of licenses to be made available, or the result of an 1380 attempt made to obtain a general license or permission for the use of 1381 such proprietary rights by implementers or users of this 1382 specification can be obtained from the IETF on-line IPR repository at 1383 http://www.ietf.org/ipr. 1385 The IETF invites any interested party to bring to its attention any 1386 copyrights, patents or patent applications, or other proprietary 1387 rights that may cover technology that may be required to implement 1388 this standard. Please address the information to the IETF at 1389 ietf-ipr@ietf.org. 1391 The IETF has been notified of intellectual property rights claimed in 1392 regard to some or all of the specification contained in this 1393 document. For more information consult the online list of claimed 1394 rights. 1396 Disclaimer of Validity 1398 This document and the information contained herein are provided on an 1399 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1400 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1401 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1402 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1403 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1404 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1406 Copyright Statement 1408 Copyright (C) The Internet Society (2004). This document is subject 1409 to the rights, licenses and restrictions contained in BCP 78, and 1410 except as set forth therein, the authors retain all their rights. 1412 Acknowledgment 1414 Funding for the RFC Editor function is currently provided by the 1415 Internet Society.