idnits 2.17.1 draft-ietf-ipfix-reqs-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: ---------------------------------------------------------------------------- ** 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 743 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 (March 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 777, 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 March 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 A metering process is a set of actions performed on packets observed 152 at an observation point in order to map them to a flow. A metering 153 process can include functions for timestamping, classification and 154 sampling of packets. Typically, the metering process also includes 155 maintainance of flow records, computation of flow statistics, and 156 detection of flow expiration. 158 2.4. Flow Record 160 A flow record contains information about a specific flow that was 161 metered at an observation point. A flow record contains measured 162 properties of the flow (e.g. the total number of bytes of all packets 163 of the flow) and usually characteristic properties of the flow (e.g. 164 source IP address). 166 2.5. Export Process 168 The export process sends flow records to one or more collectors. 170 2.6. Collector 172 The collector receives flow records from one or more export 173 processes. The collector might process or store received flow 174 record, but these actions are out of the scope of this document. 176 2.7. IPFIX device 178 A device hosting at least a flow information export process. 179 Typically, corresponding Observation points, metering processes, and 180 export processes are co-located at this device, for example at a 181 router. 183 3. Applications Requiring IP Flow Information Export 185 The following list contains a selection of applications requiring IP 186 flow information export. Because requirements for flow export listed 187 in further sections below are derived from these applications, their 188 selection is crucial. The goal of this requirements document is not 189 to cover all possible applications with all their flow export 190 requirements, but to cover applications which are considered to be of 191 significant importance in today's or future IP networks, and for 192 which requirements can be met with reasonable technical effort. 194 Please note, that the described applications can have a large number 195 of differing implementations. Requirement details or the weighting of 196 requirements could differ for specific implementations. Therefore we 197 derive the requirements from the general functionality of the 198 selected applications. Furthermore, the list of applications should 199 lead to a better understanding of the requirements which is 200 particularly important when designing or implementing a traffic flow 201 measuring device. 203 3.1 Usage-based Accounting 205 Several new business models for selling IP service and IP-based 206 services are currently under investigation. Beyond flat rate services 207 which do not need accounting, accounting for these models can be 208 based on time or volume. Accounting data can serve as input for 209 billing systems. Accounting can be performed per user or per user 210 group, it can be performed just for basic IP service or individually 211 per high-level service and/or per content type delivered. For 212 advanced/future services, accounting may also be performed per class 213 of service, per application, per time of day, per used (label 214 switched) path, etc. 216 3.2 Traffic Profiling 218 Traffic profiling is a process of characterizing IP flows and flow 219 aggregates by using a model that represents key parameters of the 220 flow such as flow duration, volume, time and burstiness. It is a 221 prerequisite for network planning, network dimensioning, trend 222 analysis, developing business models, and other activities. It 223 heavily depends on the particular traffic profiling objective(s) what 224 statistics and accuracy are required from the measurements. Typical 225 information needed for traffic profiling are the distribution of used 226 services and protocols in the network, the amount of packets of a 227 specific type (e.g. percentage of IPv6 packets) and specific flow 228 profiles. 230 Since objectives for traffic profiling can vary, this application 231 requires a high flexibility of the measurement infrastructure, 232 especially regarding the options for measurement configuration and 233 packet classification. 235 3.3 Traffic Engineering 237 Traffic Engineering (TE) comprises methods for measurement, modeling, 238 characterization and control of a network. The goal of TE is the 239 optimization of network resource utilization and traffic performance 240 [RFC2702]. Since control and administrative reaction to measurement 241 results requires access to the involved network nodes, TE mechanisms 242 and the required measurement function usually are performed within 243 one administrative domain. Typical parameters required for TE are 244 link utilization, load between specific network nodes, number, size 245 and entry/exit points of the active flows and routing information. 247 3.4 Attack/Intrusion Detection 249 Capturing of flow information plays an important role for network 250 security, both for detection of security violation, and for 251 subsequent defense. In case of a Denial of Service (DOS) attack, flow 252 monitoring can allow detection of unusual load situations or 253 suspicious flows. In a second step, flow analysis can be performed in 254 order to gather information about the attacking flows, and for 255 deriving a defense strategy. 257 Intrusion detection is a potentially more demanding application which 258 would not only look at specific characteristics of flows, but that 259 may also use a stateful packet flow analysis for detecting specific, 260 suspicious activities, or unusually frequent activities. Such 261 activities may be characterized by specific communication patterns, 262 detectable by characteristic sequences of certain packet types. 264 3.5 QoS Monitoring 266 QoS monitoring is the non-intrusive (passive) measurement of quality 267 parameters for single flows or traffic aggregates. In contrast to 268 intrusive (active) measurements, non-intrusive measurements utilize 269 the existing traffic in the network for QoS analysis. Since no test 270 traffic is sent, non-intrusive measurements can only be applied in 271 situations where the traffic of interest is already present in the 272 network. One example application is the validation of QoS parameters 273 negotiated in a service level specification (SLS). 275 Non-intrusive measurements cannot provide the kind of controllable 276 experiments that can be achieved with active measurements. On the 277 other hand non-intrusive measurements do not suffer from undesired 278 side effects caused by sending test traffic (e.g. additional load, 279 potential differences in treatment of test traffic and real customer 280 traffic) 282 QoS monitoring often requires the correlation of data from multiple 283 measurement instances (e.g. for measuring one-way metrics). This 284 requires proper clock synchronization of the involved measurement 285 instances. For some measurements packet events at the different 286 measurement points must be correlated. For this, the provisioning of 287 post-processing functions (e.g. the generation of packet IDs) at the 288 measurement instances would be useful. Furthermore, QoS monitoring 289 can lead to a huge amount of measurement result data. Therefore it 290 would highly benefit from mechanisms to reduce the measurement data, 291 like aggregation of results and flow sampling. 293 4. Distinguishing Flows 295 Packets are mapped to flows by evaluating their properties. Packets 296 with common properties are considered to belong to the same flow. A 297 packet showing at least one difference in the set of properties is 298 considered to belong to a different flow. 300 The following subsections list a set of properties which a metering 301 process MUST, SHOULD, or MAY be able to evaluate for mapping packets 302 to flows. Please note that requiring the ability to evaluate a 303 certain property does not imply that this property must be evaluated 304 for each packet. 306 In other words, compliant with IPFIX means that the metering process 307 in general must be able, via its configuration, to somehow support to 308 distinguish flows via all the MUST fields, even if in certain 309 circumstance/for certain applications, only a subset of the MUST 310 fields is needed and only a subset of the MUST fields is effectively 311 used to distinguish flows. 313 Which combination of properties is evaluated for a particular 314 measurement and how these properties are evaluated depends on the 315 configuration of the IPFIX device. The configured choice of 316 evaluated properties strongly depends on the environment and purpose 317 of the measurement and on the information required by the collector. 319 For specific deployments, only a subset of the REQUIRED properties 320 listed below could be used to distinguish flows, in order to 321 aggregate the flow records and reduce the number of flow records 322 exported. On the other hand, some other deployments will require to 323 distinguish flows by some extra parameters, like for example the TTL 324 field of the IP header or the BGP Autonomous Systems. 326 4.1. Interfaces 328 The metering process MUST be able to separate flows by the incoming 329 interface or by the outgoing interface or by both of them. 331 4.2. IP Header Fields 333 The metering process MUST, SHOULD, or MAY be able to separate flows 334 by the following fields of the IP header as indicated. 336 1. source IP address (MUST) 337 2. destination IP address (MUST) 338 3. transport protocol type (TCP,UDP,ICMP,...) (MUST) 339 4. IP version number (SHOULD) 340 This requirement only applies if the device is supporting 341 more than one version of IP. 343 For source address and destination address separating by full match 344 MUST be supported as well as separation by a partial match (for 345 example subnet masking). 347 4.3. Transport Header Fields 349 The metering process MUST be able to separate flows by the port 350 numbers of the transport header in case of TCP or UDP being used as 351 transport protocol. Both, source and destination port number MUST be 352 supported for distinguishing flows, individually as well as in 353 combination. 355 4.4. MPLS Label 357 If the metering process supports Multiprotocol Label Switching (MPLS, 358 see [RFC3031]), then the measuring device MUST be able to separate 359 flows by the MPLS label. 361 4.5. DiffServ Code Point 363 If the IPFIX device supports Differentiated Services (DiffServ) then 364 the metering process MUST be able to separate flows by the DiffServ 365 Code Point (DSCP, see [RFC2474]). 367 4.6. Header Compression and Encryption 369 If header compression or encryption is used, the metering process 370 might not be able to access all header fields. In such a case only 371 observation points at end points of header compression or of packet 372 encryption are expected to meet the requirements stated in this 373 section 4. 375 5. Metering Process 377 The following are requirements for the metering process. All 378 measurements MUST be conducted from the point of view of the 379 observation point. 381 5.1. Reliability 383 The metering process MUST either be reliable or missing reliability 384 MUST be known and indicated. The metering process is reliable, if 385 each packet passing the observation point is measured according to 386 the configuration of the metering process. If, e.g. due to some 387 overload, not all passing packets can be included into the metering 388 process, then the metering process MUST be able to detect this 389 failure and to report about it. 391 5.2. Sampling 393 The metering process MAY support measuring traffic by packet 394 sampling. If sampling is supported the sampling method and its 395 parameters MUST be well defined. If sampling parameters are changed 396 during operation, this MUST be indicated to all collectors receiving 397 the affected flow records. 399 5.3. Overload Behavior 401 In case of an overload, e. g. lack of memory or processing power, the 402 metering process MAY change in order to cope with the lack of 403 resources. Possible reactions include: 405 - Reduce the number of flow accounts. This can be achieved by more 406 coarse grained flow measurement or by a restriction of the flow 407 accounts to a subset of the set of original ones. 408 - Switch to sampling packets before they are processed by the 409 meter or - if sampling is already performed - reduce the 410 sampling rate. 411 - Stop metering. 413 Overload behavior is not restricted to the three options listed 414 above. But in any case, the overload behavior MUST be clearly defined 415 and the collector MUST be able to distinguish the flow records 416 exported before and after the metering process behavior change. 418 For example in the case of switching to sampling, the collector MUST 419 be able to distinguish the flow records generated with sampling from 420 the flow records generated without sampling and the sampling method 421 and all its parameters MUST be known or indicated. 423 5.4. Timestamps 425 The metering process MUST be able to generate a timestamp for each 426 observed packet. Please note that section 5.1 requires to offer 427 reporting a timestamp for the first and the last observed packet of a 428 flow. Therefore, the metering process MUST be able to store at least 429 two timestamps per flow. 431 5.5. Time Synchronization 433 Different metering process(es) and collector(s) SHOULD be time 434 synchronized between each other. Using NTP or GPS are possible ways 435 of achieving this. Selecting and deploying a method for time 436 synchronization is not in the scope of IPFIX. 438 5.6. Timeout 440 The metering process MUST be able to detect flow timeout. A flow is 441 considered to be timed out if no packet of this flow has been 442 observed for a given timeout interval. The metering process MAY 443 support means for detecting the end of a flow before a time out 444 occurs, for example by detecting the FIN or RST bits in a TCP 445 connection. 447 5.7. Ignore Port Copy 449 The metering process MAY be able to ignore packets which are 450 generated by a port copy function acting at the same device. 452 6. Data Export 454 The following are requirements for exporting measured flow data out 455 of the IPFIX device. Beside requirements on the data transfer, we 456 separate requirements concerning the information model from 457 requirements concerning the data model. Furthermore, we list 458 requirements on reporting times and events and on anonymization of 459 records. 461 6.1. Information Model 463 The information model for the flow information export is the list of 464 attributes of a flow to be contained in the report (including the 465 semantics of the attributes). 467 This section lists attributes an export process MUST or MAY be able 468 to report. This does not imply that a exported flow records MUST 469 contain all REQUIRED attributes, but that it MUST be possible to 470 configure the device in a way that all of the REQUIRED attributes are 471 contained in the flow records for each measured flow. 473 In other words, compliant with IPFIX means that the box in general 474 must be able, via its configuration, to somehow support to report all 475 the MUST fields, even if in certain circumstance/for certain 476 applications, only a subset of the MUST fields is needed and only a 477 subset of the MUST fields is effectively reported. 479 Beyond that, the device might offer to report also further attributes 480 not mentioned here. A particular flow record may contain some of the 481 "REQUIRED" attributes as well as some additional ones, for example 482 covering future technologies. 484 The measuring device MUST be able to report the following attributes 485 for each measured flow: 487 1. IP version number 488 This requirement only applies if the device is supporting more 489 than one version of IP. 490 2. source IP address 491 3. destination IP address 492 4. transport protocol type 493 5. source TCP/UDP port number 494 6. destination TCP/UDP port number 495 7. packet counter 496 If a packet is fragmented, each fragment is counted as an 497 individual packet. 498 8. byte counter 499 9. in case of IPv4: Type of Service 500 10. in case of IPv6: Flow Label 501 11. if BGP is supported: BGP AS# 502 12. if MPLS is supported: MPLS label 503 13. if DiffServ is supported: DSCP 504 14. timestamp of the first packet observed 505 15. timestamp of the last packet observed 506 16. if sampling is used: sampling method 507 17. if sampling is used: sampling parameters 508 18. unique identifier of the observation point 509 19. unique identifier of the export process 511 The measuring device MAY be able to report the following attributes 512 for each measured flow: 513 20. Time To Live 514 21. IP header flags 515 22. TCP header flags 516 23. dropped packet counter 517 If a packet is fragmented, each fragment MUST be counted as an 518 individual packet. This requirements does not apply to probes where 519 the value of this counter is always zero. 520 24. fragmented packet counter 521 counter of all packets for which the fragmented bit is set in 522 the IP header 523 25. multicast replication factor 524 the number of outgoing packets originating from a single 525 incoming multicast packet 527 6.2 Data Model 529 The data model describes how information is represented in flow 530 records. The data model used for exporting flow information MAY be 531 flexible concerning the flow attributes contained in flow records. A 532 flexible record format would offer the possibility of defining 533 records in a flexible (customizable) way regarding the number and 534 type of contained attributes. 536 The data model MUST be extensible for future attributes to be added. 537 Even if a set of attributes is fixed in the flow record, the data 538 model MUST provide a way of extending the record by configuration or 539 for certain implementations. 541 The Data Model SHOULD be independent of the underlying transport 542 protocol, i.e. the data transfer. 544 6.3. Data Transfer 546 Requirements for the data transfer include reliability and security 547 requirements. These requirements do not apply to the measuring device 548 alone, but also to the transport network. Consequently, the export 549 process does not necessarily have to guarantee that all requirements 550 are met. Particularly if the security requirements are already 551 guaranteed by the network used for data transfer, then these 552 requirements do not have to be considered anymore by the export 553 process. Therefore, these requirements are OPTIONAL for the export 554 process, although they may be REQUIRED for the data transfer as 555 specified in the appendix. 557 6.3.1. Congestion Awareness 559 For the data transfer a congestion aware protocol MUST be supported. 561 6.3.2. Reliability 563 Absence of reliability of the data transfer MUST be indicated 564 covering packet loss and packet reordering. 566 Please note that if an unreliable transport protocol is used, 567 reliability can be provided by higher layers. In such a case only 568 lack of overall reliability MUST be indicated. For example reordering 569 could be dealt with by adding a sequence number to each packet. 571 6.3.3. Security 573 Confidentiality of transferred IPFIX data SHOULD be ensured. 575 Integrity of transferred IPFIX data MUST be ensured. 577 Authenticity of transferred IPFIX data MUST be ensured. 579 6.4. Push and Pull Mode Reporting 581 In general, there are two ways of deciding on reporting times: push 582 mode and pull mode. In push mode, the export process decides without 583 an external trigger on when to send a report on measured flows. In 584 pull mode, sending a report is triggered by an explicit request from 585 a collector. The measuring device MUST support push mode reporting, 586 it MAY support pull mode reporting. 588 6.5. Regular Reporting Interval 590 The export process SHOULD be capable of reporting measured traffic 591 data regularly according to a given interval length. 593 6.6. Notification on Specific Events 595 The export process MAY be capable of sending notifications to a 596 consumer of measure data, if a specific event occurs. Such an event 597 might be the arrival of the first packet of a new flow, or the 598 termination of a flow after flow timeout. 600 6.7. Anonymization 602 The export process MAY be capable of anonymizing source and 603 destination IP addresses in flow data before exporting them. It MAY 604 support anonymization of port numbers and other fields. Please note 605 that anonymization is not originally an application requirement, but 606 derived from general requirements for treatment of traffic within a 607 network. 609 7. Configuration 611 The IPFIX device MUST provide a way of configuring the traffic 612 measurement and the traffic data export. The following parameters 613 SHOULD be configurable: 615 1. specification of the observation point, e.g. a list of 616 interfaces to be monitored. 617 2. specifications of flows to be measured 618 3. reporting data format 619 Specifying the reporting data format SHOULD include a selection 620 of attributes to be reported for each flow. 621 4. flow timeouts 623 The following parameters MAY be configurable: 625 5. notifications 626 6. sampling method and parameters, if feature is supported 627 7. flow anonymization, if feature is supported 629 If configuration is done remotely, the IPFIX device SHOULD support 630 security of the configuration including confidentiality, integrity 631 and authenticity. The means used for remote configuration of IPFIX 632 devices are out of the scope of this document. 634 8. General Requirements 636 8.1. Openness 638 IPFIX specifications SHOULD be open to future technologies. This 639 includes extensibility of configuration of measurement and reporting 640 as well as extensibility of the reporting information model and data 641 model. 643 8.2. Scalability concerning measuring devices 645 Data collection from hundreds of different IPFIX devices MUST be 646 supported. The collector MUST be able to distinguish several hundred 647 IPFIX devices by their identifiers. 649 8.3. Several Collectors 651 The exporting process MAY be able to export flow information to more 652 than one collector. 654 9. Security Considerations 656 This document describes requirements for IP Flow Information Export 657 (IPFIX). It therefore also states the required security features for 658 a future IPFIX protocol. Nevertheless, the suggestion of solutions 659 for achieving the security properties is out of scope of this 660 document and will be part of future IPFIX documents that specify 661 IPFIX architecture and protocol. 663 Like other requirements, the security requirements differ for the 664 considered applications. The incentive to modify collected for 665 accounting or intrusion detection for instance is usually higher than 666 the incentive to change data collected for traffic profiling. 667 Therefore the required security features are listed per application. 668 Furthermore, the security requirements also differ with regard to the 669 environment in which an IPFIX protocol is used (e.g. intra- or inter- 670 domain). Some of these issues are part of the IPFIX architecture and 671 with this out of scope of this document. Therefore this document also 672 tries to consider security threats that can only occur in an insecure 673 environment (e.g. where it can not be excluded, that an attacker 674 might gain access to the network). 676 Several security hazards also occur if the IPFIX device is configured 677 remotely (e.g. access to the measurement process, forgery of 678 configuration information, etc.). Nevertheless, this document 679 specifies only what parameters SHOULD or MAY be configurable for the 680 IPFIX device. It does not deal with requirements for a protocol for 681 measurement configuration. Therefore security considerations 682 regarding the measurement configuration are out of scope of this 683 document. 685 The following potential security hazards for an IPFIX protocol can be 686 identified: 688 - Disclosure of IP flow information data 689 It may be required to keep measurement records confidential 690 between the involved parties. Observation of IP flow 691 information data gives an attacker information about the active 692 flows in the network, communication endpoints and traffic 693 patterns. This information can not only be used to spy out user 694 behavior but also to plan and conceal future attacks. Therefore 695 the requirements document recommends to ensure the 696 confidentiality of the transferred data. This can be done for 697 instance by encryption. 699 Furthermore, features for anonymization may be provided by the 700 future IPFIX protocol. With this communication endpoints can be 701 kept confidential. Anonymization is also a useful feature to 702 allow measurements (e.g. by a third party) without violating 703 privacy protection. 705 - Forgery of exported IP flow information data 706 Especially for applications like accounting or intrusion 707 detection there are strong incentives (e.g. save money or 708 prevent detection of an attack) to forge exported IP flow 709 information records. This can be done either by altering data 710 on the path or by exporting records from a device that pretends 711 to be the IPFIX device. In order to make the IPFIX protocol 712 resistant against such attacks this document requires to ensure 713 authenticity and integrity of the data for the IPFIX data 714 transfer. 716 Special caution is required if security applications rely on 717 IPFIX data With forgery of exported IP flow information data it 718 is possible to trick on security applications. With this it can 719 be for instance possible to pretend that a DoS attack happens 720 without even launching a real attack. 722 - Denial of Service (DoS) attacks 723 DoS attacks on routers or other middleboxes that have the IPFIX 724 protocol implemented would also affect the IPFIX protocol and 725 impair the sending of IPFIX records. Nevertheless, since such 726 hazards are not induced specifically by the IPFIX protocol the 727 prevention of such attacks is out of scope of this document. 729 IPFIX itself causes the following potential hazards for DoS 730 attacks. It is always possible to overload the IPFIX device if 731 it expects the reception of traffic. For IPFIX this can occur 732 in two cases. First, if the protocol supports the pull mode 733 (which is one option in this document) and expects requests. 734 Secondly, if data is expected for remote measurement 735 configuration. The first case could be prevented by ensuring 736 authenticity for IPFIX requests. The second case should be 737 addressed for the specification of an IPFIX remote 738 configuration mechanism and therefore is out of scope of this 739 document. 741 Also IPFIX collectors can become target of an DoS attack. This 742 can be done by sending IPFIX data from a malicious device that 743 pretends to be an IPFIX device. This can be prevented by 744 ensuring authenticity of IPFIX data as stated in this document. 745 It is also possible that collectors are flooded with IPFIX 746 record from an authorized IPFIX devices for which the 747 configuration was altered. Furthermore, malicious configuration 748 or forgery of exported data can cause a loss or re-direction of 749 flow information (e.g. if destination addresses for flow 750 records are modified). This can lead to a disruption of upper 751 layer services (accounting, intrusion detection, etc.) due to 752 lack of IPFIX records. This can be prevented by controlling 753 configuration access and by ensuring the integrity of exported 754 data. 756 10. Acknowledgments 758 We like to thank all the people contributing to the requirements 759 discussion on the mailing list for a lot of valuable comments. 761 11. References 763 [MIDBOXTAX] B. Carpenter, "Middleboxes: taxonomy and issues", 764 RFC 3234, February 2002. 766 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 767 Switching Architecture", RFC 3031, January 2001. 769 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition 770 of the Differentiated Services Field (DS Field) in the IPv4 771 and IPv6 Headers", RFC 2474, December 1998. 773 [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 774 "Requirements for Traffic Engineering Over MPLS", 775 RFC 2702, September 1999. 777 [RFC2274] U. Blumenthal, B. Wijnen "User-based Security Model (USM) 778 for version 3 of the Simple Network Management Protocol 779 (SNMPv3), RFC 2274, January 1998. 781 12. List of Authors 783 Juergen Quittek 784 NEC Europe Ltd., Network Laboratories 785 Adenauerplatz 6 786 69115 Heidelberg 787 Germany 789 Phone: +49 6221 90511-15 790 EMail: quittek@ccrle.nec.de 792 Tanja Zseby 793 Fraunhofer Institute for Open Communication Systems (FOKUS) 794 Kaiserin-Augusta-Allee 31 795 10589 Berlin 796 Germany 798 Phone: +49 30 3463 7153 799 Email: zseby@fokus.fhg.de 801 Georg Carle 802 Fraunhofer Institute for Open Communication Systems (FOKUS) 803 Kaiserin-Augusta-Allee 31 804 10589 Berlin 805 Germany 807 Phone: +49 30 3463 7149 808 Email: carle@fokus.fhg.de 810 Sebastian Zander 811 Fraunhofer Institute for Open Communication Systems (FOKUS) 812 Kaiserin-Augusta-Allee 31 813 10589 Berlin 814 Germany 816 Phone: +49 30 3463 7287 817 Email: zander@fokus.fhg.de 818 Benoit Claise 819 Cisco Systems 820 De Kleetlaan 6a b1 821 1831 Diegem 822 Belgium 824 Phone: +32 2 704 5622 825 Email: bclaise@cisco.com 827 K.C. Norseth 828 Enterasys Networks 829 2691 S. Decker Lake Lane 830 Salt Lake City, Utah 84119 831 USA 833 Phone: +1 801 887 9823 834 Email: knorseth@enterasys.com 836 Appendix: Derivation of Requirements form Target Applications 838 The following table documents, how the requirements stated in 839 sections 3-7 are derived from requirements of the applications listed 840 in section 2. 842 Used abbreviations: 843 M = MUST 844 S = SHOULD 845 O = MAY (OPTIONAL) 846 - = DONT CARE 848 -----------------------------------------------------------------------. 849 IPFIX | 850 ----------------------------------------------------------------. | 851 E: QoS Monitoring | | 852 ----------------------------------------------------------. | | 853 D: Attack/Intrusion Detection | | | 854 ----------------------------------------------------. | | | 855 C: Traffic Engineering | | | | 856 ----------------------------------------------. | | | | 857 B: Traffic Profiling | | | | | 858 ----------------------------------------. | | | | | 859 A: Usage-based Accounting | | | | | | 860 ----------------------------------. | | | | | | 861 | | | | | | | 862 | Sect. | Requirement | A | B | C | D | E | IPFIX| 863 |-------+-------------------------+-----+-----+-----+-----+-----+------| 864 | 4. | DISTINGUISHING FLOWS | 865 |-------+-------------------------+-----+-----+-----+-----+-----+------| 866 | 4. | Combination of | M | M | M | M | M | M | 867 | | required attributes | | | | | | | 868 |-------+-------------------------+-----+-----+-----+-----+-----+------| 869 | 4.1. | in/out IF | S | M | M | S | S | M | 870 |-------+-------------------------+-----+-----+-----+-----+-----+------| 871 | 4.2. | src/dst address | M | M | M | M | M | M | 872 |-------+-------------------------+-----+-----+-----+-----+-----+------| 873 | 4.2. | Masking of IP adresses | M | M | M | M | M | M | 874 |-------+-------------------------+-----+-----+-----+-----+-----+------| 875 | 4.2. | transport protocol | M | M | - | M | M | M | 876 |-------+-------------------------+-----+-----+-----+-----+-----+------| 877 | 4.2. | version field | - | S | S | O | O | S | 878 | | | | | (b) | | | | 879 |-------+-------------------------+-----+-----+-----+-----+-----+------| 880 | 4.3. | src/dst port | M | M | - | M | M | M | 881 |-------+-------------------------+-----+-----+-----+-----+-----+------| 882 | Sect. | Requirement | A | B | C | D | E | IPFIX| 883 |-------+-------------------------+-----+-----+-----+-----+-----+------| 884 | 4.4. | MPLS label (a) | S | S | M | O | S | M | 885 | | | | | (c) | | | | 886 |-------+-------------------------+-----+-----+-----+-----+-----+------| 887 | 4.5. | DSCP (a) | M | S | M | O | M | M | 888 |-------+-------------------------+-----+-----+-----+-----+-----+------| 889 | 5. | METERING PROCESS | 890 |-------+-------------------------+-----+-----+-----+-----+-----+------| 891 | 5.1. | Reliability | M | S | S | S | S | | 892 |-------+-------------------------+-----+-----+-----+-----+-----+ M | 893 | 5.1. | Indication of | - | M | M | M | M | | 894 | | missing reliability | | | | | | | 895 |-------+-------------------------+-----+-----+-----+-----+-----+------| 896 | 5.2. | Sampling (g) | O | O | O | O | O | O | 897 |-------+-------------------------+-----+-----+-----+-----+-----+------| 898 | 5.2. | Dynamic sampling | O | O | O | O | O | O | 899 |-------+-------------------------+-----+-----+-----+-----+-----+------| 900 | 5.4. | Timestamping at | M | O | O | S | M | M | 901 | | measurement device | | | | | | | 902 |-------+-------------------------+-----+-----+-----+-----+-----+------| 903 | 5.5. | Time synchronization | S | S | S | S | S | S | 904 |-------+-------------------------+-----+-----+-----+-----+-----+------| 905 | 5.6. | Flow timeout | M | S | - | O | O | M | 906 | | | (d) | | | | | | 907 |-------+-------------------------+-----+-----+-----+-----+-----+------| 908 | 5.7. | Ignore port copy | O | O | O | O | O | O | 909 |-------+-------------------------+-----+-----+-----+-----+-----+------| 910 | 6. | DATA EXPORT | 911 |-------+-------------------------+-----+-----+-----+-----+-----+------| 912 | 6.1. | INFORMATION MODEL | 913 |-------+-------------------------+-----+-----+-----+-----+-----+------| 914 | 6.1. | IP Version | - | M | M | O | O | M | 915 |-------+-------------------------+-----+-----+-----+-----+-----+------| 916 | 6.1. | src/dst address | M | M | M | M | M | M | 917 |-------+-------------------------+-----+-----+-----+-----+-----+------| 918 | 6.1. | transport protocol | M | M | - | M | M | M | 919 |-------+-------------------------+-----+-----+-----+-----+-----+------| 920 | 6.1. | src/dst transport | M | M | - | M | M | M | 921 |-------+-------------------------+-----+-----+-----+-----+-----+------| 922 | 6.1. | Packet counter (h) | S | M | M | S | S | M | 923 |-------+-------------------------+-----+-----+-----+-----+-----+------| 924 | 6.1. | Byte counter | M | M | M | S | S | M | 925 |-------+-------------------------+-----+-----+-----+-----+-----+------| 926 | Sect. | Requirement | A | B | C | D | E | IPFIX| 927 |-------+-------------------------+-----+-----+-----+-----+-----+------| 928 | 6.1. | Dropped Packet | O | M | M | S | M | M | 929 | | Counter (h,i) | | | | | | | 930 |-------+-------------------------+-----+-----+-----+-----+-----+------| 931 | 6.1. | ToS Byte | M | S | M | O | M | M | 932 |-------+-------------------------+-----+-----+-----+-----+-----+------| 933 | 6.1. | Flow Label | M | S | M | O | M | M | 934 |-------+-------------------------+-----+-----+-----+-----+-----+------| 935 | 6.1. | BGP AS# | - | S | M | - | - | M | 936 |-------+-------------------------+-----+-----+-----+-----+-----+------| 937 | 6.1. | MPLS label (a) | S | S | M | O | S | M | 938 | | | | | (c) | | | | 939 |-------+-------------------------+-----+-----+-----+-----+-----+------| 940 | 6.1. | DSCP (a) | M | S | M | O | M | M | 941 |-------+-------------------------+-----+-----+-----+-----+-----+------| 942 | 6.1. | Timestamps for | M | O | O | S | S | M | 943 | | first/last packet | | | | | | | 944 |-------+-------------------------+-----+-----+-----+-----+-----+------| 945 | 6.1. | Sampling methods | M | M | M | M | M | M | 946 | | & parameters (k) | | | | | | | 947 |-------+-------------------------+-----+-----+-----+-----+-----+------| 948 | 6.1. | observation point | M | M | M | M | M | M | 949 | | identifier | | | | | | | 950 |-------+-------------------------+-----+-----+-----+-----+-----+------| 951 | 6.1. | measuring device | M | M | M | M | M | M | 952 | | identity | | | | | | | 953 |-------+-------------------------+-----+-----+-----+-----+-----+------| 954 | 6.1. | TTL | O | O | O | O | O | O | 955 |-------+-------------------------+-----+-----+-----+-----+-----+------| 956 | 6.1. | IP header flags | - | O | O | O | O | O | 957 |-------+-------------------------+-----+-----+-----+-----+-----+------| 958 | 6.1. | TCP header flags | - | O | O | O | - | O | 959 |-------+-------------------------+-----+-----+-----+-----+-----+------| 960 | 6.1. | Fragment counter | - | O | O | O | O | O | 961 |-------+-------------------------+-----+-----+-----+-----+-----+------| 962 | 6.1. | Multicast | O | O | O | - | - | O | 963 | | replication factor | | | | | | | 964 |-------+-------------------------+-----+-----+-----+-----+-----+------| 965 | 6.1. | Flow configuration | O | O | O | O | O | O | 966 |-------+-------------------------+-----+-----+-----+-----+-----+------| 967 | 6.2. | DATA MODEL | 968 |-------+-------------------------+-----+-----+-----+-----+-----+------| 969 | 6.2. | Flexibility | O | O | O | O | O | O | 970 |-------+-------------------------+-----+-----+-----+-----+-----+------| 971 | 6.2. | Extensibility | M | M | M | M | M | M | 972 |-------+-------------------------+-----+-----+-----+-----+-----+------| 973 | Sect. | Requirement | A | B | C | D | E | IPFIX| 974 |-------+-------------------------+-----+-----+-----+-----+-----+------| 975 | 6.3. | DATA TRANSFER | 976 |-------+-------------------------+-----+-----+-----+-----+-----+------| 977 | 6.3.1.| Congestion aware | M | M | M | M | M | M | 978 |-------+-------------------------+-----+-----+-----+-----+-----+------| 979 | 6.3.2.| Reliability | M | S | S | S | S | M | 980 |-------+-------------------------+-----+-----+-----+-----+-----+------| 981 | 6.3.3.| Confidentiality | S | S | S | S | S | S | 982 |-------+-------------------------+-----+-----+-----+-----+-----+------| 983 | 6.3.4.| Integrity | M | M | M | M | M | M | 984 |-------+-------------------------+-----+-----+-----+-----+-----+------| 985 | 6.3.5.| Authenticity | M | M | M | M | M | M | 986 |-------+-------------------------+-----+-----+-----+-----+-----+------| 987 | 6.4. | REPORTING TIMES | 988 |-------+-------------------------+-----+-----+-----+-----+-----+------| 989 | 6.4. | Push mode | M | O | O | M | S | M | 990 | | | | (e) | (e) | |(e,f)| | 991 |-------+-------------------------+-----+-----+-----+-----+-----+------| 992 | 6.4. | Pull mode | O | O | O | O | O | O | 993 | | | | (e) | (e) | | (e) | | 994 |-------+-------------------------+-----+-----+-----+-----+-----+------| 995 | 6.4.1.| Regular Interval | S | S | S | S | S | S | 996 |-------+-------------------------+-----+-----+-----+-----+-----+------| 997 | 6.6. | Notifications | O | O | O | O | O | O | 998 |-------+-------------------------+-----+-----+-----+-----+-----+------| 999 | 6.7. | Anonymization | O | O | O | O | O | O | 1000 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1001 | 7. | CONFIGURATION | 1002 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1003 | 7. | Config Measurement | M | M | M | M | M | M | 1004 | | & Data Export | | | | | | | 1005 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1006 | 7. | Config Observation Point| S | S | S | S | S | S | 1007 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1008 | 7. | Config Flow | S | S | S | S | S | S | 1009 | | Specifications | | | | | | | 1010 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1011 | 7. | Config Report | S | S | S | S | S | S | 1012 | | Data Format | | | | | | | 1013 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1014 | 7. | Config Flow Timeouts | S | S | S | S | O | S | 1015 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1016 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1017 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1018 | 7. | Config | O | O | O | O | O | O | 1019 | | Notifications | | | | | | | 1020 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1021 | 7. | Config Sampling | O | O | O | O | O | O | 1022 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1023 | 7. | Config Anonymization | O | O | O | O | O | O | 1024 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1025 | 7. | Config Security | O | O | O | O | O | O | 1026 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1027 | 8. | GENERAL REQUIREMENTS | 1028 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1029 | 8.1. | Openness | S | S | S | S | S | S | 1030 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1031 | 8.2. | Scalability: | | | | | | | 1032 | | data collection | M | S | M | O | S | M | 1033 | | from hundreds of | | | | | | | 1034 | | measurement devices | | | | | | | 1035 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1036 | 8.3. | Several Collectors | O | O | O | O | O | O | 1037 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1039 Remarks: 1040 (a) If feature is supported. 1041 (b) The differentiation of IPv4 and IPv6 is for TE of importance. 1042 So we tended to make this a MUST. Nevertheless, a SHOULD seems 1043 to be sufficient to perform most TE tasks and allows us to have 1044 a SHOULD for IPFIX instead of a MUST. 1045 (c) For TE in an MPLS network the label is essential. Therefore a 1046 MUST is given here leading to a MUST in IPFIX. 1047 (d) Precise time-based accounting requires reaction to a flow 1048 timeout. 1049 (e) Either push or pull has to be supported. 1050 (f) Required, in order to immediately report drop indications for 1051 SLA validation. 1052 (g) If sampling is supported the parameters and methods MUST be 1053 well defined. 1054 (h) If a packet is fragmented, each fragment is counted as an 1055 individual packet. 1056 (i) Only if measurement is done on data path i.e. has access to 1057 forwarding decision. 1058 (k) If sampling is used.