idnits 2.17.1 draft-ietf-ipfix-reqs-00.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 198 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 673 has weird spacing: '... become targe...' == Line 675 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 (November 2001) is 8197 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 711, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-carpenter-midtax-01 ** Downref: Normative reference to an Informational draft: draft-carpenter-midtax (ref. 'MIDBOXTAX') ** Downref: Normative reference to an Informational RFC: RFC 2702 ** Obsolete normative reference: RFC 2274 (Obsoleted by RFC 2574) Summary: 8 errors (**), 0 flaws (~~), 5 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: May 2002 5 T. Zseby 6 G. Carle 7 S. Zander 8 GMD FOKUS 10 B. Claise 11 Cisco Systems 13 November 2001 15 Requirements for IP Flow Information Export 16 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This memo defines requirements for the export of measured IP flow 41 information out of routers, traffic measurement probes and 42 middleboxes. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119. 50 Table of Content 52 1. Introduction 53 1.1. IP Flows 54 2. Applications Requiring IP Flow Information Export 55 2.1 Usage-based Accounting 56 2.2 Traffic Profiling 57 2.3 Traffic Engineering 58 2.4 Attack/Intrusion Detection 59 2.5 Network Surveillance 60 2.6 QoS Monitoring 61 3. Distinguishing Flows 62 3.1. Interfaces 63 3.2. IP Header Fields 64 3.3. Transport Header Fields 65 3.4. MPLS Label 66 3.5. DiffServ Code Point 67 3.6. Header Compression and Encryption 68 4. Metering Process 69 4.1. Reliability 70 4.2. Sampling 71 4.3. Timestamps 72 4.4. Time Synchronization 73 4.5. Timeout 74 4.6. Ignore Port Copy 75 5. Data Export 76 5.1. Information Model 77 5.2. Data Model 78 5.3. Data Transfer 79 5.3.1. Congestion Awareness 80 5.3.2. Reliability 81 5.3.3. Security 82 5.4. Push and Pull Mode Reporting 83 5.5. Regular Reporting Interval 84 5.6. Notification on Specific Events 85 5.7. Anonymization 86 6. Configuration 87 7. General Requirements 88 7.1. Openness 89 7.2. Scalability concerning measuring devices 90 7.3. Several Data Collectors 91 8. Security Considerations 92 9. Acknowledgements 93 10. References 94 11. Authors' Addresses 95 Appendix: Derivation of Requirements form Target Applications 97 1. Introduction 99 There are several applications that require flow-based IP traffic 100 measurements. Such measurements could be performed by a router while 101 forwarding the traffic, by a middlebox [MIDBOXTAX], or by a traffic 102 measurement probe attached to a line or a monitored port. This memo 103 defines requirements for exporting traffic flow information out of 104 these boxes for further processing by applications located on other 105 devices. In section 2 a selection of such applications is presented. 106 The following sections list requirements derived from these 107 applications. 109 1.1 IP Flows 111 There are several definitions of the term 'flow' being used by the 112 Internet community. Within this document we use the following one: 114 A flow is a set of packets passing an observation point in the 115 network during a certain time interval. All packets belonging to a 116 particular flow have a set of common properties derived from the 117 data contained in the packet and from the packet treatment at the 118 observation point. 120 The observation point may be a network interface of a device or an 121 entire router, a probe, or a middlebox with several interfaces. 122 Properties derived from packet treatment include for example the 123 interface at which the packet arrived, the interface the packet will 124 be forwarded to and potentially some other information. 126 Which flow properties are considered for distinguishing flows is part 127 of the requirements definition and will be addressed below. The above 128 definition covers the range from a flow containing all packets 129 observed at a network interface to a flow consisting of just a single 130 packet between two applications with a specific sequence number. We 131 do not constrain the definition of a flow in terms of unidirectional 132 or bidirectional traffic at this point. Please note that our flow 133 definition does not match a general application-level end-to-end 134 stream. However, an application may derive properties of application- 135 level streams by processing measured flow data. 137 2. Applications Requiring IP Flow Information Export 139 The following list contains a selection of applications requiring IP 140 flow information export. Because requirements for flow export listed 141 in further sections below are derived from these applications, their 142 selection is crucial. The goal of this requirements document is not 143 to cover all possible applications with all their flow export 144 requirements, but to cover applications which are considered to be of 145 significant importance in today's or future IP networks, and for 146 which requirements can be met with reasonable technical effort. 148 Please note, that the described applications can have a large number 149 of differing implementations. Requirement details or the weighting of 150 requirements could differ for specific implementations. Therefore we 151 derive the requirements from the general functionality of the 152 selected applications. Furthermore, the list of applications should 153 lead to a better understanding of the requirements which is 154 particularly important when designing or implementing a traffic flow 155 measuring device. 157 2.1 Usage-based Accounting 159 Several new business models for selling IP service and IP-based 160 services are currently under investigation. Beyond flat rate services 161 which do not need accounting, accounting for these models can be 162 based on time or volume. Accounting data can serve as input for 163 billing systems. Accounting can be performed per user or per user 164 group, it can be performed just for basic IP service or individually 165 per high-level service and/or per content type delivered. For 166 advanced/future services, accounting may also be performed per class 167 of service, per application, per time of day, per used (label 168 switched) path, etc. 170 2.2 Traffic Profiling 172 Traffic profiling is a process of characterizing IP flows and flow 173 aggregates by using a model that represents key parameters of the 174 flow such as flow duration, volume, time and burstiness. It is a 175 prerequisite for network planning, network dimensioning, trend 176 analysis, developing business models, and other activities. It 177 heavily depends on the particular traffic profiling objective(s) what 178 statistics and accuracy are required from the measurements. Typical 179 information needed for traffic profiling are the distribution of used 180 services and protocols in the network, the amount of packets of a 181 specific type (e.g. percentage of IPv6 packets) and specific flow 182 profiles. 184 Since objectives for traffic profiling can vary, this application 185 requires a high flexibility of the measurement infrastructure, 186 especially regarding the options for measurement configuration and 187 packet classification. 189 2.3 Traffic Engineering 191 Traffic Engineering (TE) comprises methods for measurement, modeling, 192 characterization and control of a network. The goal of TE is the 193 optimization of network resource utilization and traffic performance 194 [RFC2702]. Since control and administrative reaction to measurement 195 results requires access to the involved network nodes, TE mechanisms 196 and the required measurement function usually are performed within 197 one administrative domain. Typical parameters required for TE are 198 link utilization, load between specific network nodes, number, size 199 and entry/exit points of the active flows and routing information. 201 2.4 Attack/Intrusion Detection 203 Capturing of flow information plays an important role for network 204 security, both for detection of security violation, and for 205 subsequent defense. In case of a Denial of Service (DOS) attack, flow 206 monitoring can allow detection of unusual load situations or 207 suspicious flows. In a second step, flow analysis can be performed in 208 order to gather information about the attacking flows, and for 209 deriving a defense strategy. 211 Intrusion detection is a potentially more demanding application which 212 would not only look at specific characteristics of flows, but that 213 may also use a stateful packet flow analysis for detecting specific, 214 suspicious activities, or unusually frequent activities. Such 215 activities may be characterized by specific communication patterns, 216 detectable by characteristic sequences of certain packet types. 218 2.5 Network Surveillance 220 This application class requires collection and storage of information 221 that characterizes flows, and possibly also the collection and 222 storage of selected packets. One obvious use for network surveillance 223 is the collection of evidence of illegal activities for the purpose 224 of law enforcement. As the data collected for the purpose of network 225 surveillance contains sensitive information, adequate security 226 mechanisms are required in order to avoid misuse of the sensitive 227 information. 229 2.6 QoS Monitoring 231 QoS monitoring is the non-intrusive (passive) measurement of quality 232 parameters for single flows or traffic aggregates. In contrast to 233 intrusive (active) measurements, non-intrusive measurements utilize 234 the existing traffic in the network for QoS analysis. Since no test 235 traffic is sent, non-intrusive measurements can only be applied in 236 situations where the traffic of interest is already present in the 237 network. One example application is the validation of QoS parameters 238 negotiated in a service level specification (SLS). 240 Non-intrusive measurements cannot provide the kind of controllable 241 experiments that can be achieved with active measurements. On the 242 other hand non-intrusive measurements do not suffer from undesired 243 side effects caused by sending test traffic (e.g. additional load, 244 "Heisenberg" effects, potential differences in treatment of test 245 traffic and real customer traffic) 247 QoS monitoring often requires the correlation of data from multiple 248 measurement instances (e.g. for measuring one-way metrics). This 249 requires proper clock synchronization of the involved measurement 250 instances. For some measurements packet events at the different 251 measurement points must be correlated. For this, the provisioning of 252 post-processing functions (e.g. the generation of packet IDs) at the 253 measurement instances would be useful. Furthermore, QoS monitoring 254 can lead to a huge amount of measurement result data. Therefore it 255 would highly benefit from mechanisms to reduce the measurement data, 256 like aggregation of results and flow sampling. 258 3. Distinguishing Flows 260 Packets are mapped to flows by evaluating their properties. Packets 261 with common properties are considered to belong to the same flow. A 262 packet showing at least one difference in the set of properties is 263 considered to belong to a different flow. 265 The following subsections list a set of properties which a measuring 266 device MUST, SHOULD, or MAY be able to evaluate for mapping packets 267 to flows. Please note that requiring the ability to evaluate a 268 certain property does not imply that this property must be evaluated 269 for each packet. 271 Which combination of properties is evaluated for a particular 272 measurement and how these properties are evaluated depends on the 273 capabilities of the measuring device and on its configuration. The 274 configured choice of evaluated properties strongly depends on the 275 environment and purpose of the measurement and on the information 276 required by the data collector. 278 For specific deployments, only a subset of the REQUIRED properties 279 listed below could be used to distinguish flows, in order to 280 aggregate the flow records and reduce the number of flow records 281 exported. On the other hand, some other deployments will require to 282 distinguish flows by some extra parameters, like for example the TTL 283 field of the IP header or the BGP Autonomous Systems. 285 3.1. Interfaces 287 The measuring device MUST be able to separate flows by the incoming 288 interface or by the outgoing interface or by both of them. 290 3.2. IP Header Fields 292 The measuring device MUST, SHOULD, or MAY be able to separate flows 293 by the following fields of the IP header as indicated. 295 1. source IP address (MUST) 296 2. destination IP address (MUST) 297 3. transport protocol type (MUST) 298 4. IP version number (SHOULD) 299 This requirement only applies if the device is supporting 300 more than one version of IP. 302 For source address and destination address separating by full match 303 MUST be supported as well as separation by a partial match (for 304 example subnet masking). 306 3.3. Transport Header Fields 308 The measuring device MUST be able to separate flows by the port 309 numbers of the transport header in case of TCP or UDP being used as 310 transport protocol. Both, source and destination port number MUST be 311 supported for distinguishing flows, individually as well as in 312 combination. 314 3.4. MPLS Label 316 If the measuring device supports Multiprotocol Label Switching (MPLS, 317 see [RFC3031]), then the measuring device MUST be able to separate 318 flows by the MPLS label. 320 3.5. DiffServ Code Point 322 If the measuring device supports Differentiated Services (DiffServ), 323 then the measuring device MUST be able to separate flows by the 324 DiffServ Code Point (DSCP, see [RFC2474]). 326 3.6. Header Compression and Encryption 328 If header compression or encryption is used, the measuring device 329 might not be able to access all header fields. In such a case only 330 end points of header compression or of packet encryption are expected 331 to meet the requirements stated in this section 3. 333 4. Metering Process 335 The following are requirements for the metering process. They 336 describe the requirements for the process at the measurement 337 instance. All measurements MUST be conducted from the point of view 338 of the observation point. 340 4.1. Reliability 342 The measurement process MUST either be reliable or missing 343 reliability MUST be known and indicated. The measurement process is 344 reliable, if each packet passing the observation point is measured 345 according to the configuration of the measuring device. If, e.g. due 346 to some overload, not all passing packets can be included into the 347 measurement process, then it SHOULD be stored at the measuring 348 device, that flows might be measured inaccurately. 350 4.2. Sampling 352 The measuring device MAY support measuring traffic by packet 353 sampling. If sampling is supported the sampling method and its 354 parameters MUST be well defined. The device MAY offer a mechanism for 355 automatically switching to sampling (or to a more coarse flow 356 definition) in case of certain events, such as device overloaded. If 357 automatic switch to sampling or automated switch of the sampling rate 358 is supported, the events triggering a switch and the chosen sampling 359 method and parameters after a switch MUST be well defined. 361 4.3. Timestamps 363 The measuring device MUST be able to generate a timestamp for each 364 observed packet. Please note that section 5.1 requires to offer 365 reporting a timestamp for the first and the last observed packet of a 366 flow. Therefore, the measuring device MUST be able to store at least 367 two timestamps per flow. 369 4.4. Time Synchronization 371 Different measuring device(s) and data collector(s) SHOULD be time 372 synchronized between each other. NTP is a possible way of achieving 373 this. Where there are so many types of synchronization between 374 devices and collectors, the synchronization of the devices and 375 collectors cannot be defined as part of IPFIX. The method for time 376 synchronization is not in the scope of IPFIX. 378 4.5. Timeout 380 The measuring device MUST be able to detect flow timeout. A flow is 381 considered to be timed out if no packet of this flow has been 382 observed for a given timeout interval. The measuring device MAY 383 support means for detecting the end of a flow before a time out 384 occurs, for example by detecting the FIN or RST bits in a TCP 385 connection. 387 4.6. Ignore Port Copy 389 The measuring device MAY be able to ignore packets which are 390 generated by a port copy function acting at the same device. 392 5. Data Export 394 The following are requirements for exporting measured flow data out 395 of the measuring device. Beside requirements on the data transfer, we 396 separate requirements concerning the information model from 397 requirements concerning the data model. Furthermore, we list 398 requirements on reporting times and events and on anonymization of 399 records. 401 5.1. Information Model 403 The information model for a flow measurement report is the list of 404 attributes of a flow to be contained in the report (including the 405 semantics of the attributes). 407 This section lists attributes a measuring device MUST or MAY be able 408 to report. This does not imply that a report MUST contain all 409 REQUIRED attributes, but that it MUST be possible to configure the 410 device in a way that all of the REQUIRED attributes are contained in 411 a report for each measured flow. 413 Beyond that, the device might offer to report also further attributes 414 not mentioned here. A particular report may contain some of the 415 "REQUIRED" attributes as well as some additional ones, for example 416 covering future technologies. 418 The measuring device MUST be able to report the following attributes 419 for each measured flow: 421 1. IP version number 422 This requirement only applies if the device is supporting more 423 than one version of IP. 424 2. source IP address 425 3. destination IP address 426 4. transport type 427 5. source port number 428 6. destination port number 429 7. packet counter 430 If a packet is fragmented, each fragment is counted as an 431 individual packet. 432 8. observed byte counter 433 9. in case of IPv4: Type of Service 434 10. in case of IPv6: Flow Label 435 11. if BGP is supported: BGP AS# 436 12. if MPLS is supported: MPLS label 437 13. if DiffServ is supported: DSCP 438 14. timestamp of the first packet observed 439 15. timestamp of the last packet observed 440 16. if sampling is used: sampling method 441 17. if sampling is used: sampling parameters 442 18. unique identifier of the observation point 443 19. unique identifier of the measuring device 445 The measuring device MAY be able to report the following attributes 446 for each measured flow: 447 20. Time To Live 448 21. IP header flags 449 22. TCP header flags 450 23. dropped packet counter 451 If a packet is fragmented, each fragment is counted as an 452 individual packet. This requirements does not apply to probes where 453 the value of this counter is always zero. 454 24. fragmented packet counter 455 counter of all packets for which the fragmented bit is set in 456 the IP header 457 25. multicast replication factor 458 the number of outgoing packets originating from a single 459 incoming multicast packet 461 5.2 Data Model 463 The data model describes how information is represented in flow 464 records. The data model used for exporting flow data MAY be flexible 465 concerning the flow attributes contained in reports. A flexible 466 record format would offer the possibility of defining records in a 467 flexible (customizable) way regarding the number and type of report 468 attributes. 470 The data model MUST be extensible for future attributes to be added. 471 Even if a set of attributes is fixed in the flow record, the data 472 model MUST provide a way of extending the record by configuration or 473 for certain implementations. 475 The Data Model SHOULD be independent of the underlying transport 476 protocol, i.e. the data transfer. 478 5.3. Data Transfer 480 Requirements for the data transfer include reliability and security 481 requirements. These requirements do not apply to the measuring device 482 alone, but also to the transport network. Consequently, the 483 measurement device does not necessarily have to guarantee that all 484 requirements are met. Particularly if the security requirements are 485 already guaranteed by the network used for data transfer, then these 486 requirements do not have to be considered anymore by the measuring 487 device. Therefore, these requirements are OPTIONAL for the measuring 488 device, although they may be REQUIRED for the data transfer as 489 specified in the appendix. 491 5.3.1. Congestion Awareness 493 For the data transfer a congestion aware protocol MUST be supported. 495 5.3.2. Reliability 497 Absence of reliability of the data transfer MUST be indicated 498 covering packet loss and packet reordering. 500 Please note that if an unreliable transport protocol is used, 501 reliability can be provided by higher layers. In such a case only 502 lack of overall reliability MUST be indicated. For example reordering 503 could be dealt with by adding a sequence number to each packet. 505 5.3.3. Security 507 Confidentiallity of transferred IPFIX data SHOULD be ensured. 509 Integrity of transferred IPFIX data MUST be ensured. 511 Authenticity of transferred IPFIX data MUST be ensured. 513 5.4. Push and Pull Mode Reporting 515 In general, there are two ways of deciding on reporting times: push 516 mode and pull mode. In push mode, the measuring device decides 517 without an external trigger on when to send a report on measured 518 flows. In pull mode, sending a report is triggered by an explicit 519 request from a data collector or some other receiver of flow records. 520 The measuring device MUST support push mode reporting, it MAY support 521 pull mode reporting. 523 5.5. Regular Reporting Interval 525 The measuring device SHOULD be capable of reporting measured traffic 526 data regularly according to a given interval length. 528 5.6. Notification on Specific Events 530 The measuring device MAY be capable of sending notifications to a 531 consumer of measure data, if a specific event occurs. Such an event 532 might be the arrival of the first packet of a new flow, or the 533 termination of a flow after flow timeout. 535 5.7. Anonymization 537 The measuring device MAY be capable of anonymizing source and 538 destination IP addresses in flow data before exporting them. It MAY 539 support anonymization of port numbers and other fields. Please note 540 that anonymization is not originally an application requirement, but 541 derived from general requirements for treatment of traffic within a 542 network. 544 6. Configuration 546 The measuring device MUST provide a way of configuring the traffic 547 measurement and the traffic data export remotely. The following 548 parameters SHOULD be configurable: 550 1. specification of the observation point, e.g. a list of 551 interfaces to be monitored. 552 2. specifications of flows to be measured 553 3. reporting data format 554 Specifying the reporting data format SHOULD include a selection 555 of attributes to be reported for each flow. 557 The following parameters MAY be configurable: 559 4. notifications 560 5. flow timeouts 561 6. sampling method and parameters, if feature is supported 562 7. flow anonymization, if feature is supported 564 The measuring device SHOULD support security of remote configuration 565 including confidentiality, integrity and authenticity. 567 7. General Requirements 569 7.1. Openness 571 IPFIX specifications SHOULD be open to future technologies. This 572 includes extensibility of configuration of measurement and reporting 573 as well as extensibility of the reporting information model and data 574 model. 576 7.2. Scalability concerning measuring devices 578 Data collection from hundreds of different measuring devices MUST be 579 supported. The data collector MUST be able to distinguish several 580 hundred measuring devices by their identifiers. 582 7.3. Several Data Collectors 584 The measuring device MAY be able to export flow information to more 585 than one data collector. 587 8. Security Considerations 589 This document describes requirements for IP Flow Information Export 590 (IPFIX). It therefore also states the required security features for 591 a future IPFIX protocol. Nevertheless, the suggestion of solutions 592 for achieving the security properties is out of scope of this 593 document and will be part of future IPFIX documents that specify 594 IPFIX architecture and protocol. 596 Like other requirements, the security requirements differ for the 597 considered applications. The incentive to modify data collected for 598 accounting or intrusion detection for instance is usually higher than 599 the incentive to change data collected for traffic profiling. 600 Therefore the required security features are listed per application. 601 Furthermore, the security requirements also differ with regard to the 602 environment in which an IPFIX protocol is used (e.g. intra- or inter- 603 domain). Some of these issues are part of the IPFIX architecture and 604 with this out of scope of this document. Therefore this document also 605 tries to consider security threats that can only occur in an insecure 606 environment (e.g. where it can not be excluded, that an attacker 607 might gain access to the network). 609 Several security hazards also occur if the measurement process is 610 configured remotely (e.g. access to the measurement process, forgery 611 of configuration information, etc.). Nevertheless, this document 612 specifies only what parameters SHOULD or MAY be configurable for the 613 measurement process. It does not deal with requirements for a 614 protocol for measurement configuration. Therefore security 615 considerations regarding the measurement configuration are out of 616 scope of this document. 618 The following potential security hazards for an IPFIX protocol can be 619 identified: 621 - Disclosure of IP flow information data 622 It may be required to keep measurement records confidential 623 between the involved parties. Observation of IP flow 624 information data gives an attacker information about the active 625 flows in the network, communication endpoints and traffic 626 patterns. This information can not only be used to spy out user 627 behavior but also to plan and conceal future attacks. Therefore 628 the requirements document recommends to ensure the 629 confidentiality of the transferred data. This can be done for 630 instance by encryption. 632 Furthermore, features for anonymization may be provided by the 633 future IPFIX protocol. With this communication endpoints can be 634 kept confidential. Anonymization is also a useful feature to 635 allow measurements (e.g. by a third party) without violating 636 privacy protection. 638 - Forgery of exported IP flow information data 639 Especially for applications like accounting or intrusion 640 detection there are strong incentives (e.g. save money or 641 prevent detection of an attack) to forge exported IP flow 642 information records. This can be done either by altering data 643 on the path or by sending records from a device that pretends 644 to be the measurement device. In order to make the IPFIX 645 protocol resistant against such attacks this document requires 646 to ensure authenticity and integrity of the data for the IPFIX 647 data transfer. 649 Special caution is required if security applications rely on 650 IPFIX data With forgery of exported IP flow information data it 651 is possible to trick on security applications. With this it can 652 be for instance possible to pretend that a DoS attack happens 653 without even launching a real attack. 655 - Denial of Service (DoS) attacks 656 DoS attacks on routers or other middleboxes that have the IPFIX 657 protocol implemented would also affect the IPFIX protocol and 658 impair the sending of IPFIX records. Nevertheless, since such 659 hazards are not induced specifically by the IPFIX protocol the 660 prevention of such attacks is out of scope of this document. 662 IPFIX itself causes the following potential hazards for DoS 663 attacks. It is always possible to overload the measurement 664 device if it expects the reception of traffic. For IPFIX this 665 can occur in two cases. First, if the protocol supports the 666 pull mode (which is one option in this document) and expects 667 requests. Secondly, if data is expected for remote measurement 668 configuration. The first case could be prevented by ensuring 669 authenticity for IPFIX requests. The second case should be 670 addressed for the specification of an IPFIX configuration 671 protocol and therefore is out of scope of this document. 673 Also IPFIX collectors can become target of an DoS attack. This 674 can be done by sending IPFIX data from a malicious device that 675 pretends to be an IPFIX source. This can be prevented by 676 ensuring authenticity of IPFIX data as stated in this document. 677 It is also possible that collectors are flooded with IPFIX 678 record from an authorized IPFIX devices for which the 679 configuration was altered. Furthermore, malicious configuration 680 or forgery of exported data can cause a loss or re-direction of 681 IPFIX data (e.g. if destination addresses for flow records are 682 modified). This can lead to a disruption of upper layer 683 services (accounting, intrusion detection, etc.) due to lack 684 of IPFIX records. This can be prevented by controlling 685 configuration access and by ensuring the integrity of exported 686 data. 688 9. Acknowledgements 690 We like to thank all the people contributing to the requirements 691 discussion on the mailing list, particularly K.C. Norseth from 692 Enterasys for a lot of valuable comments and for suggesting several 693 last minute edits of this document. 695 10. References 697 [MIDBOXTAX] B. Carpenter, "Middleboxes: taxonomy and issues", 698 draft-carpenter-midtax-01.txt, work in progress. 700 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 701 Switching Architecture", RFC 3031, January 2001. 703 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition 704 of the Differentiated Services Field (DS Field) in the IPv4 705 and IPv6 Headers", RFC 2474, December 1998. 707 [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 708 "Requirements for Traffic Engineering Over MPLS", 709 RFC 2702, September 1999. 711 [RFC2274] U. Blumenthal, B. Wijnen "User-based Security Model (USM) 712 for version 3 of the Simple Network Management Protocol 713 (SNMPv3), RFC 2274, January 1998. 715 11. Authors' Addresses 717 Juergen Quittek 718 NEC Europe Ltd. 719 Adenauerplatz 6 720 69115 Heidelberg 721 Germany 723 Phone: +49 6221 90511-15 724 EMail: quittek@ccrle.nec.de 726 Tanja Zseby 727 GMD FOKUS 728 Kaiserin-Augusta-Allee 31 729 10589 Berlin 730 Germany 732 Phone: +49 30 3463 7153 733 Email: zseby@fokus.gmd.de 735 Georg Carle 736 GMD FOKUS 737 Kaiserin-Augusta-Allee 31 738 10589 Berlin 739 Germany 741 Phone: +49 30 3463 7149 742 Email: carle@fokus.gmd.de 743 Sebastian Zander 744 GMD FOKUS 745 Kaiserin-Augusta-Allee 31 746 10589 Berlin 747 Germany 749 Phone: +49 30 3463 7287 750 Email: zander@fokus.gmd.de 752 Benoit Claise 753 Cisco Systems 754 De Kleetlaan 6a b1 755 1831 Diegem 756 Belgium 758 Phone: +32 2 704 5622 759 Email: bclaise@cisco.com 761 Appendix: Derivation of Requirements form Target Applications 763 The following table documents, how the requirements stated in 764 sections 3-7 are derived from requirements of the applications listed 765 in section 2. 767 Used abbreviations: 768 M = MUST 769 S = SHOULD 770 O = MAY (OPTIONAL) 771 - = DONT CARE 773 -----------------------------------------------------------------------. 774 IPFIX | 775 ----------------------------------------------------------------. | 776 F: QoS Monitoring | | 777 ----------------------------------------------------------. | | 778 E: Network Surveillance | | | 779 ----------------------------------------------------. | | | 780 D: Attack/Intrusion Detection | | | | 781 ----------------------------------------------. | | | | 782 C: Traffic Engineering | | | | | 783 ----------------------------------------. | | | | | 784 B: Traffic Profiling | | | | | | 785 ----------------------------------. | | | | | | 786 A: Usage-based Accounting | | | | | | | 787 ----------------------------. | | | | | | | 788 | | | | | | | | 790 | Sect. | Requirement | A | B | C | D | E | F | IPFIX| 791 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 792 | 3. | DISTINGUISHING FLOWS | 793 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 794 | 3. |Combination of | M | M | M | M | M | M | M | 795 | |required attributes| | | | | | | | 796 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 797 | 3.1. |in/out IF | S | M | M | S | S | S | M | 798 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 799 | 3.2. |src/dst address | M | M | M | M | M | M | M | 800 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 801 | 3.2. |Masking of IP | M | M | M | M | M | M | M | 802 | |adresses | | | | | | | | 803 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 804 | 3.2. |transport protocol | M | M | - | M | M | M | M | 805 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 806 | 3.2. |version field | - | S | S | O | O | O | S | 807 | | | | | (b) | | | | | 808 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 809 | 3.3. |src/dst port | M | M | - | M | M | M | M | 810 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 811 | 3.4. |MPLS label (a) | S | S | M | O | - | S | M | 812 | | | | | (c) | | | | | 813 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 814 | 3.5. |DSCP (a) | M | S | M | O | - | M | M | 815 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 816 | 4. |METERING PROCESS | 817 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 818 | 4.1. |Reliability | M | S | S | S | M | S | | 819 |-------+-------------------+-----+-----+-----+-----+-----+-----+ M | 820 | 4.1. |Indication of | - | M | M | M | - | M | | 821 | |missing reliability| | | | | | | | 822 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 823 | 4.2. |Sampling (g) | O | O | O | O | - | O | O | 824 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 825 | 4.2. |Dynamic sampling | O | O | O | O | - | O | O | 826 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 827 | 4.3. |Timestamping at | M | O | O | S | S | M | M | 828 | |measurement device | | | | | | | | 829 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 830 | 4.4. |Time synchroniz. | S | S | S | S | S | S | S | 831 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 832 | 4.5. |Flow timeout | M | S | - | O | O | O | M | 833 | | | (d) | | | | | | | 834 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 835 | 4.6. |Ignore port copy | O | O | O | O | O | O | O | 836 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 837 | Sect. | Requirement | A | B | C | D | E | F | IPFIX| 838 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 839 | 5. |DATA EXPORT | 840 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 841 | 5.1. |INFORMATION MODEL | 842 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 843 | 5.1. |IP Version | - | M | M | O | O | O | M | 844 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 845 | 5.1. |src/dst address | M | M | M | M | M | M | M | 846 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 847 | 5.1. |transport protocol | M | M | - | M | O | M | M | 848 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 849 | 5.1. |src/dst transport | M | M | - | M | O | M | M | 850 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 851 | 5.1. |Packet counter (h) | S | M | M | S | - | S | M | 852 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 853 | 5.1. |Byte counter | M | M | M | S | - | S | M | 854 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 855 | 5.1. |Dropped Packet | O | M | M | S | - | M | M | 856 | |Counter (h,i) | | | | | | | | 857 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 858 | 5.1. |ToS Byte | M | S | M | O | O | M | M | 859 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 860 | 5.1. |Flow Label | M | S | M | O | O | M | M | 861 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 862 | 5.1. |BGP AS# | - | S | M | - | - | - | M | 863 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 864 | 5.1. |MPLS label (a) | S | S | M | O | - | S | M | 865 | | | | | (c) | | | | | 866 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 867 | 5.1. |DSCP (a) | M | S | M | O | - | M | M | 868 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 869 | 5.1. |Timestamps for | M | O | O | S | O | S | M | 870 | |first/last packet | | | | | | | | 871 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 872 | 5.1. |Sampling methods | M | M | M | M | M | M | M | 873 | |& parameters (k) | | | | | | | | 874 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 875 | 5.1. |observation point | M | M | M | M | M | M | M | 876 | |identifier | | | | | | | | 877 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 878 | 5.1. |measuring device | M | M | M | M | M | M | M | 879 | |identity | | | | | | | | 880 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 881 | 5.1. |TTL | O | O | O | O | - | O | O | 882 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 883 | 5.1. |IP header flags | - | O | O | O | - | O | O | 884 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 885 | Sect. | Requirement | A | B | C | D | E | F | IPFIX| 886 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 887 | 5.1. |TCP header flags | - | O | O | O | - | - | O | 888 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 889 | 5.1. |Fragment counter | - | O | O | O | _ | O | O | 890 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 891 | 5.1. |Multicast | O | O | O | - | - | - | O | 892 | |replication factor | | | | | | | | 893 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 894 | 5.1. |Flow configuration | O | O | O | O | O | O | O | 895 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 896 | 5.2. |DATA MODEL | 897 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 898 | 5.2. |Flexibility | O | O | O | O | O | O | O | 899 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 900 | 5.2. |Extensibility | M | M | M | M | M | M | M | 901 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 902 | 5.3. |DATA TRANSFER | 903 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 904 | 5.3.1.|Congestion aware | M | M | M | M | M | M | M | 905 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 906 | 5.3.2.|Reliability | M | S | S | S | M | S | M | 907 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 908 | 5.3.3.|Confidentiality | S | S | S | S | S | S | S | 909 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 910 | 5.3.4.|Integrity | M | M | M | M | M | M | M | 911 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 912 | 5.3.5.|Authenticity | M | M | M | M | M | M | M | 913 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 914 | 5.4. |REPORTING TIMES | 915 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 916 | 5.4. |Push mode | M | O | O | M | O | S | M | 917 | | | | (e) | (e) | | (e) |(e,f)| | 918 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 919 | 5.4. |Pull mode | O | O | O | O | O | O | O | 920 | | | | (e) | (e) | | (e) | (e) | | 921 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 922 | 5.4.1.|Regular Interval | S | S | S | S | S | S | S | 923 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 924 | 5.6. |Notifications | O | O | O | O | O | O | O | 925 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 926 | 5.7. |Anonymization | O | O | O | O | O | O | O | 927 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 928 | Sect. | Requirement | A | B | C | D | E | F | IPFIX| 929 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 930 | 6. |CONFIGURATION | 931 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 932 | 6. |Config Measurement | M | M | M | M | M | M | M | 933 | |& Data Export | | | | | | | | 934 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 935 | 6. |Config Observation | S | S | S | S | S | S | S | 936 | |Point | | | | | | | | 937 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 938 | 6. |Config Flow | S | S | S | S | S | S | S | 939 | |Specifications | | | | | | | | 940 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 941 | 6. |Config Report | S | S | S | S | S | S | S | 942 | |Data Format | | | | | | | | 943 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 944 | 6. |Config | O | O | O | O | O | O | O | 945 | |Notifications | | | | | | | | 946 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 947 | 6. |Config Flow | O | O | O | O | O | O | O | 948 | |Timeouts | | | | | | | | 949 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 950 | 6. |Config Sampling | O | O | O | O | O | O | O | 951 | | | | | | | | | | 952 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 953 | 6. |Config | O | O | O | O | O | O | O | 954 | |Anonymization | | | | | | | | 955 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 956 | 6. |Config | O | O | O | O | O | O | O | 957 | |Security | | | | | | | | 958 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 959 | 7. |GENERAL REQREQUIREMENTS | 960 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 961 | 7.1. |Openness | S | S | S | S | S | S | S | 962 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 963 | 7.2. |Scalability: | | | | | | | | 964 | |data collection | M | S | M | O | M | S | M | 965 | |from hundreds of | | | | | | | | 966 | |measurement devices| | | | | | | | 967 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 968 | 7.3. |Several Data | O | O | O | O | O | O | O | 969 | |Collectors | | | | | | | | 970 |-------+-------------------+-----+-----+-----+-----+-----+-----+------| 972 Remarks: 973 (a) If feature is supported. 974 (b) The differentiation of IPv4 and IPv6 is for TE of importance. 975 So we tended to make this a MUST. Nevertheless, a SHOULD seems 976 to be sufficient to perform most TE tasks and allows us to have 977 a SHOULD for IPFIX instead of a MUST. 978 (c) For TE in an MPLS network the label is essential. Therefore a 979 MUST is given here leading to a MUST in IPFIX. 980 (d) Precise time-based accounting requires reaction to a flow 981 timeout. 982 (e) Either push or pull has to be supported. 983 (f) Required, in order to immediately report drop indications for 984 SLA validation. 985 (g) If sampling is supported the parameters and methods MUST be 986 well defined. 987 (h) If a packet is fragmented, each fragment is counted as an 988 individual packet. 989 (i) Only if measurement is done on data path i.e. has access to 990 forwarding decission. 991 (k) If sampling is used.