idnits 2.17.1 draft-ietf-ipfix-reqs-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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 191 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 753 has weird spacing: '... can be preve...' -- 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 (February 2002) is 8077 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: 'RFC2274' is defined on line 787, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3234 (ref. 'MIDBOXTAX') ** Downref: Normative reference to an Informational RFC: RFC 2702 ** Obsolete normative reference: RFC 2274 (Obsoleted by RFC 2574) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Quittek 3 NEC Europe Ltd. 4 Expires: August 2002 T. Zseby 5 FhI FOKUS 6 B. Claise 7 Cisco Systems 8 (Editors) 10 February 2002 12 Requirements for IP Flow Information Export 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This memo defines requirements for the export of measured IP flow 38 information out of routers, traffic measurement probes and 39 middleboxes. 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC 2119. 47 Table of Content 49 1. Introduction 50 2. Terminology 51 2.1. IP Traffic Flows 52 2.2. Observation Point 53 2.3. Metering Process 54 2.4. Flow Record 55 2.5. Export Process 56 2.6. Flow Information Collector or Collector 57 2.7. IPFIX device 58 3. Applications Requiring IP Flow Information Export 59 3.1 Usage-based Accounting 60 3.2 Traffic Profiling 61 3.3 Traffic Engineering 62 3.4 Attack/Intrusion Detection 63 3.5 QoS Monitoring 64 4. Distinguishing Flows 65 4.1. Interfaces 66 4.2. IP Header Fields 67 4.3. Transport Header Fields 68 4.4. MPLS Label 69 4.5. DiffServ Code Point 70 4.6. Header Compression and Encryption 71 5. Metering Process 72 5.1. Reliability 73 5.2. Sampling 74 5.3. Overload Behavior 75 5.4. Timestamps 76 5.5. Time Synchronization 77 5.6. Timeout 78 5.7. Ignore Port Copy 79 6. Data Export 80 6.1. Information Model 81 6.2. Data Model 82 6.3. Data Transfer 83 6.3.1. Congestion Awareness 84 6.3.2. Reliability 85 6.3.3. Security 86 6.4. Push and Pull Mode Reporting 87 6.5. Regular Reporting Interval 88 6.6. Notification on Specific Events 89 6.7. Anonymization 90 7. Configuration 91 8. General Requirements 92 8.1. Openness 93 8.2. Scalability concerning measuring devices 94 8.3. Several Data Collectors 95 9. Security Considerations 96 10. Acknowledgments 97 11. References 98 12. Authors' Addresses 99 Appendix: Derivation of Requirements form Target Applications 101 1. Introduction 103 There are several applications that require flow-based IP traffic 104 measurements. Such measurements could be performed by a router while 105 forwarding the traffic, by a middlebox [MIDBOXTAX], or by a traffic 106 measurement probe attached to a line or a monitored port. This memo 107 defines requirements for exporting traffic flow information out of 108 these boxes for further processing by applications located on other 109 devices. In section 2 a selection of such applications is presented. 110 The following sections list requirements derived from these 111 applications. 113 2. Terminology 115 2.1. IP Traffic Flows 117 There are several definitions of the term 'flow' being used by the 118 Internet community. Within this document we use the following one: 120 A flow is defined as a set of packets passing an observation point in 121 the network during a certain time interval. All packets belonging to 122 a particular flow have a set of common properties. Each property is 123 defined as the result of applying a function to the values of: 125 1. one or more of packet header fields (eg. destination IP 126 address) 127 2. one or more properties of the packet itself (eg. packet length) 128 3. one or more of fields derived from packet treatment (eg. AS 129 number) 131 A packet is defined to belong to a flow if it completely satisfies 132 all the defined properties of the flow. 134 This definition covers the range from a flow containing all packets 135 observed at a network interface to a flow consisting of just a single 136 packet between two applications with a specific sequence number. 137 Please note that the flow definition does not match a general 138 application-level end-to-end stream. However, an application may 139 derive properties of application-level streams by processing measured 140 flow data. 142 2.2. Observation Point 144 The observation point is a location in the network where IP packets 145 can be observed. Examples are a line to which a probe is attached, a 146 shared medium, such as an Ethernet-based LAN, a single port of a 147 router, or a set of interfaces (physical or logical) of a router. 149 2.3. Metering Process 151 The metering process gets as input all packets observed at the 152 observation point. On these packets it performs the actions of 153 timestamping, sampling, filtering, mapping them to flows. 154 Furthermore, the metering process includes maintaining flow records, 155 computing flow statistics, and detecting flow expiration. 157 2.4. Flow Record 159 A flow record provides information about a specific flow that was 160 measured at an observation point using a certain set of methods 161 within an exporter. A flow record may contain characteristic 162 properties of the flow, for example the source IP address, as well as 163 measured properties of the flow, for example the total number of 164 bytes of all packets of the flow. 166 2.5. Export Process 168 Flow information export denotes the process of sending flow records 169 to one or more collectors. 171 2.6. Flow Information Collector or Collector 173 The collector receives flow records from one or more exporters. The 174 collector might process or store received flow record, but these 175 actions are out of the scope of this document. 177 2.7. IPFIX device 179 A device hosting at least a flow information export process. 180 Typically, corresponding Observation points, metering processes, and 181 exporter processes are co-located at this device, for example at a 182 router. But also different scenarios are possible: In a hierarchical 183 flow information collection system a collector might be co-located 184 with the export process. Then the collector receives flow records 185 from remote exporters and the exporter exports them to a higher level 186 in the hierarchy. 188 3. Applications Requiring IP Flow Information Export 190 The following list contains a selection of applications requiring IP 191 flow information export. Because requirements for flow export listed 192 in further sections below are derived from these applications, their 193 selection is crucial. The goal of this requirements document is not 194 to cover all possible applications with all their flow export 195 requirements, but to cover applications which are considered to be of 196 significant importance in today's or future IP networks, and for 197 which requirements can be met with reasonable technical effort. 199 Please note, that the described applications can have a large number 200 of differing implementations. Requirement details or the weighting of 201 requirements could differ for specific implementations. Therefore we 202 derive the requirements from the general functionality of the 203 selected applications. Furthermore, the list of applications should 204 lead to a better understanding of the requirements which is 205 particularly important when designing or implementing a traffic flow 206 measuring device. 208 3.1 Usage-based Accounting 210 Several new business models for selling IP service and IP-based 211 services are currently under investigation. Beyond flat rate services 212 which do not need accounting, accounting for these models can be 213 based on time or volume. Accounting data can serve as input for 214 billing systems. Accounting can be performed per user or per user 215 group, it can be performed just for basic IP service or individually 216 per high-level service and/or per content type delivered. For 217 advanced/future services, accounting may also be performed per class 218 of service, per application, per time of day, per used (label 219 switched) path, etc. 221 3.2 Traffic Profiling 223 Traffic profiling is a process of characterizing IP flows and flow 224 aggregates by using a model that represents key parameters of the 225 flow such as flow duration, volume, time and burstiness. It is a 226 prerequisite for network planning, network dimensioning, trend 227 analysis, developing business models, and other activities. It 228 heavily depends on the particular traffic profiling objective(s) what 229 statistics and accuracy are required from the measurements. Typical 230 information needed for traffic profiling are the distribution of used 231 services and protocols in the network, the amount of packets of a 232 specific type (e.g. percentage of IPv6 packets) and specific flow 233 profiles. 235 Since objectives for traffic profiling can vary, this application 236 requires a high flexibility of the measurement infrastructure, 237 especially regarding the options for measurement configuration and 238 packet classification. 240 3.3 Traffic Engineering 242 Traffic Engineering (TE) comprises methods for measurement, modeling, 243 characterization and control of a network. The goal of TE is the 244 optimization of network resource utilization and traffic performance 245 [RFC2702]. Since control and administrative reaction to measurement 246 results requires access to the involved network nodes, TE mechanisms 247 and the required measurement function usually are performed within 248 one administrative domain. Typical parameters required for TE are 249 link utilization, load between specific network nodes, number, size 250 and entry/exit points of the active flows and routing information. 252 3.4 Attack/Intrusion Detection 254 Capturing of flow information plays an important role for network 255 security, both for detection of security violation, and for 256 subsequent defense. In case of a Denial of Service (DOS) attack, flow 257 monitoring can allow detection of unusual load situations or 258 suspicious flows. In a second step, flow analysis can be performed in 259 order to gather information about the attacking flows, and for 260 deriving a defense strategy. 262 Intrusion detection is a potentially more demanding application which 263 would not only look at specific characteristics of flows, but that 264 may also use a stateful packet flow analysis for detecting specific, 265 suspicious activities, or unusually frequent activities. Such 266 activities may be characterized by specific communication patterns, 267 detectable by characteristic sequences of certain packet types. 269 3.5 QoS Monitoring 271 QoS monitoring is the non-intrusive (passive) measurement of quality 272 parameters for single flows or traffic aggregates. In contrast to 273 intrusive (active) measurements, non-intrusive measurements utilize 274 the existing traffic in the network for QoS analysis. Since no test 275 traffic is sent, non-intrusive measurements can only be applied in 276 situations where the traffic of interest is already present in the 277 network. One example application is the validation of QoS parameters 278 negotiated in a service level specification (SLS). 280 Non-intrusive measurements cannot provide the kind of controllable 281 experiments that can be achieved with active measurements. On the 282 other hand non-intrusive measurements do not suffer from undesired 283 side effects caused by sending test traffic (e.g. additional load, 284 potential differences in treatment of test traffic and real customer 285 traffic) 287 QoS monitoring often requires the correlation of data from multiple 288 measurement instances (e.g. for measuring one-way metrics). This 289 requires proper clock synchronization of the involved measurement 290 instances. For some measurements packet events at the different 291 measurement points must be correlated. For this, the provisioning of 292 post-processing functions (e.g. the generation of packet IDs) at the 293 measurement instances would be useful. Furthermore, QoS monitoring 294 can lead to a huge amount of measurement result data. Therefore it 295 would highly benefit from mechanisms to reduce the measurement data, 296 like aggregation of results and flow sampling. 298 4. Distinguishing Flows 300 Packets are mapped to flows by evaluating their properties. Packets 301 with common properties are considered to belong to the same flow. A 302 packet showing at least one difference in the set of properties is 303 considered to belong to a different flow. 305 The following subsections list a set of properties which a metering 306 process MUST, SHOULD, or MAY be able to evaluate for mapping packets 307 to flows. Please note that requiring the ability to evaluate a 308 certain property does not imply that this property must be evaluated 309 for each packet. 311 In other words, compliant with IPFIX means that the metering process 312 in general must be able, via its configuration, to somehow support to 313 distinguish flows via all the MUST fields, even if in certain 314 circumstance/for certain applications, only a subset of the MUST 315 fields is needed and only a subset of the MUST fields is effectively 316 used to distinguish flows. 318 Which combination of properties is evaluated for a particular 319 measurement and how these properties are evaluated depends on the 320 configuration of the IPFIX device. The configured choice of 321 evaluated properties strongly depends on the environment and purpose 322 of the measurement and on the information required by the collector. 324 For specific deployments, only a subset of the REQUIRED properties 325 listed below could be used to distinguish flows, in order to 326 aggregate the flow records and reduce the number of flow records 327 exported. On the other hand, some other deployments will require to 328 distinguish flows by some extra parameters, like for example the TTL 329 field of the IP header or the BGP Autonomous Systems. 331 4.1. Interfaces 333 The metering process MUST be able to separate flows by the incoming 334 interface or by the outgoing interface or by both of them, if the 335 observation point consists of one or more ports of a router. 337 4.2. IP Header Fields 339 The metering process MUST, SHOULD, or MAY be able to separate flows 340 by the following fields of the IP header as indicated. 342 1. source IP address (MUST) 343 2. destination IP address (MUST) 344 3. transport protocol type (TCP,UDP,ICMP,...) (MUST) 345 4. IP version number (SHOULD) 346 This requirement only applies if the device is supporting 347 more than one version of IP. 349 For source address and destination address separating by full match 350 MUST be supported as well as separation by a partial match (for 351 example subnet masking). 353 4.3. Transport Header Fields 355 The metering process MUST be able to separate flows by the port 356 numbers of the transport header in case of TCP or UDP being used as 357 transport protocol. Both, source and destination port number MUST be 358 supported for distinguishing flows, individually as well as in 359 combination. 361 4.4. MPLS Label 363 If the metering process supports Multiprotocol Label Switching (MPLS, 364 see [RFC3031]), then the measuring device MUST be able to separate 365 flows by the MPLS label. 367 4.5. DiffServ Code Point 369 If the IPFIX device supports Differentiated Services (DiffServ) and 370 if the observation point is local to this device, then the metering 371 process MUST be able to separate flows by the DiffServ Code Point 372 (DSCP, see [RFC2474]). 374 4.6. Header Compression and Encryption 376 If header compression or encryption is used, the metering process 377 might not be able to access all header fields. In such a case only 378 observation points at end points of header compression or of packet 379 encryption are expected to meet the requirements stated in this 380 section 4. 382 5. Metering Process 384 The following are requirements for the metering process. All 385 measurements MUST be conducted from the point of view of the 386 observation point. 388 5.1. Reliability 390 The metering process MUST either be reliable or missing reliability 391 MUST be known and indicated. The metering process is reliable, if 392 each packet passing the observation point is measured according to 393 the configuration of the metering process. If, e.g. due to some 394 overload, not all passing packets can be included into the metering 395 process, then the metering process MUST be able to detect this 396 failure and to report about it. 398 5.2. Sampling 400 The metering process MAY support measuring traffic by packet 401 sampling. If sampling is supported the sampling method and its 402 parameters MUST be well defined. If sampling parameters are changed 403 during operation, this MUST be indicated to all collectors receiving 404 the affected flow records. 406 5.3. Overload Behavior 408 In case of an overload, e. g. lack of memory or processing power, the 409 metering process MAY change in order to cope with the lack of 410 resources. Possible reactions include: 412 - Reduce the number of flow accounts. This can be achieved by more 413 coarse grained flow measurement or by a restriction of the flow 414 accounts to a subset of the set of original ones. 415 - Switch to sampling packets before they are processed by the 416 meter or - if sampling is already performed - reduce the 417 sampling rate. 418 - Stop metering. 420 Overload behavior is not restricted to the three options listed 421 above. But in any case, the overload behavior MUST be clearly defined 422 and the collector MUST be able to distinguish the flow records 423 exported before and after the metering process behavior change. 425 For example in the case of switching to sampling, the collector MUST 426 be able to distinguish the flow records generated with sampling from 427 the flow records generated without sampling and the sampling method 428 and all its parameters MUST be known or indicated. 430 5.4. Timestamps 432 The metering process MUST be able to generate a timestamp for each 433 observed packet. Please note that section 5.1 requires to offer 434 reporting a timestamp for the first and the last observed packet of a 435 flow. Therefore, the metering process MUST be able to store at least 436 two timestamps per flow. 438 5.5. Time Synchronization 440 Different metering process(es) and collector(s) SHOULD be time 441 synchronized between each other. NTP is a possible way of achieving 442 this. Where there are so many types of synchronization between IPFIX 443 devices and collectors, the synchronization of the devices and 444 collectors cannot be defined as part of IPFIX. The method for time 445 synchronization is not in the scope of IPFIX. 447 5.6. Timeout 449 The metering process MUST be able to detect flow timeout. A flow is 450 considered to be timed out if no packet of this flow has been 451 observed for a given timeout interval. The metering process MAY 452 support means for detecting the end of a flow before a time out 453 occurs, for example by detecting the FIN or RST bits in a TCP 454 connection. 456 5.7. Ignore Port Copy 458 The metering process MAY be able to ignore packets which are 459 generated by a port copy function acting at the same device. 461 6. Data Export 463 The following are requirements for exporting measured flow data out 464 of the IPFIX device. Beside requirements on the data transfer, we 465 separate requirements concerning the information model from 466 requirements concerning the data model. Furthermore, we list 467 requirements on reporting times and events and on anonymization of 468 records. 470 6.1. Information Model 472 The information model for the flow information export is the list of 473 attributes of a flow to be contained in the report (including the 474 semantics of the attributes). 476 This section lists attributes an export process MUST or MAY be able 477 to report. This does not imply that a exported flow records MUST 478 contain all REQUIRED attributes, but that it MUST be possible to 479 configure the device in a way that all of the REQUIRED attributes are 480 contained in the flow records for each measured flow. 482 In other words, compliant with IPFIX means that the box in general 483 must be able, via its configuration, to somehow support to report all 484 the MUST fields, even if in certain circumstance/for certain 485 applications, only a subset of the MUST fields is needed and only a 486 subset of the MUST fields is effectively reported. 488 Beyond that, the device might offer to report also further attributes 489 not mentioned here. A particular flow record may contain some of the 490 "REQUIRED" attributes as well as some additional ones, for example 491 covering future technologies. 493 The measuring device MUST be able to report the following attributes 494 for each measured flow: 496 1. IP version number 497 This requirement only applies if the device is supporting more 498 than one version of IP. 499 2. source IP address 500 3. destination IP address 501 4. transport protocol type 502 5. source TCP/UDP port number 503 6. destination TCP/UDP port number 504 7. packet counter 505 If a packet is fragmented, each fragment is counted as an 506 individual packet. 507 8. byte counter 508 9. in case of IPv4: Type of Service 510 10. in case of IPv6: Flow Label 511 11. if BGP is supported: BGP AS# 512 12. if MPLS is supported: MPLS label 513 13. if DiffServ is supported: DSCP 514 14. timestamp of the first packet observed 515 15. timestamp of the last packet observed 516 16. if sampling is used: sampling method 517 17. if sampling is used: sampling parameters 518 18. unique identifier of the observation point 519 19. unique identifier of the export process 521 The measuring device MAY be able to report the following attributes 522 for each measured flow: 523 20. Time To Live 524 21. IP header flags 525 22. TCP header flags 526 23. dropped packet counter 527 If a packet is fragmented, each fragment MUST be counted as an 528 individual packet. This requirements does not apply to probes where 529 the value of this counter is always zero. 530 24. fragmented packet counter 531 counter of all packets for which the fragmented bit is set in 532 the IP header 533 25. multicast replication factor 534 the number of outgoing packets originating from a single 535 incoming multicast packet 537 6.2 Data Model 539 The data model describes how information is represented in flow 540 records. The data model used for exporting flow information MAY be 541 flexible concerning the flow attributes contained in flow records. A 542 flexible record format would offer the possibility of defining 543 records in a flexible (customizable) way regarding the number and 544 type of contained attributes. 546 The data model MUST be extensible for future attributes to be added. 547 Even if a set of attributes is fixed in the flow record, the data 548 model MUST provide a way of extending the record by configuration or 549 for certain implementations. 551 The Data Model SHOULD be independent of the underlying transport 552 protocol, i.e. the data transfer. 554 6.3. Data Transfer 556 Requirements for the data transfer include reliability and security 557 requirements. These requirements do not apply to the measuring device 558 alone, but also to the transport network. Consequently, the export 559 process does not necessarily have to guarantee that all requirements 560 are met. Particularly if the security requirements are already 561 guaranteed by the network used for data transfer, then these 562 requirements do not have to be considered anymore by the export 563 process. Therefore, these requirements are OPTIONAL for the export 564 process, although they may be REQUIRED for the data transfer as 565 specified in the appendix. 567 6.3.1. Congestion Awareness 569 For the data transfer a congestion aware protocol MUST be supported. 571 6.3.2. Reliability 573 Absence of reliability of the data transfer MUST be indicated 574 covering packet loss and packet reordering. 576 Please note that if an unreliable transport protocol is used, 577 reliability can be provided by higher layers. In such a case only 578 lack of overall reliability MUST be indicated. For example reordering 579 could be dealt with by adding a sequence number to each packet. 581 6.3.3. Security 583 Confidentiality of transferred IPFIX data SHOULD be ensured. 585 Integrity of transferred IPFIX data MUST be ensured. 587 Authenticity of transferred IPFIX data MUST be ensured. 589 6.4. Push and Pull Mode Reporting 591 In general, there are two ways of deciding on reporting times: push 592 mode and pull mode. In push mode, the export process decides without 593 an external trigger on when to send a report on measured flows. In 594 pull mode, sending a report is triggered by an explicit request from 595 a collector. The measuring device MUST support push mode reporting, 596 it MAY support pull mode reporting. 598 6.5. Regular Reporting Interval 600 The export process SHOULD be capable of reporting measured traffic 601 data regularly according to a given interval length. 603 6.6. Notification on Specific Events 605 The export process MAY be capable of sending notifications to a 606 consumer of measure data, if a specific event occurs. Such an event 607 might be the arrival of the first packet of a new flow, or the 608 termination of a flow after flow timeout. 610 6.7. Anonymization 612 The export process MAY be capable of anonymizing source and 613 destination IP addresses in flow data before exporting them. It MAY 614 support anonymization of port numbers and other fields. Please note 615 that anonymization is not originally an application requirement, but 616 derived from general requirements for treatment of traffic within a 617 network. 619 7. Configuration 621 The IPFIX device MUST provide a way of configuring the traffic 622 measurement and the traffic data export. The following parameters 623 SHOULD be configurable: 625 1. specification of the observation point, e.g. a list of 626 interfaces to be monitored. 627 2. specifications of flows to be measured 628 3. reporting data format 629 Specifying the reporting data format SHOULD include a selection 630 of attributes to be reported for each flow. 631 4. flow timeouts 633 The following parameters MAY be configurable: 635 5. notifications 636 6. sampling method and parameters, if feature is supported 637 7. flow anonymization, if feature is supported 639 If configuration is done remotely, the IPFIX device SHOULD support 640 security of the configuration including confidentiality, integrity 641 and authenticity. The means used for remote configuration of IPFIX 642 devices are out of the scope of this document. 644 8. General Requirements 646 8.1. Openness 648 IPFIX specifications SHOULD be open to future technologies. This 649 includes extensibility of configuration of measurement and reporting 650 as well as extensibility of the reporting information model and data 651 model. 653 8.2. Scalability concerning measuring devices 655 Data collection from hundreds of different IPFIX devices MUST be 656 supported. The collector MUST be able to distinguish several hundred 657 IPFIX devices by their identifiers. 659 8.3. Several Collectors 661 The exporting process MAY be able to export flow information to more 662 than one collector. 664 9. Security Considerations 666 This document describes requirements for IP Flow Information Export 667 (IPFIX). It therefore also states the required security features for 668 a future IPFIX protocol. Nevertheless, the suggestion of solutions 669 for achieving the security properties is out of scope of this 670 document and will be part of future IPFIX documents that specify 671 IPFIX architecture and protocol. 673 Like other requirements, the security requirements differ for the 674 considered applications. The incentive to modify collected for 675 accounting or intrusion detection for instance is usually higher than 676 the incentive to change data collected for traffic profiling. 677 Therefore the required security features are listed per application. 678 Furthermore, the security requirements also differ with regard to the 679 environment in which an IPFIX protocol is used (e.g. intra- or inter- 680 domain). Some of these issues are part of the IPFIX architecture and 681 with this out of scope of this document. Therefore this document also 682 tries to consider security threats that can only occur in an insecure 683 environment (e.g. where it can not be excluded, that an attacker 684 might gain access to the network). 686 Several security hazards also occur if the IPFIX device is configured 687 remotely (e.g. access to the measurement process, forgery of 688 configuration information, etc.). Nevertheless, this document 689 specifies only what parameters SHOULD or MAY be configurable for the 690 IPFIX device. It does not deal with requirements for a protocol for 691 measurement configuration. Therefore security considerations 692 regarding the measurement configuration are out of scope of this 693 document. 695 The following potential security hazards for an IPFIX protocol can be 696 identified: 698 - Disclosure of IP flow information data 699 It may be required to keep measurement records confidential 700 between the involved parties. Observation of IP flow 701 information data gives an attacker information about the active 702 flows in the network, communication endpoints and traffic 703 patterns. This information can not only be used to spy out user 704 behavior but also to plan and conceal future attacks. Therefore 705 the requirements document recommends to ensure the 706 confidentiality of the transferred data. This can be done for 707 instance by encryption. 709 Furthermore, features for anonymization may be provided by the 710 future IPFIX protocol. With this communication endpoints can be 711 kept confidential. Anonymization is also a useful feature to 712 allow measurements (e.g. by a third party) without violating 713 privacy protection. 715 - Forgery of exported IP flow information data 716 Especially for applications like accounting or intrusion 717 detection there are strong incentives (e.g. save money or 718 prevent detection of an attack) to forge exported IP flow 719 information records. This can be done either by altering data 720 on the path or by exporting records from a device that pretends 721 to be the IPFIX device. In order to make the IPFIX protocol 722 resistant against such attacks this document requires to ensure 723 authenticity and integrity of the data for the IPFIX data 724 transfer. 726 Special caution is required if security applications rely on 727 IPFIX data With forgery of exported IP flow information data it 728 is possible to trick on security applications. With this it can 729 be for instance possible to pretend that a DoS attack happens 730 without even launching a real attack. 732 - Denial of Service (DoS) attacks 733 DoS attacks on routers or other middleboxes that have the IPFIX 734 protocol implemented would also affect the IPFIX protocol and 735 impair the sending of IPFIX records. Nevertheless, since such 736 hazards are not induced specifically by the IPFIX protocol the 737 prevention of such attacks is out of scope of this document. 739 IPFIX itself causes the following potential hazards for DoS 740 attacks. It is always possible to overload the IPFIX device if 741 it expects the reception of traffic. For IPFIX this can occur 742 in two cases. First, if the protocol supports the pull mode 743 (which is one option in this document) and expects requests. 744 Secondly, if data is expected for remote measurement 745 configuration. The first case could be prevented by ensuring 746 authenticity for IPFIX requests. The second case should be 747 addressed for the specification of an IPFIX remote 748 configuration mechanism and therefore is out of scope of this 749 document. 751 Also IPFIX collectors can become target of an DoS attack. This 752 can be done by sending IPFIX data from a malicious device that 753 pretends to be an IPFIX device. This can be prevented by 754 ensuring authenticity of IPFIX data as stated in this document. 755 It is also possible that collectors are flooded with IPFIX 756 record from an authorized IPFIX devices for which the 757 configuration was altered. Furthermore, malicious configuration 758 or forgery of exported data can cause a loss or re-direction of 759 flow information (e.g. if destination addresses for flow 760 records are modified). This can lead to a disruption of upper 761 layer services (accounting, intrusion detection, etc.) due to 762 lack of IPFIX records. This can be prevented by controlling 763 configuration access and by ensuring the integrity of exported 764 data. 766 10. Acknowledgments 768 We like to thank all the people contributing to the requirements 769 discussion on the mailing list for a lot of valuable comments. 771 11. References 773 [MIDBOXTAX] B. Carpenter, "Middleboxes: taxonomy and issues", 774 RFC 3234, February 2002. 776 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 777 Switching Architecture", RFC 3031, January 2001. 779 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition 780 of the Differentiated Services Field (DS Field) in the IPv4 781 and IPv6 Headers", RFC 2474, December 1998. 783 [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 784 "Requirements for Traffic Engineering Over MPLS", 785 RFC 2702, September 1999. 787 [RFC2274] U. Blumenthal, B. Wijnen "User-based Security Model (USM) 788 for version 3 of the Simple Network Management Protocol 789 (SNMPv3), RFC 2274, January 1998. 791 12. List of Authors 793 Juergen Quittek 794 NEC Europe Ltd., Network Laboratories 795 Adenauerplatz 6 796 69115 Heidelberg 797 Germany 799 Phone: +49 6221 90511-15 800 EMail: quittek@ccrle.nec.de 802 Tanja Zseby 803 Fraunhofer Institute for Open Communication Systems (FOKUS) 804 Kaiserin-Augusta-Allee 31 805 10589 Berlin 806 Germany 808 Phone: +49 30 3463 7153 809 Email: zseby@fokus.fhg.de 811 Georg Carle 812 Fraunhofer Institute for Open Communication Systems (FOKUS) 813 Kaiserin-Augusta-Allee 31 814 10589 Berlin 815 Germany 817 Phone: +49 30 3463 7149 818 Email: carle@fokus.fhg.de 819 Sebastian Zander 820 Fraunhofer Institute for Open Communication Systems (FOKUS) 821 Kaiserin-Augusta-Allee 31 822 10589 Berlin 823 Germany 825 Phone: +49 30 3463 7287 826 Email: zander@fokus.fhg.de 828 Benoit Claise 829 Cisco Systems 830 De Kleetlaan 6a b1 831 1831 Diegem 832 Belgium 834 Phone: +32 2 704 5622 835 Email: bclaise@cisco.com 837 K.C. Norseth 838 Enterasys Networks 839 2691 S. Decker Lake Lane 840 Salt Lake City, Utah 84119 841 USA 843 Phone: +1 801 887 9823 844 Email: knorseth@enterasys.com 846 Appendix: Derivation of Requirements form Target Applications 848 The following table documents, how the requirements stated in 849 sections 3-7 are derived from requirements of the applications listed 850 in section 2. 852 Used abbreviations: 853 M = MUST 854 S = SHOULD 855 O = MAY (OPTIONAL) 856 - = DONT CARE 858 -----------------------------------------------------------------------. 859 IPFIX | 860 ----------------------------------------------------------------. | 861 E: QoS Monitoring | | 862 ----------------------------------------------------------. | | 863 D: Attack/Intrusion Detection | | | 864 ----------------------------------------------------. | | | 865 C: Traffic Engineering | | | | 866 ----------------------------------------------. | | | | 867 B: Traffic Profiling | | | | | 868 ----------------------------------------. | | | | | 869 A: Usage-based Accounting | | | | | | 870 ----------------------------------. | | | | | | 871 | | | | | | | 872 | Sect. | Requirement | A | B | C | D | E | IPFIX| 873 |-------+-------------------------+-----+-----+-----+-----+-----+------| 874 | 4. | DISTINGUISHING FLOWS | 875 |-------+-------------------------+-----+-----+-----+-----+-----+------| 876 | 4. | Combination of | M | M | M | M | M | M | 877 | | required attributes | | | | | | | 878 |-------+-------------------------+-----+-----+-----+-----+-----+------| 879 | 4.1. | in/out IF | S | M | M | S | S | M | 880 |-------+-------------------------+-----+-----+-----+-----+-----+------| 881 | 4.2. | src/dst address | M | M | M | M | M | M | 882 |-------+-------------------------+-----+-----+-----+-----+-----+------| 883 | 4.2. | Masking of IP adresses | M | M | M | M | M | M | 884 |-------+-------------------------+-----+-----+-----+-----+-----+------| 885 | 4.2. | transport protocol | M | M | - | M | M | M | 886 |-------+-------------------------+-----+-----+-----+-----+-----+------| 887 | 4.2. | version field | - | S | S | O | O | S | 888 | | | | | (b) | | | | 889 |-------+-------------------------+-----+-----+-----+-----+-----+------| 890 | 4.3. | src/dst port | M | M | - | M | M | M | 891 |-------+-------------------------+-----+-----+-----+-----+-----+------| 892 | Sect. | Requirement | A | B | C | D | E | IPFIX| 893 |-------+-------------------------+-----+-----+-----+-----+-----+------| 894 | 4.4. | MPLS label (a) | S | S | M | O | S | M | 895 | | | | | (c) | | | | 896 |-------+-------------------------+-----+-----+-----+-----+-----+------| 897 | 4.5. | DSCP (a) | M | S | M | O | M | M | 898 |-------+-------------------------+-----+-----+-----+-----+-----+------| 899 | 5. | METERING PROCESS | 900 |-------+-------------------------+-----+-----+-----+-----+-----+------| 901 | 5.1. | Reliability | M | S | S | S | S | | 902 |-------+-------------------------+-----+-----+-----+-----+-----+ M | 903 | 5.1. | Indication of | - | M | M | M | M | | 904 | | missing reliability | | | | | | | 905 |-------+-------------------------+-----+-----+-----+-----+-----+------| 906 | 5.2. | Sampling (g) | O | O | O | O | O | O | 907 |-------+-------------------------+-----+-----+-----+-----+-----+------| 908 | 5.2. | Dynamic sampling | O | O | O | O | O | O | 909 |-------+-------------------------+-----+-----+-----+-----+-----+------| 910 | 5.4. | Timestamping at | M | O | O | S | M | M | 911 | | measurement device | | | | | | | 912 |-------+-------------------------+-----+-----+-----+-----+-----+------| 913 | 5.5. | Time synchronization | S | S | S | S | S | S | 914 |-------+-------------------------+-----+-----+-----+-----+-----+------| 915 | 5.6. | Flow timeout | M | S | - | O | O | M | 916 | | | (d) | | | | | | 917 |-------+-------------------------+-----+-----+-----+-----+-----+------| 918 | 5.7. | Ignore port copy | O | O | O | O | O | O | 919 |-------+-------------------------+-----+-----+-----+-----+-----+------| 920 | 6. | DATA EXPORT | 921 |-------+-------------------------+-----+-----+-----+-----+-----+------| 922 | 6.1. | INFORMATION MODEL | 923 |-------+-------------------------+-----+-----+-----+-----+-----+------| 924 | 6.1. | IP Version | - | M | M | O | O | M | 925 |-------+-------------------------+-----+-----+-----+-----+-----+------| 926 | 6.1. | src/dst address | M | M | M | M | M | M | 927 |-------+-------------------------+-----+-----+-----+-----+-----+------| 928 | 6.1. | transport protocol | M | M | - | M | M | M | 929 |-------+-------------------------+-----+-----+-----+-----+-----+------| 930 | 6.1. | src/dst transport | M | M | - | M | M | M | 931 |-------+-------------------------+-----+-----+-----+-----+-----+------| 932 | 6.1. | Packet counter (h) | S | M | M | S | S | M | 933 |-------+-------------------------+-----+-----+-----+-----+-----+------| 934 | 6.1. | Byte counter | M | M | M | S | S | M | 935 |-------+-------------------------+-----+-----+-----+-----+-----+------| 936 | Sect. | Requirement | A | B | C | D | E | IPFIX| 937 |-------+-------------------------+-----+-----+-----+-----+-----+------| 938 | 6.1. | Dropped Packet | O | M | M | S | M | M | 939 | | Counter (h,i) | | | | | | | 940 |-------+-------------------------+-----+-----+-----+-----+-----+------| 941 | 6.1. | ToS Byte | M | S | M | O | M | M | 942 |-------+-------------------------+-----+-----+-----+-----+-----+------| 943 | 6.1. | Flow Label | M | S | M | O | M | M | 944 |-------+-------------------------+-----+-----+-----+-----+-----+------| 945 | 6.1. | BGP AS# | - | S | M | - | - | M | 946 |-------+-------------------------+-----+-----+-----+-----+-----+------| 947 | 6.1. | MPLS label (a) | S | S | M | O | S | M | 948 | | | | | (c) | | | | 949 |-------+-------------------------+-----+-----+-----+-----+-----+------| 950 | 6.1. | DSCP (a) | M | S | M | O | M | M | 951 |-------+-------------------------+-----+-----+-----+-----+-----+------| 952 | 6.1. | Timestamps for | M | O | O | S | S | M | 953 | | first/last packet | | | | | | | 954 |-------+-------------------------+-----+-----+-----+-----+-----+------| 955 | 6.1. | Sampling methods | M | M | M | M | M | M | 956 | | & parameters (k) | | | | | | | 957 |-------+-------------------------+-----+-----+-----+-----+-----+------| 958 | 6.1. | observation point | M | M | M | M | M | M | 959 | | identifier | | | | | | | 960 |-------+-------------------------+-----+-----+-----+-----+-----+------| 961 | 6.1. | measuring device | M | M | M | M | M | M | 962 | | identity | | | | | | | 963 |-------+-------------------------+-----+-----+-----+-----+-----+------| 964 | 6.1. | TTL | O | O | O | O | O | O | 965 |-------+-------------------------+-----+-----+-----+-----+-----+------| 966 | 6.1. | IP header flags | - | O | O | O | O | O | 967 |-------+-------------------------+-----+-----+-----+-----+-----+------| 968 | 6.1. | TCP header flags | - | O | O | O | - | O | 969 |-------+-------------------------+-----+-----+-----+-----+-----+------| 970 | 6.1. | Fragment counter | - | O | O | O | O | O | 971 |-------+-------------------------+-----+-----+-----+-----+-----+------| 972 | 6.1. | Multicast | O | O | O | - | - | O | 973 | | replication factor | | | | | | | 974 |-------+-------------------------+-----+-----+-----+-----+-----+------| 975 | 6.1. | Flow configuration | O | O | O | O | O | O | 976 |-------+-------------------------+-----+-----+-----+-----+-----+------| 977 | 6.2. | DATA MODEL | 978 |-------+-------------------------+-----+-----+-----+-----+-----+------| 979 | 6.2. | Flexibility | O | O | O | O | O | O | 980 |-------+-------------------------+-----+-----+-----+-----+-----+------| 981 | 6.2. | Extensibility | M | M | M | M | M | M | 982 |-------+-------------------------+-----+-----+-----+-----+-----+------| 983 | Sect. | Requirement | A | B | C | D | E | IPFIX| 984 |-------+-------------------------+-----+-----+-----+-----+-----+------| 985 | 6.3. | DATA TRANSFER | 986 |-------+-------------------------+-----+-----+-----+-----+-----+------| 987 | 6.3.1.| Congestion aware | M | M | M | M | M | M | 988 |-------+-------------------------+-----+-----+-----+-----+-----+------| 989 | 6.3.2.| Reliability | M | S | S | S | S | M | 990 |-------+-------------------------+-----+-----+-----+-----+-----+------| 991 | 6.3.3.| Confidentiality | S | S | S | S | S | S | 992 |-------+-------------------------+-----+-----+-----+-----+-----+------| 993 | 6.3.4.| Integrity | M | M | M | M | M | M | 994 |-------+-------------------------+-----+-----+-----+-----+-----+------| 995 | 6.3.5.| Authenticity | M | M | M | M | M | M | 996 |-------+-------------------------+-----+-----+-----+-----+-----+------| 997 | 6.4. | REPORTING TIMES | 998 |-------+-------------------------+-----+-----+-----+-----+-----+------| 999 | 6.4. | Push mode | M | O | O | M | S | M | 1000 | | | | (e) | (e) | |(e,f)| | 1001 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1002 | 6.4. | Pull mode | O | O | O | O | O | O | 1003 | | | | (e) | (e) | | (e) | | 1004 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1005 | 6.4.1.| Regular Interval | S | S | S | S | S | S | 1006 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1007 | 6.6. | Notifications | O | O | O | O | O | O | 1008 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1009 | 6.7. | Anonymization | O | O | O | O | O | O | 1010 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1011 | 7. | CONFIGURATION | 1012 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1013 | 7. | Config Measurement | M | M | M | M | M | M | 1014 | | & Data Export | | | | | | | 1015 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1016 | 7. | Config Observation Point| S | S | S | S | S | S | 1017 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1018 | 7. | Config Flow | S | S | S | S | S | S | 1019 | | Specifications | | | | | | | 1020 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1021 | 7. | Config Report | S | S | S | S | S | S | 1022 | | Data Format | | | | | | | 1023 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1024 | 7. | Config Flow Timeouts | S | S | S | S | O | S | 1025 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1026 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1027 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1028 | 7. | Config | O | O | O | O | O | O | 1029 | | Notifications | | | | | | | 1030 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1031 | 7. | Config Sampling | O | O | O | O | O | O | 1032 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1033 | 7. | Config Anonymization | O | O | O | O | O | O | 1034 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1035 | 7. | Config Security | O | O | O | O | O | O | 1036 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1037 | 8. | GENERAL REQUIREMENTS | 1038 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1039 | 8.1. | Openness | S | S | S | S | S | S | 1040 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1041 | 8.2. | Scalability: | | | | | | | 1042 | | data collection | M | S | M | O | S | M | 1043 | | from hundreds of | | | | | | | 1044 | | measurement devices | | | | | | | 1045 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1046 | 8.3. | Several Collectors | O | O | O | O | O | O | 1047 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1049 Remarks: 1050 (a) If feature is supported. 1051 (b) The differentiation of IPv4 and IPv6 is for TE of importance. 1052 So we tended to make this a MUST. Nevertheless, a SHOULD seems 1053 to be sufficient to perform most TE tasks and allows us to have 1054 a SHOULD for IPFIX instead of a MUST. 1055 (c) For TE in an MPLS network the label is essential. Therefore a 1056 MUST is given here leading to a MUST in IPFIX. 1057 (d) Precise time-based accounting requires reaction to a flow 1058 timeout. 1059 (e) Either push or pull has to be supported. 1060 (f) Required, in order to immediately report drop indications for 1061 SLA validation. 1062 (g) If sampling is supported the parameters and methods MUST be 1063 well defined. 1064 (h) If a packet is fragmented, each fragment is counted as an 1065 individual packet. 1066 (i) Only if measurement is done on data path i.e. has access to 1067 forwarding decision. 1068 (k) If sampling is used.