idnits 2.17.1 draft-ietf-ipfix-architecture-01.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 (April 2002) is 8039 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 825, 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: October 2002 Ganesh Sadasivan 5 Cisco Systems, Inc. 6 April 2002 8 Architecture Model for IP Flow Information Export 10 draft-ietf-ipfix-architecture-01.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 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: 125 Each property is defined as the result of applying a function to 126 the values of: 128 1. One or more of packet header fields (eg. destination IP 129 address) 130 2. One or more properties of the packet itself (eg. packet 131 length) 133 3. One or more of fields derived from packet treatment (eg. AS 134 number) 136 A packet is defined to belong to a flow if it matches all the 137 defined properties of the flow. Each of the fields from 1., 2. 138 and 3. are referred to as flow keys. Though a flow could match a 139 general application-level end-to-end stream, its definition is 140 not restricted to this alone. The above definition covers a broad 141 range from a flow containing all packets observed on a set of 142 observation points to a flow consisting of just a single packet 143 between two applications with a specific sequence number observed 144 at a single observation point. Some examples of flows are listed 145 below: 147 Example 1: To create flows, we define the different fields to 148 distinguish flows. The different combination of the field values 149 creates unique flows. If the keys are defined as {source IP 150 address, destination IP address, TOS}, then all of these are 151 different flows. 153 1. {192.1.40.1, 171.6.23.5, 4} 154 2. {192.1.40.23, 171.6.23.67, 4} 155 3. {192.1.40.23, 171.6.23.67, 2} 156 4. {198.20.9.200, 171.6.23.67, 4} 158 Example 2: To create flows, we can apply a match function to all 159 the packets that pass through an observation point, in order to 160 aggregate some values. This could be done by defining the keys as 161 {source IP address, destination IP address, TOS} like in the 162 example 1, and applying the function which masks the least 163 significant 8 bits of the source IP address and destination IP 164 address (i.e. the resultant is a /24 address). The 4 flows from 165 example 1 would now be aggregated into 3 flows, by merging the 166 flows 1. and 2. into a single flow. 168 1. {192.1.40.0/24, 171.6.23.0/24, 4} 169 2. {192.1.40.0/24, 171.6.23.0/24, 2} 170 3. {198.20.9.0/24, 171.6.23.0/24, 4} 172 Example 3: To create flows, we can filter some field values on 173 all packets that pass the observation point, in order to select 174 only certain flows. The filter is defined by choosing fixed 175 values for specific fields from the packet. 177 All the packets that go from a customer network 192.1.40.0/24 to 178 another customer network 171.6.23.0/24 with TOS value of 4 define 179 a flow. All other combinations don't define a flow and are not 180 taken into account. The 3 flows from example 2 would now be 181 reduced to 1 flow, by filtering away the second and the third 182 flow. {192.1.40.0/24, 171.6.23.0/24, 4}. 184 The above example can be thought of as a function F takes as 185 input {source IP address, destination IP address, TOS}. The 186 function selects only the packets which satisfy all the 3 187 conditions which are: 189 * mask the least significant 8 bits of source IP address, 190 compare against 192.1.40.0. 191 * mask the least significant 8 bits of destination IP address, 192 compare against 171.6.23.0. 193 * tos value equal to 4. 195 Depending on the values of {source IP address, destination IP 196 address, TOS} of the different observed packets, the metering 197 process function F would choose/filter/aggregate different sets 198 of packets, which would create different flows. In other words, 199 based on various combination of values of {source IP address, 200 destination IP address, TOS}, F(source IP address, destination IP 201 address, TOS) would result in the definition of one or more 202 flows. The function F is referred to as Flow Type. 204 * Flow Key: 205 Each of the field which belongs to 206 1. Packet header (eg. destination IP address) 207 2. Property of the packet itself (eg. packet length) 208 3. Derived from packet treatment (eg. AS number) 209 which is used to define a flow is termed as flow key. 211 * Flow Type: 212 A function F which would take input as a set of flow keys and the 213 output would be one or more flows depending on the combination of 214 values for the set of flow keys. 216 * Flow Record: 217 A flow record contains information about a specific flow that was 218 metered at an observation point. A flow record contains measured 219 properties of the flow (e.g. the total number of bytes of all 220 packets of the flow) and usually characteristic properties of the 221 flow (e.g. source IP address). 223 * Export Process: 224 The process of sending flow records to one or more collectors. 226 * IPFIX Device: 227 A device hosting at least an observation point, a metering 228 process and a export process. Typically, corresponding 229 observation point(s), metering process(es), and exporter 230 process(es) are co-located at this device, for example, at a 231 router. 233 * Collector: 234 The collector receives flow records from one or more exporters. 235 The collector might process or store received flow record, but 236 these actions are out of the scope of this document. 238 * Observation Point: 239 The observation point is a location in the network where IP 240 packets can be observed. Examples are, a line to which a probe is 241 attached, a shared medium, such as an Ethernet-based LAN, a 242 single port of a router, or a set of interfaces (physical or 243 logical) of a router. 245 * Metering Process: 246 The metering process generates flow records. Input to the process 247 are IP packets observed in an observation point. The metering 248 process consists of a set of functions that includes packet 249 header capturing, timestamping, sampling, classifying, and 250 maintaining flow records. 252 * Observation Domain: 253 The set of observation points which is the largest aggregatable 254 set of flow information at the IPFIX Device is termed as an 255 observation domain. The observation domain presents itself a 256 unique ID to the collector for identifying the export packets 257 generated by it. One or more Observation Domains can interface 258 with the same export process. Example: The observation domain 259 could be a router line-card, composed of several interfaces with 260 each interface being an observation point. 262 * Template: 263 Templates is a set of ordered pairs (eg. , TLV), 264 used to completely identify the structure and semantics of a 265 particular information that needs to be communicated from the 266 IPFIX Device to the collector. Each template is uniquely 267 identifiable by some means (eg. by using a Template ID). 269 * Control Stream, Data Stream: 270 The information that needs to be exported from the IPFIX device 271 can be classified into the following categories: 273 - Control Information : 274 This includes the flow type definition, selection criteria 275 for packets within the flow. This is also called as Control 276 Stream. This stream carries all the information for the 277 end-points to understand the IPFIX protocol and specifically 278 for the receiver to understand and interpret the data stream 279 send by the sender. 281 - Flow record : 282 This includes data records corresponding to the information 283 on various observed flows at each of the observation 284 point.This is also called as Data Stream. 286 The definitions in this section is intended be identical with that in 287 the IPFIX data model [3] and in the event of a discrepancy, the 288 definition specified in this document supercedes the one defined in 289 the latter. 291 4. IPFIX reference Model 293 The figure below shows the reference model for IPFIX. This figure 294 covers the various possible scenarios that can exist in an IPFIX 295 system. 297 +----------------+ +----------------+ 298 |[*Application 1]| ..|[*Application n]| 299 +--------+-------+ +-------+--------+ 300 ^ ^ 301 ~ ~ 302 +~~~~~~~~~~+~~~~~~~~+ 303 ! 304 v 305 +---------------------+ +------------------+ 306 |IPFIX Device(1) | | Collector(1) | 307 |[Export Process] |<--------------->| | 308 | | | | 309 +---------------------+ +------------------+ 310 .... .... 311 +----------------------+ +------------------+ 312 |IPFIX Device(i) | | Collector(j) | 313 |[Obsv Point(s)] |<-------------->| [*Application(s)]| 314 |[Metering Process(es)]| +---->| | 315 |[Export Process] | | +------------------+ 316 +----------------------+ . 317 .... . .... 318 +----------------------+ | +------------------+ 319 |IPFIX Device(m) | | | Collector(n) | 320 |[Obsv Point(s)] |<---------+---->| [*Application(s)]| 321 |[Metering Process(es)]| | | 322 |[Export Process] | +------------------+ 323 +----------------------+ 325 The various functional components are indicated within []. The 326 functional components within [*] are not part of the IPFIX framework. 327 The interfaces shown by "<-->" are defined by the the IPFIX framework 328 and those shown by "<~~>" are not. 330 The figure below shows a typical IPFIX device. 332 +---------------------------------------------------+ 333 | IPFIX Device | 334 | +---------------------------------------+ +-----+ | 335 | | Observation Domain 1 | | e | | 336 | | +------------------------+ (*) | | | | 337 | | | Selection Criteria for +----+---------> x | | 338 | | | Flow export | | | | | | 339 | | +------------------------+ | | | p | | 340 | | ^ ^ | | | | | 341 | | |(*) | (*) | | | o | | 342 | | | | | | | | | 343 | | +---......--+------------+ | | r | | 344 | | | | | | | | 345 | | +----+----+ +----+----+ | | t | | 346 | | |Metering | |Metering | | | | | 347 | | |Process 1| |Process N| | | | | 348 | | |(Packet | |(Packet | | | | | 349 | | | Level) | | Level) | | | | | 350 | | +---------+ +---------+ | | | | 351 | | ^ ^ | | | | 352 | | | | | | | | 353 | | +-----+------+ +-----+------+| | | | 354 | | |Obsv Point 1| ... |Obsv Point M|| | | | 355 | | +------------+ +------------+| | | | 356 | +---------------------------------------+ | | |export 357 | .... | ------> 358 | +---------------------------------------+ | P | |towards 359 | | Observation Domain K | | | |the 360 | | +------------------------+ (*) | | r | |collector(s) 361 | | | Selection Criteria for +----+---------> | | 362 | | | Flow export | | | | o | | 363 | | +------------------------+ | | | | | 364 | | ^ ^ | | | c | | 365 | | |(*) | (*) | | | | | 366 | | | | | | | e | | 367 | | +---......--+------------+ | | | | 368 | | | | | | s | | 369 | | +----+----+ +----+----+ | | | | 370 | | |Metering | |Metering | | | s | | 371 | | |Process 1| |Process N| | | | | 372 | | +---------+ +---------+ | | | | 373 | | ^ ^ | | | | 374 | | | | | | | | 375 | | +-----+------+ +-----+------+| | | | 376 | | |Obsv Point 1| ... |Obsv Point M|| | | | 377 | | +------------+ +------------+| | | | 378 | +---------------------------------------+ +-----+ | 379 +---------------------------------------------------+ 380 In this figure the functional blocks are shown in rectangular boxes. 381 The interface shown by (*) is applicable only if the optional 382 metering process at the flow level is present. Otherwise the metering 383 process(es) at the packet level interfaces directly with the 384 exporting function. Note that in case of multiple observation 385 domains, a unique ID per observation domain must be transmitted as a 386 parameters to the exporting function. 388 4.1. IPFIX protocol 390 At the IPFIX device, the protocol functionality may be split between 391 observation domain and export process. 393 At a high level, IPFIX protocol at the IPFIX device does the 394 following: 396 1. Encode the control information into templates. 397 2. Encode the flows observed at the observation points into flow 398 records. 399 3. Packetize the flow record and/or control information into export 400 packets based on the export policies. 401 4. Use the underlying transport layer to send the export packets to 402 the collector. 404 At a high level, IPFIX protocol at the collector is responsible for 405 the following: 407 1. Receive and store the control information. 408 2. Decode and store the flow records using the control information. 410 4.2. Export Process 412 The Export Process is the functional block that interacts with 413 observation domain(s) on one side and collector(s) on the other side. 414 The typical functions of an export process may include: 416 * Accept control/data streams from one or more observation domains 417 and separate them into separate export packet streams based on 418 observation domain. 419 * Run the part of the IPFIX protocol which deals with packetization 420 and transport of flow records/control information with the 421 collector. This involves: 423 - Gather flow records from the metering process(es) and export 424 them towards the collector(s), using the data stream. 426 - Export the control information regarding the flow and 427 metering process(es) towards the collector(s), using the 428 control stream. 430 * Optionally monitor the status of the collector and execute a fail 431 over in case of problem. 433 4.3. Observation Domain 435 The Observation Domain is the functional block, which MUST manage the 436 flows generated from all the valid {Observation Point, Metering 437 Process} combination defined within itself. The typical functions of 438 an Observation Domain may include: 440 * Encode the flow records and send them to the export process. 441 * Encode the control information into templates and send them to 442 the export process. 443 * Decide which flow records/control information to export using 444 rules based on time, thresholds, configuration events etc. 445 * Aggregate flow records generated by one or more metering 446 processes. 447 * Flow record maintenance which may include creating new records, 448 updating existing ones, computing flow statistics, deriving 449 further flow properties, adding non-flow specific information (in 450 some cases fields like AS numbers) detecting flow expiration, 451 passing flows record to the exporting process, and deleting flow 452 records. 453 * May perform appropriate middle-box functions to translate the 454 flow information. 456 4.4. Metering Process Functions 458 4.4.1. Flow Classification 460 The collector MUST be able to map the flow record to the 461 corresponding property types defined by the flow type. In addition 462 the collector, when it receives the flow records, MAY need the 463 following interpreting the flow records further: 465 a. Observation Point. 466 b. Selection Criteria of Packets 468 A flow record can be better analyzed if the Observation Point from 469 which it is measured is known. As such it is recommended that the 470 flow record carry the Observation Point information along with the 471 flow records when exported. In cases where there is a single 472 observation point or where the observation point information is not 473 relevant, the exporter MAY choose not to add this to the flow 474 records. 476 4.4.2. Selection Criteria Of Packets 478 The measurement device MAY define rules so that only certain packets 479 within a flow can be chosen for measurement at an observation point. 480 This MAY be done by one of the two types of methods defined below or 481 a combination of them. A combination of each of these ways can be 482 adopted to select the packets .i.e. one can define a set of methods 483 {F1, S1, F2, S2, S3} executed in certain sequence at an observation 484 point to collect flows of a particular type. 486 4.4.3. Function on properties that determines a flow type (Fi) 488 Packets that satisfy a function on the fields defined by the packet 489 header fields or fields obtained while doing the packet processing or 490 the properties of the packet itself. 492 Example: Mask/Match of the fields that define a filter. The filter 493 may be defined as {Protocol == TCP, Destination Port between 80 and 494 120}. 496 Multiple such filters could be used in any sequence to select 497 packets. 499 4.4.4. Sampling packets on a flow type (Si) 501 Packets that satisfy the sampling criteria for this flow type. 503 Example: Sample every 100th packet that was received at an 504 observation point and collect the flow information for a particular 505 flow type. choosing all the packets is a special case where sampling 506 rate is 1:1. 508 The figure below shows the operations which MAY be applied as part of 509 a typical metering process. 511 packet header capturing 512 | 513 timestamping 514 | 515 v 516 +----->+ 517 | | 518 | sampling Si (1:1 in case of no sampling) 519 | | 520 | classifying Fi (NULL when No criteria) 521 | | 522 +------+ 523 | 524 | 525 v 526 Flows 528 4.5. Selection Criteria of flows for export 530 There MAY be additional rules defined within the observation domain 531 so that only certain flows records are picked up for export. This MAY 532 be done by either one or a combination of Si, Fi. 534 Example: The flow records which meet the following selection 535 criteria are only exported. 537 1. All flow records whose destination IP address matches 538 {20.3.1.5}. 539 2. Every other (.i.e. sampling rate 1 in 2) flow record whose 540 destination IP address matches {160.0.1.30}. 542 4.6. Collector 544 Collector is a subsystem that interacts with one or more IPFIX 545 devices. The functions of the collector MAY include: 547 * Identifying, accepting and decoding export packets from different 548 {Export Process, Observation Domain} pairs . 549 * Running the IPFIX protocol. 550 * Storing the control information and flow records received from 551 IPFIX device. 552 * Notifying the IPFIX device its status and problems. 554 4.7. Applications 556 Applications that use the information collected by IPFIX may be 557 Billing, Intrusion Detection sub-systems, etc. These applications may 558 be an integral part of the collector or collocated to the collector. 559 The way by which these applications interface with IPFIX system to 560 get the desired information is out of this document's scope. 562 5. IPFIX Protocol 564 5.1. Selection Criteria for IPFIX Protocol 566 There are existing standard practices in the area of flow export like 567 Netflow, CRANE, LFAP etc. The charter mentions to choose the the 568 protocol among these existing practices that fits the IPFIX 569 requirements the most. There may be additions or modifications made 570 to the chosen protocol to fit it exactly into the IPFIX architecture. 571 The following is the list of criteria that the candidate protocol 572 SHOULD meet in order to be the qualified into the IPFIX architecture. 573 This is based on the requirements specified in the requirement 574 document [2]. 576 5.1.1. Common for IPFIX Device and Collector 578 1. Transparency over transport protocol. Ability to operate over a 579 congestion aware transport like TCP or SCTP. 580 2. Transparency over any underlying security protocols. 581 3. The protocol SHOULD be based on a flexible data model based on 582 templates. 583 4. The protocol SHOULD be based on a extensible information model. 585 5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) 587 1. Ability to detect loss of connectivity with the collector and 588 trigger the appropriate action (eg. a switch over to an 589 alternate collector.) 590 2. Optionally export flow records to multiple collectors. 591 3. Monitor control information/flow record export, detect any 592 overload in the process of exporting. 594 5.1.3. Intellectual Property Rights 596 The protocol must abide by the intellectual property rights as 597 defined in rfc: 2026. Specifically section: 10.3.1. All 598 Contributions. If the protocol does not abide by this, it will not 599 be considered. 601 5.1.4. IPFIX Protocol on Collector 603 1. Monitor the reception of export packets from IPFIX device. 604 2. Optionally notify the status and overload conditions to the 605 IPFIX device. 606 Once the selection is made from the set of candidate protocols, this 607 section would be replaced by the chosen protocol. 609 5.2. Export Models 611 5.2.1. Export Model with Reliable Control Connection 613 As mentioned in the selection criteria, the control and data stream 614 MUST be transported over a congestion-aware transport protocol. If 615 the network in which the IPFIX device and collector are located does 616 not guarantee reliability, at least the control stream SHOULD be 617 exported over a reliable transport. There could be network security 618 concerns between IPFIX device and collector. To avoid re-inventing 619 the wheel, and to reduce the complexity of flow export protocol, one 620 or a combination of the following methods MAY be adopted as a 621 solution to achieve security : 623 * IP Authentication Header MAY be used when the threat environment 624 requires stronger integrity protections, but does not require 625 confidentiality. 626 * IP Encapsulating Security Payload (ESP) MAY be used to provide 627 confidentiality and integrity. 628 * If the transport protocol used is TCP, optionally TCP MD5 629 signature option MAY be used to protect against spoofed TCP 630 segments. 631 * If the transport protocol used is TCP, optionally TLS MAY be used 632 to add integrity, authenticity and confidentiality. 634 The data stream MAY be exported over an reliable or unreliable 635 transport protocol. 637 As explained above the transport connection (in the case of a 638 connection oriented protocol) is pre-setup between the IPFIX device 639 and the collector. Once connected, the collector side receives the 640 control information and uses this information to interpret the flow 641 records. The IPFIX device SHOULD set the keepalive (eg. keepalive 642 timeout in the case of TCP; the HEARTBEAT interval in the case of 643 SCTP; IPFIX protocol level Keepalive if any) to a sufficiently low 644 value so that it can quickly detect a collector crash. 646 5.3. Collector Crash Detection and Recovery 648 5.3.1. Export Model with Reliable Control Connection 650 The collector crash is detected at the IPFIX device by the break in 651 control connection (depending on the transport protocol the 652 connection timeout mechanisms differ). On detecting a Keepalive 653 timeout, the IPFIX device SHOULD stop sending the flow export data to 654 the collector and try reconnecting the transport connection. This is 655 valid for a single collector scenario. If there are multiple 656 collectors for the same IPFIX device, the IPFIX device opens control 657 connections to each of the collectors. But data gets sent only to 658 one of the collectors which is chosen as the primary. There could be 659 one or more collectors configured as secondary and a priority 660 assigned to them. The primary collector crash is detected at the 661 IPFIX device by the break in control connection (depending on the 662 transport protocol the connection timeout mechanisms differ). On 663 detecting loss of connectivity, the IPFIX device opens data stream 664 with the secondary collector of the next highest priority. This 665 collector now becomes the primary. The maximum export data loss would 666 be the amount of data exported in the time between when the loss of 667 connectivity to the collector happened, and the time at which this 668 was detected by the IPFIX device. 670 5.4. Collector Redundancy 672 Since IPFIX protocol requires a congestion-aware transport, achieving 673 redundancy using multicast is not an option. Multiple pairs could be setup, each to a different 675 collector from the same IPFIX device. The control and data 676 information are then replicated on each of the control stream and 677 data stream. 679 6. Security Consideration 681 IP flow information can be used for various purposes, such as usage 682 accounting, traffic profiling, traffic engineering, and intrusion 683 detection. For each application, the security requirement may differ 684 significantly from one to another. To be able to satisfy the security 685 needs of various IPFIX users, the architecture of IPFIX MUST provide 686 different levels of security protection. 688 6.1. Data security 690 IPFIX data consists of control stream and data stream generated by 691 the IPFIX device. 693 The IPFIX data may exist in both the IPFIX device and the collector. 694 In addition, the data is also transferred on the wire from the 695 exporter to the collector when it is reported. To provide security, 696 the data SHOULD be protected from adversary. 698 The protection of IPFIX data within the end system (IPFIX device and 699 collector) is out of the scope. It is assumed that the end system 700 operator will provide adequate security for the IPFIX data. 702 The IPFIX architecture MUST allow different levels of protection to 703 the IPFIX data on the wire. Where ever security functions are 704 required it is recommended to leverage to lower layers using either 705 IPsec or TLS, if they can successfully satisfy the security 706 requirement of IPFIX data protection. 708 To protect the data on the wire, three levels of granularity SHOULD 709 be supported: 711 6.1.1. No security 713 No security is required when the transport between the IPFIX device 714 and the collector is perceived as safe. This option allows the 715 protocol to run most efficiently without extra overhead and an IPFIX 716 solution MUST support it. 718 6.1.2. Authentication only 720 The authentication only protection provides the IPFIX users the 721 assurance of data integrity and authenticity. The data exchanged 722 between the IPFIX device and the collector is protected by 723 authentication signature. Any modification of the IPFIX data will be 724 detected by the recipient, resulting in discarding of the received 725 data. However, the authentication only option doesn't offer data 726 confidentiality. The IPFIX user SHOULD avoid use this option when 727 sensitive or confidential information is being exchanged. An IPFIX 728 solution SHOULD support this option. The authentication only option 729 SHOULD provide replay attack protection. Some means to achieve this 730 level of security are: 731 * TCP with MD5 options. 732 * IP Authentication Header 734 6.1.3. Encryption 736 Data encryption provides the best protection for IPFIX data. The 737 IPFIX data is encrypted at the sender and only the intended recipient 738 can decrypt and have access to the data. This option MUST be used 739 when the transport between the exporter and the collector are unsafe 740 and the IPFIX data needs to be protected. It is recommended to use 741 the underlying security layer functions for this purpose. Some means 742 to achieve this level of security are: 744 * Encapsulating Security Payload. 745 * Transport Layer Security Protocol 747 The data encryption option adds overhead to the IPFIX data transfer. 748 It may limit the rate that an export can report its flow to the 749 collector due to the heavy resource requirement of running 750 encryption. 752 6.2. IPFIX end point authentication 754 It is important to make sure that the IPFIX device is talking to the 755 "right" collector instead of a masqueraded collector. The same logic 756 also holds true from the collector point of view that it want to make 757 sure it is collecting the flow information from the "right" IPFIX 758 device. The IPFIX architecture SHOULD allow the authentication 759 capability so that either one-way or mutual authentication can be 760 performed between the IPFIX device and collector. 762 The IPFIX architecture SHOULD use the existing transport protection 763 protocols such as TLS to fulfill the authentication requirement. 765 6.3. Denial of service (DoS) attack prevention 767 Since one of the potential usages for IPFIX is for intrusion 768 detection, it is important for the IPFIX architecture to support some 769 kind of DoS resistance. 771 6.3.1. Network under attack 773 The Network itself may be under attack, resulting in an overwhelming 774 number of IPFIX messages. The IPFIX SHOULD try to capture as much 775 information as possible. However, when large amount IPFIX messages 776 are generated in a short period of time, the IPFIX may become 777 overloaded. 779 6.3.2. Generic DoS attack on the IPFIX system 781 The IPFIX system may subject to generic DoS attacks, just as any 782 system on any open networks. These types of attacks are not IPFIX 783 specific. Preventing and responding to such types of attacks are out 784 of the scope of IPFIX WG. 786 6.3.3. IPFIX Specific DoS attack 788 There is a specific attack on the IPFIX portion of the IPFIX device 789 or Collector. 791 (To be added and discussed on the general list). 793 7. Flow Expiration 795 A flow is considered to be inactive if no packets of this flow has 796 been observed at the observation point for a given timeout interval. 797 The flow can be exported under the following conditions: 799 1. If the exporter can deduce the end of a flow, the exporter 800 SHOULD export the flow records when the end of the flow is 801 detected. For example: flow generated by TCP type of traffic 802 where the FIN or RST bits indicate the end of the flow 804 2. If the flow has been inactive for a certain period of time. 805 This inactivity timeout SHOULD be configurable. For example: 806 flow generated by UDP type of traffic. 808 3. For long aging flows, the exporter SHOULD export the flow 809 records on regular basis, in order to: 811 a. Report the flow records periodic accounting information to 812 the collector 813 b. Avoid counter wrapping This activity timeout SHOULD be 814 configurable 816 4. If the exporter experiences resources constraints, a flow MAY be 817 prematurely expired (example: memory) 819 8. IANA Consideration 821 Need Port number assigned from IANA [more to be written] 823 9. References 825 [1] IP Flow Information Export (IPFIX) 826 828 [2] J. Quittek ,T. Zseby, B. Claise,"Requirements for IP Flow 829 Information Export", (work in progress) ,Internet Draft, Internet 830 Engineering Task Force, , August 2002 832 [3] K.C. Norseth, Paul Calato,"Data Model for IP Flow Information 833 Export", (work in progress) ,Internet Draft, Internet Engineering 834 Task Force, , August 2002 836 10. Acknowledgements 838 We like to thank all the people contributing to the requirements 839 discussion on the mailing list, and the design teams for many 840 valuable comments. 842 George Carle 843 Tanja Zseby 844 Paul Calato 845 Dave Plonka 846 Kevin Zhang 847 KC Norseth 848 Benoit Claise 849 Ganesh Sadasivan 850 Vamsi Valluri 851 Cliff Wang 852 Ram Gopal 853 Jc Martin 854 Carter Bullard 855 Juergen Quittek 856 Reinaldo Penno 857 Nevil Brownlee 858 Simon Leinen 860 11. Author's Addresses 862 Benoit Claise 863 Cisco Systems 864 De Kleetlaan 6a b1 865 1831 Diegem 866 Belgium 867 Phone: +32 2 704 5622 868 Email: bclaise@cisco.com 870 Ganesh Sadasivan 871 Cisco Systems, Inc. 872 170 W. Tasman Dr. 873 San Jose, CA 95134 874 USA 875 Phone: +1 (408) 527-0251 876 Email: gsadasiv@cisco.com 878 K.C. Norseth 879 Consultant 880 Phone: +1 (801) 546-3316 881 Email: kcn@norseth.com 883 Juergen Quittek 884 NEC Europe Ltd. 885 Adenauerplatz 6 886 69115 Heidelberg 887 Germany 888 Phone: +49 6221 90511-15 889 EMail: quittek@ccrle.nec.de 891 12. Full Copyright Statement 893 "Copyright (C) The Internet Society (date). All Rights Reserved. This 894 document and translations of it may be copied and furnished to 895 others, and derivative works that comment on or otherwise explain it 896 or assist in its implementation may be prepared, copied, published 897 and distributed, in whole or in part, without restriction of any 898 kind, provided that the above copyright notice and this paragraph are 899 included on all such copies and derivative works. However, this 900 document itself may not be modified in any way, such as by removing 901 the copyright notice or references to the Internet Society or other 902 Internet organizations, except as needed for the purpose of 903 developing Internet standards in which case the procedures for 904 copyrights defined in the Internet Standards process must be 905 followed, or as required to translate it into.