idnits 2.17.1 draft-ietf-ipfix-architecture-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 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 (June 2002) is 7984 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) == Unused Reference: '1' is defined on line 829, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group EDITORS: K.C. Norseth 3 Internet Draft Consultant 4 Expiration Date: December 2002 Ganesh Sadasivan 5 Cisco Systems, Inc. 6 June 2002 8 Architecture Model for IP Flow Information Export 10 draft-ietf-ipfix-architecture-02.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo defines the architecture, for the export of measured IP 35 flow information out of an IPFIX device to a collector, per the 36 requirements defined in [2]. 38 Conventions used in this document 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119. 44 Table of Contents 46 1 Introduction ........................................... 3 47 2 Scope .................................................. 3 48 3 Terminology ............................................ 3 49 4 IPFIX reference Model .................................. 7 50 4.1 IPFIX protocol ......................................... 10 51 4.2 Export Process ......................................... 10 52 4.3 Observation Domain ..................................... 11 53 4.4 Metering Process Functions ............................. 11 54 4.4.1 Flow Classification .................................... 11 55 4.4.2 Selection Criteria Of Packets .......................... 12 56 4.4.3 Function on properties that determines a flow type (Fi) . 12 57 4.4.4 Sampling packets on a flow type (Si) ................... 12 58 4.5 Selection Criteria of flows for export ................. 13 59 4.6 Collector .............................................. 13 60 4.7 Applications ........................................... 14 61 5 IPFIX Protocol ......................................... 14 62 5.1 Selection Criteria for IPFIX Protocol .................. 14 63 5.1.1 Common for IPFIX Device and Collector .................. 14 64 5.1.2 IPFIX Protocol on IPFIX Device (At Export Process) ..... 14 65 5.1.3 Intellectual Property Rights ........................... 15 66 5.1.4 IPFIX Protocol on Collector ............................ 15 67 5.2 Export Models .......................................... 15 68 5.2.1 Export Model with Reliable Control Connection .......... 15 69 5.3 Collector Crash Detection and Recovery ................. 16 70 5.3.1 Export Model with Reliable Control Connection .......... 16 71 5.4 Collector Redundancy ................................... 16 72 6 Security Consideration ................................. 17 73 6.1 Data security .......................................... 17 74 6.1.1 No security ............................................ 17 75 6.1.2 Authentication only .................................... 17 76 6.1.3 Encryption ............................................. 18 77 6.2 IPFIX end point authentication ......................... 18 78 6.3 Denial of service (DoS) attack prevention .............. 19 79 6.3.1 Network under attack ................................... 19 80 6.3.2 Generic DoS attack on the IPFIX system ................. 19 81 6.3.3 IPFIX Specific DoS attack .............................. 19 82 7 Flow Expiration ........................................ 19 83 8 IANA Consideration ..................................... 20 84 9 References ............................................. 20 85 10 Acknowledgements ....................................... 20 86 11 Author's Addresses ..................................... 21 87 12 Full Copyright Statement ............................... 22 89 1. Introduction 91 There are several applications e.g., Usage-based Accounting, Traffic 92 Profiling, Traffic engineering, Attack/Intrusion Detection, QoS 93 Monitoring, that require require flow-based IP traffic measurements. 94 It is hence important to have a standard way of exporting information 95 related to IP flows. This document defines architecture for IP 96 traffic flow monitoring, measuring and exporting. It provides a 97 high-level description of the key components and their functions. 99 2. Scope 101 This document defines architecture for IPFIX. The main objective of 102 this document is to: 104 * Describe the key architectural components of IPFIX. 105 * Define the architectural requirements, e.g., Recovery, Security, 106 etc for the IPFIX framework. 107 * Define the criteria to select the IPFIX Protocol. 108 * Specify the control/data message formats and handshaking details 109 to pass the IP flow information. 111 3. Terminology 113 * IP Traffic Flow or Flow: 114 A flow is defined as a set of IP packets passing an observation 115 point in the network during a certain time interval. All packets 116 belonging to a particular flow have a set of common properties 117 derived from the data contained in the packet and from the packet 118 treatment at the observation point. 120 In this draft we define the flow more specifically. A flow is 121 defined as a set of packets passing an observation point in the 122 network during a certain time interval. All packets belonging to 123 a particular flow have a set of common properties. Each property 124 is defined as the result of applying a function to the values of: 126 1. One or more of packet header fields (eg. destination IP 127 address) 128 2. One or more properties of the packet itself (eg. packet 129 length) 130 3. One or more of fields derived from packet treatment (eg. AS 131 number) 133 A packet is defined to belong to a flow if it matches all the 134 defined properties of the flow. Each of the fields from 1., 2. 136 and 3. mentioned above are referred to as flow keys. Though a 137 flow could match a general application-level end-to-end stream, 138 its definition is not restricted to this alone. The above 139 definition covers a broad range from a flow containing all 140 packets observed on a set of observation points to a flow 141 consisting of just a single packet between two applications with 142 a specific sequence number observed at a single observation 143 point. Some examples of flows are listed below: 145 Example 1: To create flows, we define the different fields to 146 distinguish flows. The different combination of the field values 147 creates unique flows. If the keys are defined as {source IP 148 address, destination IP address, TOS}, then all of these are 149 different flows. 151 1. {192.1.40.1, 171.6.23.5, 4} 152 2. {192.1.40.23, 171.6.23.67, 4} 153 3. {192.1.40.23, 171.6.23.67, 2} 154 4. {198.20.9.200, 171.6.23.67, 4} 156 Example 2: To create flows, we can apply a match function to all 157 the packets that pass through an observation point, in order to 158 aggregate some values. This could be done by defining the keys as 159 {source IP address, destination IP address, TOS} like in the 160 example 1, and applying the function which masks the least 161 significant 8 bits of the source IP address and destination IP 162 address (i.e. the resultant is a /24 address). The 4 flows from 163 example 1 would now be aggregated into 3 flows, by merging the 164 flows 1. and 2. into a single flow. 166 1. {192.1.40.0/24, 171.6.23.0/24, 4} 167 2. {192.1.40.0/24, 171.6.23.0/24, 2} 168 3. {198.20.9.0/24, 171.6.23.0/24, 4} 170 Example 3: To create flows, we can filter some field values on 171 all packets that pass the observation point, in order to select 172 only certain flows. The filter is defined by choosing fixed 173 values for specific fields from the packet. 175 All the packets that go from a customer network 192.1.40.0/24 to 176 another customer network 171.6.23.0/24 with TOS value of 4 define 177 a flow. All other combinations don't define a flow and are not 178 taken into account. The 3 flows from example 2 would now be 179 reduced to 1 flow, by filtering away the second and the third 180 flow. {192.1.40.0/24, 171.6.23.0/24, 4}. 182 The above example can be thought of as a function F takes as 183 input {source IP address, destination IP address, TOS}. The 184 function selects only the packets which satisfy all the 3 185 conditions which are: 187 * mask the least significant 8 bits of source IP address, 188 compare against 192.1.40.0. 189 * mask the least significant 8 bits of destination IP address, 190 compare against 171.6.23.0. 191 * tos value equal to 4. 193 Depending on the values of {source IP address, destination IP 194 address, TOS} of the different observed packets, the metering 195 process function F would choose/filter/aggregate different sets 196 of packets, which would create different flows. In other words, 197 based on various combination of values of {source IP address, 198 destination IP address, TOS}, F(source IP address, destination IP 199 address, TOS) would result in the definition of one or more 200 flows. The function F is referred to as Flow Type. 202 * Flow Key: 203 Each of the fields which belong to 204 1. Packet header (eg. destination IP address) 205 2. Property of the packet itself (eg. packet length) 206 3. Derived from packet treatment (eg. AS number) 207 which is used to define a flow is termed as flow key. 209 * Flow Type: 210 A function F which would take input as a set of flow keys and the 211 output would be one or more flows depending on the combination of 212 values for the set of flow keys. 214 * Flow Record: 215 A flow record contains information about a specific flow that was 216 metered at an observation point. A flow record contains measured 217 properties of the flow (e.g. the total number of bytes of all 218 packets of the flow) and usually characteristic properties of the 219 flow (e.g. source IP address). 221 * Export Process: 222 The process of sending flow records to one or more collectors. 224 * IPFIX Device: 225 A device hosting at least an observation point, a metering 226 process and a export process. Typically, corresponding 227 observation point(s), metering process(es), and exporter 228 process(es) are co-located at this device, for example, at a 229 router. 231 * Collector: 232 The collector receives flow records from one or more exporters. 233 The collector might process or store received flow record, but 234 these actions are out of the scope of this document. 236 * Observation Point: 237 The observation point is a location in the network where IP 238 packets can be observed. Examples are, a line to which a probe is 239 attached, a shared medium, such as an Ethernet-based LAN, a 240 single port of a router, or a set of interfaces (physical or 241 logical) of a router. 243 * Metering Process: 244 The metering process generates flow records. Input to the process 245 are IP packets observed in an observation point. The metering 246 process consists of a set of functions that includes packet 247 header capturing, timestamping, sampling, classifying, and 248 maintaining flow records. 250 * Observation Domain: 251 The set of observation points which is the largest aggregatable 252 set of flow information at the IPFIX Device is termed as an 253 observation domain. The observation domain presents itself a 254 unique ID to the collector for identifying the export packets 255 generated by it. One or more Observation Domains can interface 256 with the same export process. Example: The observation domain 257 could be a router line-card, composed of several interfaces with 258 each interface being an observation point. 260 * Template: 261 Template is an ordered n-tuple (eg. , TLV), used to 262 completely identify the structure and semantics of a particular 263 information that needs to be communicated from the IPFIX Device 264 to the collector. Each template is uniquely identifiable by some 265 means (eg. by using a Template ID). 267 * Control Information, Data Stream: 268 The information that needs to be exported from the IPFIX device 269 can be classified into the following categories: 271 - Control Information : 272 This includes the flow type definition, selection criteria 273 for packets within the flow send by the export process and 274 any IPFIX protocol messages (eg. Keepalives). This stream 275 carries all the information for the end-points to understand 276 the IPFIX protocol and specifically for the receiver to 277 understand and interpret the data send by the sender. 279 - Flow record : 280 This includes data records corresponding to the information 281 on various observed flows at each of the observation 282 point.This is also called as Data Stream. 284 The definitions in this section is intended be identical with that in 285 the IPFIX data model [3] and in the event of a discrepancy, the 286 definition specified in this document supercedes the one defined in 287 the latter. 289 4. IPFIX reference Model 291 The figure below shows the reference model for IPFIX. This figure 292 covers the various possible scenarios that can exist in an IPFIX 293 system. 295 +----------------+ +----------------+ 296 |[*Application 1]| ..|[*Application n]| 297 +--------+-------+ +-------+--------+ 298 ^ ^ 299 ~ ~ 300 +~~~~~~~~~~+~~~~~~~~+ 301 ! 302 v 303 +---------------------+ +------------------+ 304 |IPFIX Device(1) | | Collector(1) | 305 |[Export Process] |<--------------->| | 306 | | | | 307 +---------------------+ +------------------+ 308 .... .... 309 +----------------------+ +------------------+ 310 |IPFIX Device(i) | | Collector(j) | 311 |[Obsv Point(s)] |<-------------->| [*Application(s)]| 312 |[Metering Process(es)]| +---->| | 313 |[Export Process] | | +------------------+ 314 +----------------------+ . 315 .... . .... 316 +----------------------+ | +------------------+ 317 |IPFIX Device(m) | | | Collector(n) | 318 |[Obsv Point(s)] |<---------+---->| [*Application(s)]| 319 |[Metering Process(es)]| | | 320 |[Export Process] | +------------------+ 321 +----------------------+ 323 The various functional components are indicated within []. The 324 functional components within [*] are not part of the IPFIX framework. 326 The interfaces shown by "<-->" are defined by the the IPFIX framework 327 and those shown by "<~~>" are not. 329 The figure below shows a typical IPFIX device. 331 +---------------------------------------------------+ 332 | IPFIX Device | 333 | +---------------------------------------+ +-----+ | 334 | | Observation Domain 1 | | e | | 335 | | +------------------------+ (*) | | | | 336 | | | Selection Criteria for +----+---------> x | | 337 | | | Flow export | | | | | | 338 | | +------------------------+ | | | p | | 339 | | ^ ^ | | | | | 340 | | |(*) | (*) | | | o | | 341 | | | | | | | | | 342 | | +---......--+------------+ | | r | | 343 | | | | | | | | 344 | | +----+----+ +----+----+ | | t | | 345 | | |Metering | |Metering | | | | | 346 | | |Process 1| |Process N| | | | | 347 | | |(Packet | |(Packet | | | | | 348 | | | Level) | | Level) | | | | | 349 | | +---------+ +---------+ | | | | 350 | | ^ ^ | | | | 351 | | | | | | | | 352 | | +-----+------+ +-----+------+| | | | 353 | | |Obsv Point 1| ... |Obsv Point M|| | | | 354 | | +------------+ +------------+| | | | 355 | +---------------------------------------+ | | |export 356 | .... | ------> 357 | +---------------------------------------+ | P | |towards 358 | | Observation Domain K | | | |the 359 | | +------------------------+ (*) | | r | |collector(s) 360 | | | Selection Criteria for +----+---------> | | 361 | | | Flow export | | | | o | | 362 | | +------------------------+ | | | | | 363 | | ^ ^ | | | c | | 364 | | |(*) | (*) | | | | | 365 | | | | | | | e | | 366 | | +---......--+------------+ | | | | 367 | | | | | | s | | 368 | | +----+----+ +----+----+ | | | | 369 | | |Metering | |Metering | | | s | | 370 | | |Process 1| |Process N| | | | | 371 | | +---------+ +---------+ | | | | 372 | | ^ ^ | | | | 373 | | | | | | | | 374 | | +-----+------+ +-----+------+| | | | 375 | | |Obsv Point 1| ... |Obsv Point M|| | | | 376 | | +------------+ +------------+| | | | 377 | +---------------------------------------+ +-----+ | 378 +---------------------------------------------------+ 379 In this figure the functional blocks are shown in rectangular boxes. 380 The interface shown by (*) is applicable only if the optional 381 metering process at the flow level is present. Otherwise the metering 382 process(es) at the packet level interfaces directly with the 383 exporting function. Note that in case of multiple observation 384 domains, a unique ID per observation domain must be transmitted as a 385 parameters to the exporting function. 387 4.1. IPFIX protocol 389 At the IPFIX device, the protocol functionality may be split between 390 observation domain and export process. 392 At a high level, IPFIX protocol at the IPFIX device does the 393 following: 395 1. Encode the control information into templates. 396 2. Encode the flows observed at the observation points into flow 397 records. 398 3. Packetize the flow record and/or control information into export 399 packets based on the export policies. 400 4. Use the underlying transport layer to send the export packets to 401 the collector. 403 At a high level, IPFIX protocol at the collector is responsible for 404 the following: 406 1. Receive and store the control information. 407 2. Decode and store the flow records using the control information. 409 4.2. Export Process 411 The Export Process is the functional block that interacts with 412 observation domain(s) on one side and collector(s) on the other side. 413 The typical functions of an export process may include: 415 * Accept control information and data streams from one or more 416 observation domains and separate them into separate export packet 417 streams based on observation domain. 418 * Run the part of the IPFIX protocol which deals with packetization 419 and transport of flow records/control information with the 420 collector. This involves: 422 - Gather flow records from the metering process(es) and export 423 them towards the collector(s), using the data stream. 425 - Export the control information regarding the flow and 426 metering process(es) towards the collector(s). 428 * Optionally monitor the status of the collector and execute a fail 429 over in case of problem. 431 4.3. Observation Domain 433 The Observation Domain is the functional block, which MUST manage the 434 flows generated from all the valid {Observation Point, Metering 435 Process} combination defined within itself. The typical functions of 436 an Observation Domain MAY include: 438 * Encoding the flow records and sending them to the export process. 439 * Encoding the control information into templates and sending them to 440 the export process. 441 * Deciding which flow records/control information to export using 442 rules based on time, thresholds, configuration events etc. 443 * Aggregating flow records generated by one or more metering 444 processes. 445 * Flow record maintenance which may include creating new records, 446 updating existing ones, computing flow statistics, deriving 447 further flow properties, adding non-flow specific information (in 448 some cases fields like AS numbers) detecting flow expiration, 449 passing flows record to the exporting process, and deleting flow 450 records. 451 * Perform appropriate middle-box functions to translate the flow 452 information. 454 4.4. Metering Process Functions 456 4.4.1. Flow Classification 458 The collector MUST be able to map the flow record to the 459 corresponding property types defined by the flow type. In addition 460 the collector, when it receives the flow records, MAY need the 461 following to interpret the flow records further: 463 a. Observation Point. 464 b. Selection Criteria of Packets 466 A flow record can be better analyzed if the Observation Point from 467 which it is measured is known. As such it is recommended that the 468 flow record carry the Observation Point information along with the 469 flow records when exported. In cases where there is a single 470 observation point or where the observation point information is not 471 relevant, the exporter MAY choose not to add this to the flow 472 records. 474 4.4.2. Selection Criteria Of Packets 476 The measurement device MAY define rules so that only certain packets 477 within a flow can be chosen for measurement at an observation point. 478 This MAY be done by one of the two types of methods defined below or 479 a combination of them. A combination of each of these ways can be 480 adopted to select the packets .i.e. one can define a set of methods 481 {F1, S1, F2, S2, S3} executed in certain sequence at an observation 482 point to collect flows of a particular type. 484 4.4.3. Function on properties that determines a flow type (Fi) 486 Packets that satisfy a function on the fields defined by the packet 487 header fields or fields obtained while doing the packet processing or 488 the properties of the packet itself. 490 Example: Mask/Match of the fields that define a filter. The filter 491 may be defined as {Protocol == TCP, Destination Port between 80 and 492 120}. 494 Multiple such filters could be used in any sequence to select 495 packets. 497 4.4.4. Sampling packets on a flow type (Si) 499 Packets that satisfy the sampling criteria for this flow type. 501 Example: Sample every 100th packet that was received at an 502 observation point and collect the flow information for a particular 503 flow type. choosing all the packets is a special case where sampling 504 rate is 1:1. 506 The figure below shows the operations which MAY be applied as part of 507 a typical metering process. 509 packet header capturing 510 | 511 timestamping 512 | 513 v 514 +----->+ 515 | | 516 | sampling Si (1:1 in case of no sampling) 517 | | 518 | classifying Fi (NULL when No criteria) 519 | | 520 +------+ 521 | 522 | 523 v 524 Flows 526 4.5. Selection Criteria of flows for export 528 There MAY be additional rules defined within the observation domain 529 so that only certain flows records are picked up for export. This MAY 530 be done by either one or a combination of Si, Fi. 532 Example: The flow records which meet the following selection 533 criteria are only exported. 535 1. All flow records whose destination IP address matches 536 {20.3.1.5}. 537 2. Every other (.i.e. sampling rate 1 in 2) flow record whose 538 destination IP address matches {160.0.1.30}. 540 4.6. Collector 542 Collector is a subsystem that interacts with one or more IPFIX 543 devices. The functions of the collector MAY include: 545 * Identifying, accepting and decoding export packets from different 546 {Export Process, Observation Domain} pairs . 547 * Running the IPFIX protocol. 548 * Storing the control information and flow records received from 549 IPFIX device. 550 * Notifying the IPFIX device its status and problems. 552 4.7. Applications 554 Applications that use the information collected by IPFIX may be 555 Billing, Intrusion Detection sub-systems, etc. These applications may 556 be an integral part of the collector or collocated to the collector. 557 The way by which these applications interface with IPFIX system to 558 get the desired information is out of this document's scope. 560 5. IPFIX Protocol 562 5.1. Selection Criteria for IPFIX Protocol 564 There are existing standard practices in the area of flow export like 565 Netflow, CRANE, LFAP etc. The charter mentions to choose the the 566 protocol among these existing practices that fits the IPFIX 567 requirements the most. There may be additions or modifications made 568 to the chosen protocol to fit it exactly into the IPFIX architecture. 569 The following is the list of criteria that the candidate protocol 570 SHOULD meet in order to be the qualified into the IPFIX architecture. 571 This is based on the requirements specified in the requirement 572 document [2]. 574 5.1.1. Common for IPFIX Device and Collector 576 1. Transparency over transport protocol. Ability to operate over a 577 congestion aware transport like TCP or SCTP is a MUST. 578 2. Transparency over any underlying security protocols. 579 3. The protocol SHOULD be based on a flexible data model based on 580 templates. 581 4. The protocol SHOULD be based on a extensible information model. 583 5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) 585 1. Ability to detect loss of connectivity with the collector and 586 trigger the appropriate action (eg. a switch over to an 587 alternate collector.) 588 2. Optionally export flow records to multiple collectors. 589 3. Optionally re-transmit lost flow records. 590 4. Exchange control information from the collector, monitor export 591 process and detect any overload in the process of exporting. 593 5.1.3. Intellectual Property Rights 595 The protocol must abide by the intellectual property rights as 596 defined in rfc: 2026. Specifically section: 10.3.1. All 597 Contributions. If the protocol does not abide by this, it will not 598 be considered. 600 5.1.4. IPFIX Protocol on Collector 602 1. Receive and decode the flow records from the IPFIX devices. 603 2. Ability to indicate flow record losses to the exporting IPFIX 604 device and/or IPFIX users. 605 3. Optionally notify the status and overload conditions to the 606 IPFIX device. 607 Once the selection is made from the set of candidate protocols, this 608 section would be replaced by the chosen protocol. 610 5.2. Export Models 612 5.2.1. Export Model with Reliable Control Connection 614 As mentioned in the selection criteria, the control information and 615 data stream MUST be transported over a congestion-aware transport 616 protocol. If the network in which the IPFIX device and collector are 617 located does not guarantee reliability, at least the control 618 information SHOULD be exported over a reliable transport. There could 619 be network security concerns between IPFIX device and collector. To 620 avoid re-inventing the wheel, and to reduce the complexity of flow 621 export protocol, one or a combination of the following methods MAY be 622 adopted as a solution to achieve security : 624 * IP Authentication Header MAY be used when the threat environment 625 requires stronger integrity protections, but does not require 626 confidentiality. 627 * IP Encapsulating Security Payload (ESP) MAY be used to provide 628 confidentiality and integrity. 629 * If the transport protocol used is TCP, optionally TCP MD5 630 signature option MAY be used to protect against spoofed TCP 631 segments. 632 * If the transport protocol used is TCP, optionally TLS MAY be used 633 to add integrity, authenticity and confidentiality. 635 The data stream MAY be exported over an reliable or unreliable 636 transport protocol. 638 As explained above the transport connection (in the case of a 639 connection oriented protocol) is pre-setup between the IPFIX device 640 and the collector. Once connected, the collector side receives the 641 control information and uses this information to interpret the flow 642 records. The IPFIX device SHOULD set the keepalive (eg. keepalive 643 timeout in the case of TCP; the HEARTBEAT interval in the case of 644 SCTP; IPFIX protocol level Keepalive if any) to a sufficiently low 645 value so that it can quickly detect a collector crash. 647 5.3. Collector Crash Detection and Recovery 649 5.3.1. Export Model with Reliable Control Connection 651 The collector crash is detected at the IPFIX device by the break in 652 control connection (depending on the transport protocol the 653 connection timeout mechanisms differ). On detecting a Keepalive 654 timeout, the IPFIX device SHOULD stop sending the flow export data to 655 the collector and try reconnecting the transport connection. This is 656 valid for a single collector scenario. If there are multiple 657 collectors for the same IPFIX device, the IPFIX device opens control 658 connections to each of the collectors. But data gets sent only to 659 one of the collectors which is chosen as the primary. There could be 660 one or more collectors configured as secondary and a priority 661 assigned to them. The primary collector crash is detected at the 662 IPFIX device by the break in control connection (depending on the 663 transport protocol the connection timeout mechanisms differ). On 664 detecting loss of connectivity, the IPFIX device opens data stream 665 with the secondary collector of the next highest priority. This 666 collector now becomes the primary. The maximum export data loss would 667 be the amount of data exported in the time between when the loss of 668 connectivity to the collector happened, and the time at which this 669 was detected by the IPFIX device. 671 5.4. Collector Redundancy 673 Since IPFIX protocol requires a congestion-aware transport, achieving 674 redundancy using multicast is not an option. Multiple pairs could be setup, each to a different 676 collector from the same IPFIX device. The control and data 677 information are then replicated on each of the control information 678 and data stream. 680 6. Security Consideration 682 IP flow information can be used for various purposes, such as usage 683 accounting, traffic profiling, traffic engineering, and intrusion 684 detection. For each application, the security requirement may differ 685 significantly from one to another. To be able to satisfy the security 686 needs of various IPFIX users, the architecture of IPFIX MUST provide 687 different levels of security protection. 689 6.1. Data security 691 IPFIX data consists of control information and data stream generated 692 by the IPFIX device. 694 The IPFIX data may exist in both the IPFIX device and the collector. 695 In addition, the data is also transferred on the wire from the 696 exporter to the collector when it is reported. To provide security, 697 the data SHOULD be protected from adversity. 699 The protection of IPFIX data within the end system (IPFIX device and 700 collector) is out of the scope. It is assumed that the end system 701 operator will provide adequate security for the IPFIX data. 703 The IPFIX architecture MUST allow different levels of protection to 704 the IPFIX data on the wire. Where ever security functions are 705 required it is recommended to leverage to lower layers using either 706 IPsec or TLS, if they can successfully satisfy the security 707 requirement of IPFIX data protection. 709 To protect the data on the wire, three levels of granularity SHOULD 710 be supported: 712 6.1.1. No security 714 No security is required when the transport between the IPFIX device 715 and the collector is perceived as safe. This option allows the 716 protocol to run most efficiently without extra overhead and an IPFIX 717 solution MUST support it. 719 6.1.2. Authentication only 721 The authentication only protection provides the IPFIX users the 722 assurance of data integrity and authenticity. The data exchanged 723 between the IPFIX device and the collector is protected by 724 authentication signature. Any modification of the IPFIX data will be 725 detected by the recipient, resulting in discarding of the received 726 data. However, the authentication only option doesn't offer data 727 confidentiality. The IPFIX user SHOULD avoid use this option when 728 sensitive or confidential information is being exchanged. An IPFIX 729 solution SHOULD support this option. The authentication only option 730 SHOULD provide replay attack protection. Some means to achieve this 731 level of security are: 732 * TCP with MD5 options. 733 * IP Authentication Header 735 6.1.3. Encryption 737 Data encryption provides the best protection for IPFIX data. The 738 IPFIX data is encrypted at the sender and only the intended recipient 739 can decrypt and have access to the data. This option MUST be used 740 when the transport between the exporter and the collector are unsafe 741 and the IPFIX data needs to be protected. It is recommended to use 742 the underlying security layer functions for this purpose. Some means 743 to achieve this level of security are: 745 * Encapsulating Security Payload. 746 * Transport Layer Security Protocol 748 The data encryption option adds overhead to the IPFIX data transfer. 749 It may limit the rate that an export can report its flow to the 750 collector due to the heavy resource requirement of running 751 encryption. 753 6.2. IPFIX end point authentication 755 It is important to make sure that the IPFIX device is talking to the 756 "right" collector instead of a masqueraded collector. The same logic 757 also holds true from the collector point of view that it want to make 758 sure it is collecting the flow information from the "right" IPFIX 759 device. The IPFIX architecture SHOULD allow the authentication 760 capability so that either one-way or mutual authentication can be 761 performed between the IPFIX device and collector. 763 The IPFIX architecture SHOULD use the existing transport protection 764 protocols such as TLS to fulfill the authentication requirement. 766 6.3. Denial of service (DoS) attack prevention 768 Since one of the potential usages for IPFIX is for intrusion 769 detection, it is important for the IPFIX architecture to support some 770 kind of DoS resistance. 772 6.3.1. Network under attack 774 The Network itself may be under attack, resulting in an overwhelming 775 number of IPFIX messages. The IPFIX SHOULD try to capture as much 776 information as possible. However, when large amount IPFIX messages 777 are generated in a short period of time, the IPFIX may become 778 overloaded. 780 6.3.2. Generic DoS attack on the IPFIX system 782 The IPFIX system may subject to generic DoS attacks, just as any 783 system on any open networks. These types of attacks are not IPFIX 784 specific. Preventing and responding to such types of attacks are out 785 of the scope of IPFIX WG. 787 6.3.3. IPFIX Specific DoS attack 789 There is a specific attack on the IPFIX portion of the IPFIX device 790 or Collector. 792 (To be added and discussed on the general list). 794 7. Flow Expiration 796 A flow is considered to be inactive if no packets of this flow has 797 been observed at the observation point for a given timeout interval. 798 The flow can be exported under the following conditions: 800 1. If the exporter can deduce the end of a flow, the exporter 801 SHOULD export the flow records when the end of the flow is 802 detected. For example: flow generated by TCP type of traffic 803 where the FIN or RST bits indicate the end of the flow 805 2. If the flow has been inactive for a certain period of time. 806 This inactivity timeout SHOULD be configurable. For example: 807 flow generated by UDP type of traffic. 809 3. For long aging flows, the exporter SHOULD export the flow 810 records on regular basis, in order to: 812 a. Report the flow records periodic accounting information to 813 the collector 814 b. Avoid counter wrapping This activity timeout SHOULD be 815 configurable 816 c. Prevent an attacker from indefinitely delaying the delivery 817 of flow information to an IDS application by intentionally 818 generating packets which fall within long aging flows. 820 4. If the exporter experiences resources constraints, a flow MAY be 821 prematurely expired (example: memory) 823 8. IANA Consideration 825 Need Port number assigned from IANA [more to be written] 827 9. References 829 [1] IP Flow Information Export (IPFIX) 830 832 [2] J. Quittek ,T. Zseby, B. Claise,"Requirements for IP Flow 833 Information Export", (work in progress) ,Internet Draft, Internet 834 Engineering Task Force, , August 2002 836 [3] K.C. Norseth, Paul Calato,"Data Model for IP Flow Information 837 Export", (work in progress) ,Internet Draft, Internet Engineering 838 Task Force, , August 2002 840 10. Acknowledgements 842 We like to thank all the people contributing to the requirements 843 discussion on the mailing list, and the design teams for many 844 valuable comments. 846 George Carle 847 Tanja Zseby 848 Paul Calato 849 Dave Plonka 850 KC Norseth 851 Benoit Claise 852 Ganesh Sadasivan 853 Vamsi Valluri 854 Cliff Wang 855 Ram Gopal 856 Jc Martin 857 Carter Bullard 858 Juergen Quittek 859 Reinaldo Penno 860 Nevil Brownlee 861 Simon Leinen 863 11. Author's Addresses 865 Benoit Claise 866 Cisco Systems 867 De Kleetlaan 6a b1 868 1831 Diegem 869 Belgium 870 Phone: +32 2 704 5622 871 Email: bclaise@cisco.com 873 Ganesh Sadasivan 874 Cisco Systems, Inc. 875 170 W. Tasman Dr. 876 San Jose, CA 95134 877 USA 878 Phone: +1 (408) 527-0251 879 Email: gsadasiv@cisco.com 881 K.C. Norseth 882 Consultant 883 934 S. Palos Verdes Dr. 884 Kaysville, Utah 84037 885 Phone: +1 (801) 546-3316 886 Email: kcn@norseth.com 888 Juergen Quittek 889 NEC Europe Ltd. 890 Adenauerplatz 6 891 69115 Heidelberg 892 Germany 893 Phone: +49 6221 90511-15 894 EMail: quittek@ccrle.nec.de 895 Kevin Zhang 896 XACCT Technologies, Inc. 897 2900 Lakeside Drive 898 Santa Clara, CA 95054 899 Phone +1 301 992 4697 900 Email: kevin.zhang@xacct.com 902 12. Full Copyright Statement 904 "Copyright (C) The Internet Society (date). All Rights Reserved. This 905 document and translations of it may be copied and furnished to 906 others, and derivative works that comment on or otherwise explain it 907 or assist in its implementation may be prepared, copied, published 908 and distributed, in whole or in part, without restriction of any 909 kind, provided that the above copyright notice and this paragraph are 910 included on all such copies and derivative works. However, this 911 document itself may not be modified in any way, such as by removing 912 the copyright notice or references to the Internet Society or other 913 Internet organizations, except as needed for the purpose of 914 developing Internet standards in which case the procedures for 915 copyrights defined in the Internet Standards process must be 916 followed, or as required to translate it into.