idnits 2.17.1 draft-ietf-ipfix-reqs-03.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 seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 184 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1042 has weird spacing: '...for the purpo...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Overload behavior is not restricted to the four options listed above. But in case the overload behavior has an impact on the metering process or the export process, the overload behavior MUST be clearly defined and the collector MUST be able to distinguish the flow records exported before and after the metering process behavior change: In case of any change of the meter's behavior, all flow records metered by the previous behavior MUST be terminated and exported according to the export configuration. The metering process MUST not merge the flow records generated with the new behavior with the flow records generated with the previous behavior. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7957 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) == Missing Reference: 'RFC 2026' is mentioned on line 26, but not defined == Unused Reference: 'RFC2026' is defined on line 948, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3234 ** Downref: Normative reference to an Informational RFC: RFC 2702 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft J. Quittek 2 Document: draft-ietf-ipfix-reqs-03.txt NEC Europe Ltd. 3 Expires: December 2002 T. Zseby 4 FhI FOKUS 5 B. Claise 6 Cisco Systems 7 S. Zander 8 G. Carle 9 FhI FOKUS 10 K.C. Norseth 11 Consultant 13 June 2002 15 Requirements for IP Flow Information Export 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are 23 working documents of the Internet Engineering Task Force (IETF), its 24 areas, and its working groups. Note that other groups may also 25 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 Distribution of this document is unlimited. 40 Copyright Notice 42 Copyright (C) The Internet Society (2001). All Rights Reserved. 44 Abstract 46 This memo defines requirements for the export of measured IP flow 47 information out of routers, traffic measurement probes and 48 middleboxes. 50 Table of Contents 52 1 Introduction ................................................. 2 53 2 Terminology .................................................. 2 54 2.1 IP Traffic Flow ............................................ 2 55 2.2 Observation Point .......................................... 3 56 2.3 Metering Process ........................................... 3 57 2.4 Flow Record ................................................ 4 58 2.5 Export Process ............................................. 4 59 2.6 Collecting Process ......................................... 4 60 3 Applications Requiring IP Flow Information Export ............ 4 61 3.1 Usage-based Accounting ..................................... 5 62 3.2 Traffic Profiling .......................................... 5 63 3.3 Attack/Intrusion Detection ................................. 6 64 3.4 QoS Monitoring ............................................. 6 65 4 Distinguishing Flows ......................................... 7 66 4.1 Interfaces ................................................. 7 67 4.2 IP Header Fields ........................................... 8 68 4.3 Transport Header Fields .................................... 8 69 4.4 MPLS Label ................................................. 8 70 4.5 DiffServ Code Point ........................................ 8 71 4.6 Header Compression and Encryption .......................... 8 72 5 Metering Process ............................................. 9 73 5.1 Reliability ................................................ 9 74 5.2 Sampling ................................................... 9 75 5.3 Overload Behavior .......................................... 10 76 5.4 Timestamps ................................................. 10 77 5.5 Time Synchronization ....................................... 10 78 5.6 Timeout .................................................... 10 79 5.7 Ignore Port Copy ........................................... 11 80 6 Data Export .................................................. 11 81 6.1 Information Model .......................................... 11 82 6.2 Data Model ................................................. 13 83 6.3 Data Transfer .............................................. 13 84 6.3.1 Congestion Awareness ..................................... 13 85 6.3.2 Reliability .............................................. 13 86 6.3.3 Security ................................................. 14 87 6.4 Push and Pull Mode Reporting ............................... 14 88 6.5 Regular Reporting Interval ................................. 14 89 6.6 Notification on Specific Events ............................ 14 90 6.7 Anonymization .............................................. 14 91 7 Configuration ................................................ 14 92 8 General Requirements ......................................... 15 93 8.1 Openness ................................................... 15 94 8.2 Scalability Concerning the Number of Export Processes ...... 15 95 8.3 Several Collectors ......................................... 15 96 9 Special Device Considerations ................................ 16 97 10 Security Considerations ..................................... 17 98 10.1 Disclosure of Flow Information Data ....................... 18 99 10.2 Forgery of Flow Records ................................... 18 100 10.3 Denial of Service (DoS) Attacks ........................... 19 101 11 Acknowledgments ............................................. 19 102 12 References .................................................. 19 103 13 Authors' Addresses .......................................... 20 104 14 Full Copyright Statement .................................... 21 105 Appendix: Derivation of Requirements from Applications ......... 22 107 1. Introduction 109 There are several applications that require flow-based IP traffic 110 measurements. Such measurements could be performed by a router while 111 forwarding the traffic, by a middlebox [RFC3234], or by a traffic 112 measurement probe attached to a line or a monitored port. This memo 113 defines requirements for exporting traffic flow information out of 114 these boxes for further processing by applications located on other 115 devices. In section 3, a selection of such applications is presented. 116 The following sections list requirements derived from these 117 applications. 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. Terminology 125 The following terminology is used within this document: 127 2.1. IP Traffic Flow 129 There are several definitions of the term 'flow' being used by the 130 Internet community. Within this document we use the following one: 132 A flow is defined as a set of IP packets passing an observation point 133 in the network during a certain time interval. All packets belonging 134 to a particular flow have a set of common properties. Each property 135 is defined as the result of applying a function to the values of: 137 1. one or more of packet header fields (e.g. destination IP 138 address) 140 2. one or more properties of the packet itself (e.g. packet 141 length) 143 3. one or more of fields derived from packet treatment (e.g. AS 144 number) 146 A packet is defined to belong to a flow if it completely satisfies 147 all the defined properties of the flow. 149 This definition covers the range from a flow containing all packets 150 observed at a network interface to a flow consisting of just a single 151 packet between two applications with a specific sequence number. 152 Please note that the flow definition does not necessarily match a 153 general application-level end-to-end stream. However, an application 154 may derive properties of application-level streams by processing 155 measured flow data. 157 2.2. Observation Point 159 The observation point is a location in the network where IP packets 160 can be observed. Examples are a line to which a probe is attached, a 161 shared medium, such as an Ethernet-based LAN, a single port of a 162 router, or a set of interfaces (physical or logical) of a router. 164 Please note that a coarse-grained observation point of one flow, for 165 example a line card with several ports, may be the superset of 166 several more fine-grained observation points of some other flows, for 167 example the individual ports of the line card. 169 2.3. Metering Process 171 The metering process generates flow records. Input to the process are 172 IP packet headers observed at an observation point. The metering 173 process consists of a set of functions that includes packet header 174 capturing, timestamping, sampling, classifying, and maintaining flow 175 records. 177 The maintenance of flow records may include creating new records, 178 updating existing ones, computing flow statistics, deriving further 179 flow properties, detecting flow expiration, passing flows record to 180 the export process, and deleting flow records. 182 The sampling function and the classifying function may be applied 183 more than once with different parameters. Figure 1 shows the sequence 184 in which the functions are applied. Sampling is not illustrated in 185 the figure, it may be applied before any other function. 187 packet header capturing 188 | 189 timestamping 190 | 191 v 192 +----->+ 193 | | 194 | classifying 195 | | 196 +------+ 197 | 198 maintaining flow records 199 | 200 v 202 Figure 1: Functions of the metering process 204 2.4. Flow Record 206 A flow record contains information about a specific flow that was 207 metered at an observation point. A flow record contains measured 208 properties of the flow (e.g. the total number of bytes of all packets 209 of the flow) and usually also characteristic properties of the flow 210 (e.g. source IP address). 212 2.5. Export Process 214 The export process sends flow records to one or more collectors. The 215 flow records are generated by one or more metering processes. 217 2.6. Collecting Process 219 The collecting process receives flow records from one or more export 220 processes. The collecting process might store received flow records 221 or further process them, but these actions are out of the scope of 222 this document. 224 3. Applications Requiring IP Flow Information Export 226 This section describes a selection of applications requiring IP flow 227 information export. Because requirements for flow export listed in 228 further sections below are derived from these applications, their 229 selection is crucial. The goal of this requirements document is not 230 to cover all possible applications with all their flow export 231 requirements, but to cover applications which are considered to be of 232 significant importance in today's or future IP networks, and for 233 which requirements can be met with reasonable technical effort. 235 Please note, that the described applications can have a large number 236 of differing implementations. Requirement details or the weighting of 237 requirements could differ for specific implementations. Therefore we 238 derive the requirements from the general functionality of the 239 selected applications. 241 The list of applications should lead to a better understanding of the 242 requirements which is particularly important when designing or 243 implementing traffic flow measuring functions. A detailed overview of 244 which requirement was derived from which application(s) is given in 245 the appendix. 247 3.1. Usage-based Accounting 249 Several new business models for selling IP service and IP-based 250 services are currently under investigation. Beyond flat rate services 251 which do not need accounting, accounting for these models can be 252 based on time or volume. Accounting data can serve as input for 253 billing systems. Accounting can be performed per user or per user 254 group, it can be performed just for basic IP service or individually 255 per high-level service and/or per content type delivered. For 256 advanced/future services, accounting may also be performed per class 257 of service, per application, per time of day, per used (label 258 switched) path, etc. 260 3.2. Traffic Profiling 262 Traffic profiling is a process of characterizing IP flows and flow 263 aggregates by using a model that represents key parameters of the 264 flows such as flow duration, volume, time and burstiness. It is a 265 prerequisite for network planning, network dimensioning, trend 266 analysis, developing business models, and other activities. It 267 heavily depends on the particular traffic profiling objective(s) what 268 statistics and accuracy are required from the measurements. Typical 269 information needed for traffic profiling is the distribution of used 270 services and protocols in the network, the amount of packets of a 271 specific type (e.g. percentage of IPv6 packets) and specific flow 272 profiles. 274 Since objectives for traffic profiling can vary, this application 275 requires a high flexibility of the measurement infrastructure, 276 especially regarding the options for measurement configuration and 277 packet classification. 279 Traffic Engineering (TE) comprises methods for measurement, modeling, 280 characterization and control of a network. The goal of TE is the 281 optimization of network resource utilization and traffic performance 282 [RFC2702]. Since control and administrative reaction to measurement 283 results requires access to the involved network nodes, TE mechanisms 284 and the required measurement function usually are performed within 285 one administrative domain. Typical parameters required for TE are 286 link utilization, load between specific network nodes, number, size 287 and entry/exit points of the active flows and routing information. 289 3.3. Attack/Intrusion Detection 291 Capturing of flow information plays an important role for network 292 security, both for detection of security violation, and for 293 subsequent defense. In case of a Denial of Service (DOS) attack, flow 294 monitoring can allow detection of unusual load situations or 295 suspicious flows. In a second step, flow analysis can be performed in 296 order to gather information about the attacking flows, and for 297 deriving a defense strategy. 299 Intrusion detection is a potentially more demanding application which 300 would not only look at specific characteristics of flows, but that 301 may also use a stateful packet flow analysis for detecting specific, 302 suspicious activities, or unusually frequent activities. Such 303 activities may be characterized by specific communication patterns, 304 detectable by characteristic sequences of certain packet types. 306 3.4. QoS Monitoring 308 QoS monitoring is the non-intrusive (passive) measurement of quality 309 parameters for single flows or traffic aggregates. In contrast to 310 intrusive (active) measurements, non-intrusive measurements utilize 311 the existing traffic in the network for QoS analysis. Since no test 312 traffic is sent, non-intrusive measurements can only be applied in 313 situations where the traffic of interest is already present in the 314 network. One example application is the validation of QoS parameters 315 negotiated in a service level specification (SLS). 317 Non-intrusive measurements cannot provide the kind of controllable 318 experiments that can be achieved with active measurements. On the 319 other hand non-intrusive measurements do not suffer from undesired 320 side effects caused by sending test traffic (e.g. additional load, 321 potential differences in treatment of test traffic and real customer 322 traffic). 324 QoS monitoring often requires the correlation of data from multiple 325 measurement instances (e.g. for measuring one-way metrics). This 326 requires proper clock synchronization of the involved measurement 327 instances. For some measurements packet events at the different 328 measurement points must be correlated. For this, the provisioning of 329 post-processing functions (e.g. the generation of packet IDs) at the 330 measurement instances would be useful. Furthermore, QoS monitoring 331 can lead to a huge amount of measurement result data. Therefore it 332 would highly benefit from mechanisms to reduce the measurement data, 333 like aggregation of results and flow sampling. 335 Please note that not all requirements for QoS monitoring are covered 336 by the IPFIX requirements specified in the following sections. The 337 IPFIX requirements are targeted at per flow information including 338 summaries of per-packet properties for packets within a flow, but not 339 per-packet information itself. For example jitter measurement 340 requires timestamping each packet and reporting of all timestamps of 341 a flow, but the IPFIX requirements only cover timestamps of first and 342 last packet of a flow. 344 4. Distinguishing Flows 346 Packets are mapped to flows by evaluating their properties. Packets 347 with common properties are considered to belong to the same flow. A 348 packet showing at least one difference in the set of properties is 349 considered to belong to a different flow. 351 The following subsections list a set of properties which a metering 352 process MUST, SHOULD, or MAY be able to evaluate for mapping packets 353 to flows. Please note that requiring the ability to evaluate a 354 certain property does not imply that this property must be evaluated 355 for each packet. 357 In other words, meeting the IPFIX requirements means that the 358 metering process in general must be able, via its configuration, to 359 somehow support to distinguish flows via all the MUST fields, even if 360 in certain circumstance/for certain applications, only a subset of 361 the MUST fields is needed and only a subset of the MUST fields is 362 effectively used to distinguish flows. 364 Which combination of properties is used for distinguishing a flow in 365 a particular measurement and how these properties are evaluated 366 depends on the configuration of the metering process. The configured 367 choice of evaluated properties strongly depends on the environment 368 and purpose of the measurement and on the information required by the 369 collector. 371 For specific deployments, only a subset of the REQUIRED properties 372 listed below can be used to distinguish flows, for example in order 373 to aggregate the flow records and reduce the number of flow records 374 exported. On the other hand, some other deployments will require 375 distinguishing flows by some extra parameters, like for example the 376 TTL field of the IP header or the BGP Autonomous Systems. 378 4.1. Interfaces 380 The metering process MUST be able to separate flows by the incoming 381 interface or by the outgoing interface or by both of them. 383 4.2. IP Header Fields 385 The metering process MUST, SHOULD, or MAY be able to separate flows 386 by the following fields of the IP header as indicated. 388 1. source IP address (MUST) 390 2. destination IP address (MUST) 392 3. protocol type (TCP,UDP,ICMP,...) (MUST) 394 4. IP version number (SHOULD) 395 This requirement only applies if the the observation point is 396 located at a device that is supporting more than one version of 397 IP. 399 For source address and destination address, separating by full match 400 MUST be supported as well as separation by a partial match (for 401 example subnet masking). 403 4.3. Transport Header Fields 405 The metering process MUST be able to separate flows by the port 406 numbers of the transport header in case of TCP or UDP being used as 407 transport protocol. Both, source and destination port number MUST be 408 supported for distinguishing flows, individually as well as in 409 combination. 411 4.4. MPLS Label 413 If the observation point is located at a device supporting 414 Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering 415 process MUST be able to separate flows by the MPLS label. 417 4.5. DiffServ Code Point 419 If the observation point is located at a device supporting 420 Differentiated Services (DiffServ) then the metering process MUST be 421 able to separate flows by the DiffServ Code Point (DSCP, see 422 [RFC2474]). 424 4.6. Header Compression and Encryption 426 If header compression or encryption is used, the metering process 427 might not be able to access all header fields. For packets with 428 compressed or encrypted headers, the requirements stated in this 429 section 4 MUST be met for observation points at end points of header 430 compression or of packet encryption, but they do not need to be met 431 for observation points between the end points. 433 5. Metering Process 435 The following are requirements for the metering process. All 436 measurements MUST be conducted from the point of view of the 437 observation point. 439 5.1. Reliability 441 The metering process MUST either be reliable or missing reliability 442 MUST be known and indicated. The metering process is reliable if each 443 packet passing the observation point is measured according to the 444 configuration of the metering process. If, e.g. due to some overload, 445 not all passing packets can be included into the metering process, 446 then the metering process MUST be able to detect this failure and to 447 report about it. 449 5.2. Sampling 451 Sampling describes the systematic or random selection of a subset of 452 elements (the sample) out of a set of elements (the parent 453 population). Usually the purpose of applying sampling techniques is 454 to estimate a parameter of the parent population by using only the 455 elements of the subset. Sampling techniques can be applied for 456 instance to select a subset of packets out of all packets of a flow 457 or to select a subset of flows out of all flows on a link. Sampling 458 methods differ in their sampling strategy (e.g. systematic or random) 459 and in the event that triggers the selection of an element. The 460 selection of one packet can for instance be triggered by its arrival 461 time (time-based sampling), by its position in the flow (count-based 462 sampling) or by the packet content (content-based sampling). 464 The metering process MAY support measuring traffic by packet 465 sampling. If sampling is supported the sampling configuration MUST be 466 well defined. The sampling configuration includes the sampling method 467 and all its parameters. 469 If the sampling configuration is changed during operation, the new 470 sampling configuration with its parameters MUST be indicated to all 471 collectors receiving the affected flow records. 473 In case of any change in the sampling configuration, all flow records 474 metered by the previous sampling configuration MUST be terminated and 475 exported according to the export configuration. The metering process 476 MUST NOT merge the flow records generated with the new sampling 477 configuration with the flow records generated with the previous 478 sampling configuration. 480 5.3. Overload Behavior 482 In case of an overload, for example lack of memory or processing 483 power, the metering process MAY change in order to cope with the lack 484 of resources. Possible reactions include: 486 - Reduce the number of flows to be measured. This can be achieved 487 by more coarse grained flow measurement or by a restriction of 488 the flow accounts to a subset of the set of original ones. 490 - Switch to sampling packets before they are processed by the 491 metering process or - if sampling is already performed - reduce 492 the sampling rate. 494 - Stop metering. 496 - Reducing the resource usage of competing processes on the same 497 device. Example: reducing the packet forwarding throughput 499 Overload behavior is not restricted to the four options listed above. 500 But in case the overload behavior has an impact on the metering 501 process or the export process, the overload behavior MUST be clearly 502 defined and the collector MUST be able to distinguish the flow 503 records exported before and after the metering process behavior 504 change: In case of any change of the meter's behavior, all flow 505 records metered by the previous behavior MUST be terminated and 506 exported according to the export configuration. The metering process 507 MUST not merge the flow records generated with the new behavior with 508 the flow records generated with the previous behavior. 510 5.4. Timestamps 512 The metering process MUST be able to generate timestamps for the 513 first and the last observed packet of a flow. The timestamp 514 resolution MUST be at least the one of the sysUpTime [RFC1213], which 515 is one centisecond. 517 5.5. Time Synchronization 519 Metering processes and collectors SHOULD be time-synchronized with 520 each other. Using NTP or GPS are possible ways of achieving this. 521 However selecting a method for time synchronization is not in the 522 scope of this document. 524 5.6. Timeout 526 The metering process MUST be able to detect flow timeout. A flow is 527 considered to be timed out if no packet of this flow has been 528 observed for a given timeout interval. The metering process MAY 529 support means for detecting the end of a flow before a time out 530 occurs, for example by detecting the FIN or RST bits in a TCP 531 connection. The procedure for detecting a flow timeout MUST be 532 clearly defined. 534 5.7. Ignore Port Copy 536 The metering process MAY be able to ignore packets which are 537 generated by a port copy function acting at the device where the 538 observation point of a flow is located. 540 6. Data Export 542 The following are requirements for exporting measured flow data out 543 of the exporter. Beside requirements on the data transfer, we 544 separate requirements concerning the information model from 545 requirements concerning the data model. Furthermore, we list 546 requirements on reporting times and events and on anonymization of 547 records. 549 6.1. Information Model 551 The information model for the flow information export is the list of 552 attributes of a flow to be contained in the report (including the 553 semantics of the attributes). 555 This section lists attributes an export process MUST or MAY be able 556 to report. This does not imply that each exported flow records MUST 557 contain all REQUIRED attributes. But it implies that it MUST be 558 possible to configure the export process in a way that the 559 information contained in all of the REQUIRED attributes of each 560 exported flow is transmitted from the export process to the receiving 561 collecting process(es). 563 In other words, meeting the IPFIX requirements means that the export 564 process in general must be able, via its configuration, to somehow 565 support to report all the MUST fields, even if in certain 566 circumstance or for certain applications, only a subset of the MUST 567 fields is needed and only a subset of the MUST fields is effectively 568 reported. 570 Beyond that, the export process might offer to report also further 571 attributes not mentioned here. A particular flow record may contain 572 some of the "REQUIRED" attributes as well as some additional ones, 573 for example covering future technologies. 575 This document does not impose that the following attributes would 576 reported for every single flow records, especially for repetitive 577 attributes. For example, if the observation point is the incoming 578 packet stream at IP interface with the ifIndex value 3, then this 579 observation point does not have to be exported as part of every 580 single flow record. Exporting it just once might give sufficient 581 information to the collecting process. 583 The export process MUST be able to report the following attributes 584 for each measured flow: 586 1. IP version number 587 This requirement only applies if the observation point is 588 located at a device supporting more than one version of IP. 589 2. source IP address 590 3. destination IP address 591 4. IP protocol type (TCP,UDP,ICMP,...) 592 5. source TCP/UDP port number 593 6. destination TCP/UDP port number 594 7. input interface (ifIndex) 595 This requirement does not apply if the observation point is 596 located at a probe device. 597 8. output interface (ifIndex) 598 This requirement does not apply if the observation point is 599 located at a probe device. This requirement does not apply in 600 case of multicast flow records. 601 9. packet counter 602 If a packet is fragmented, each fragment is counted as an 603 individual packet. 604 10. byte counter 605 Which bytes of a packet are counted MUST be defined exactly. 606 11. in case of IPv4: Type of Service 607 10. in case of IPv6: Flow Label 608 11. if BGP is supported at the observation point: BGP AS number 609 12. if MPLS is supported at the observation point: MPLS label 610 13. if DiffServ is supported at the observation point: DSCP 611 14. timestamp of the first packet of the flow 612 15. timestamp of the last packet of the flow 613 16. if sampling is used: sampling configuration 614 17. unique identifier of the observation point 615 18. unique identifier of the export process 617 The export process MAY be able to report the following attributes for 618 each measured flow: 620 20. Time To Live 621 21. IP header flags 622 22. TCP header flags 623 23. dropped packet counter at the observation point 624 If a packet is fragmented, each fragment MUST be counted as an 625 individual packet. 626 24. fragmented packet counter 627 counter of all packets for which the fragmented bit is set in 628 the IP header 630 25. multicast replication factor 631 the number of outgoing packets originating from a single 632 incoming multicast packet 634 6.2. Data Model 636 The data model describes how information is represented in flow 637 records. 639 The data model MUST be extensible for future attributes to be added. 640 Even if a set of attributes is fixed in the flow record, the data 641 model MUST provide a way of extending the record by configuration or 642 for certain implementations. 644 The data model used for exporting flow information MAY be flexible 645 concerning the flow attributes contained in flow records. A flexible 646 record format would offer the possibility of defining records in a 647 flexible (customizable) way regarding the number and type of 648 contained attributes. 650 The Data Model SHOULD be independent of the underlying transport 651 protocol, i.e. the data transfer. 653 6.3. Data Transfer 655 Requirements for the data transfer include reliability and security 656 requirements. These requirements do not apply to the export process 657 alone, but also to the transport network. Consequently, the export 658 process does not necessarily have to guarantee that all requirements 659 are met. Particularly if the security requirements are already 660 guaranteed by the network used for data transfer, then these 661 requirements do not have to be considered anymore by the export 662 process. Therefore, these requirements are OPTIONAL for the export 663 process, although they may be REQUIRED for the data transfer as 664 specified in the appendix. 666 6.3.1. Congestion Awareness 668 For the data transfer, a congestion aware protocol MUST be supported. 670 6.3.2. Reliability 672 Absence of reliability, for example caused by export packet loss or 673 export packet reordering, of the data transfer MUST be indicated. 675 Please note that if an unreliable transport protocol is used, 676 reliability can be provided by higher layers. In such a case only 677 lack of overall reliability MUST be indicated. For example reordering 678 could be dealt with by adding a sequence number to each packet. 680 6.3.3. Security 682 Confidentiality of flow specific data transferred from an export 683 process to a collecting process SHOULD be ensured. 685 Integrity of flow specific data transferred from an export process to 686 a collecting process MUST be ensured. 688 Authenticity of flow specific data transferred from an export process 689 to a collecting process MUST be ensured. 691 See more about Security in the "Security Considerations" section 10, 692 from which the 3 requirements above are deducted. 694 6.4. Push and Pull Mode Reporting 696 In general, there are two ways of deciding on reporting times: push 697 mode and pull mode. In push mode, the export process decides without 698 an external trigger on when to send a report on measured flows. In 699 pull mode, sending a report is triggered by an explicit request from 700 a collector. The export process MUST support push mode reporting, it 701 MAY support pull mode reporting. 703 6.5. Regular Reporting Interval 705 The export process SHOULD be capable of reporting measured traffic 706 data regularly according to a given interval length. 708 6.6. Notification on Specific Events 710 The export process MAY be capable of sending notifications to a 711 collecting process, if a specific event occurs. Such an event can be 712 the arrival of the first packet of a new flow, or the termination of 713 a flow after flow timeout. 715 6.7. Anonymization 717 The export process MAY be capable of anonymizing source and 718 destination IP addresses in flow data before exporting them. It MAY 719 support anonymization of port numbers and other fields. Please note 720 that anonymization is not originally an application requirement, but 721 derived from general requirements for treatment of traffic within a 722 network. 724 7. Configuration 726 The metering process MUST provide a way of configuring traffic 727 measurement. The following parameters of the metering process SHOULD 728 be configurable: 730 1. specification of the observation point 731 e.g. an interface or a list of interfaces to be monitored. 732 2. specifications of flows to be metered 733 3. flow timeouts 735 The following parameters MAY be configurable: 737 4. sampling method and parameters, if feature is supported 738 5. overload behavior 740 The export process MUST provide a way of configuring the data export. 741 The following parameters of the export process SHOULD be 742 configurable: 744 1. reporting data format 745 Specifying the reporting data format SHOULD include a selection 746 of attributes to be reported for each flow. 747 2. the collecting process(es) to which flows are reported 748 3. notifications to be sent to the collecting process(es) 749 4. flow anonymization 750 Only applicable if the export process supports flow 751 anonymization. 753 If configuration is done remotely, security of the configuration 754 SHOULD be supported including confidentiality, integrity and 755 authenticity. The means used for remote configuration are out of the 756 scope of this document. 758 8. General Requirements 760 8.1. Openness 762 IPFIX specifications SHOULD be open to future technologies. This 763 includes extensibility of configuration of measurement and reporting. 765 Openness is also required concerning the extensibility of the data 766 model, as stated in section 6.2. 768 8.2. Scalability Concerning the Number of Export Processes 770 Data collection from hundreds of different export processes MUST be 771 supported. The collecting process MUST be able to distinguish several 772 hundred export processes by their identifiers. 774 8.3. Several Collectors 776 The export process MAY be able to export flow information to more 777 than one collecting process. 779 9. Special Device Considerations 781 This document is intended to avoid constraining the architecture of 782 probes, routers, and other devices hosting observation points, 783 metering processes, export processes, or collecting processes. It 784 can be expected that typically observation point, metering process, 785 and export process are co-located at a single device. However, the 786 requirements defined in this document do not exclude devices that 787 derive from this configuration. Figure 2 shows some examples. 789 +---+ +-----+ +---------+ +---------+ 790 | E-+-> | E--+-> | E----+-> <-+--E E--+-> 791 | | | | | | | / \ | | | | | 792 | M | | M | | M M | | M M | 793 | | | | /|\ | | /|\ /|\ | | /|\ /|\ | 794 | O | | OOO | | OOO OOO | | OOO OOO | 795 +---+ +-----+ +---------+ +---------+ 796 Probe Basic Complex Multiple 797 Router Router Exporters 799 +---+ +---+ +---+ 800 | E-+-> | E-+-> | E-+------------->---+ 801 | | | | | | | | | +---+ +-+-----+ 802 +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> 803 | | | | | | | | | | +---+ +-+-----+ 804 +-+-+ +-+-+ | O | | M | | E-+->---+ 805 | | | | +---+ | | | | | | 806 | M | +-+-+ | O | | M | 807 | | | | | | +---+ | | | +-----+ 808 | O | | O | | O | ->-+-C-E-+-> 809 +---+ +---+ +---+ +-----+ 811 Protocol Remote Concentrator Proxy 812 Converter Observation 814 Figure 2: IPFIX-related Devices 816 All examples are composed of one or more of the following elements: 817 observation point (O), full or partial metering process (M), export 818 process (E), collecting process (C). The observation shown in the 819 figure are always the most fine-granular ones supported by the 820 respective device. 822 A very simple device is a probe. It contains on a single observation 823 point, a single metering process, and a single export process. 825 A basic router extends this structure by multiple observation point. 826 Here, the observation point of a flow may be one of the displayed 827 most fine-granular observation points, but also it may be a set of 828 them. 830 A more complex router may host more than one metering process, for 831 example one per line card. Please note that here, the observation 832 point of a single flow cannot exceed the set of most fine-granular 833 observation points linked to a single metering process, because only 834 the metering process can merge packets observed at different fine- 835 granular observation points to a joint flow. An observation point 836 containing all most fine-granular observation points of this router 837 is not possible with this structure. 839 Alternatively, a complex router may host different export processes 840 for flow records generated by different metering processes. 842 A protocol converter makes use of a metering process that can be 843 accessed only by another protocol than the one defined for IPFIX, for 844 example the SNMP and the Meter MIB module [RFC2720]. Then the 845 exporter receives flow record from a remote metering process and 846 exports these records using the IPFIX protocol. 848 Another choice is remote packet observation. Packet header captured 849 at an observation point may be exported as raw data to a device 850 hosting metering process and export process. 852 An intermediate structure between protocol converter and remote 853 observation (not shown in the Figure) would be a split metering 854 process, for example performing timestamping and sampling at the 855 device hosting the observation point and performing packet 856 classification at another device hosting the export process. 858 A concentrator receives flow records via the IPFIX protocol, merges 859 them into higher aggregated flows and exports the resulting flows 860 again using the IPFIX protocol. Please note that for the final flow 861 records the observation point potentially includes all most fine- 862 granular observation points of all first level devices. The metering 863 process of the final flow records is composed by the (partial) 864 metering processes at the first level devices and the partial 865 metering process at the concentrator. 867 Finally, a very simple IPFIX-related device is a proxy. It just 868 receives flow records using the IPFIX protocol and sends them further 869 using the same protocol. A proxy might be useful for traversing 870 firewalls or other gateways. 872 10. Security Considerations 874 An IPFIX protocol must be capable to transport data over the public 875 Internet. Therefore it cannot be excluded that an attacker captures 876 or modifies packets or inserts additional packets. 878 This section describes security requirements for IPFIX. Like other 879 requirements, the security requirements differ among the considered 880 applications. The incentive to modify collected data for accounting 881 or intrusion detection for instance is usually higher than the 882 incentive to change data collected for traffic profiling. A detailed 883 list of the required security features per application can be found 884 in the appendix. 886 The suggestion of concrete solutions for achieving the required 887 security properties should be part of an IPFIX architecture and 888 protocol is out of scope of this document. Also methods for remote 889 configuration of the metering processes and export processes out of 890 scope. Therefore, threats that are caused by data exchange for remote 891 configuration are not considered here. 893 The following potential security hazards for an IPFIX protocol can be 894 identified: disclosure of IP flow information, forgery of flow 895 records, and Denial of Service (DoS) attacks. 897 10.1. Disclosure of Flow Information Data 899 The content of data exchanged by an IPFIX protocol (for example IPFIX 900 flow records) should be kept confidential between the involved 901 parties (export process and collecting process). Observation of IPFIX 902 flow records gives an attacker information about the active flows in 903 the network, communication endpoints and traffic patterns. This 904 information cannot only be used to spy out user behavior but also to 905 plan and conceal future attacks. Therefore, the requirements 906 specified in section 6.3.3. include confidentiality of the 907 transferred data. This can be achieved for instance by encryption. 909 10.2. Forgery of Flow Records 911 If flow records are used in accounting and security applications, 912 there are potentially strong incentives to forge exported IPFIX flow 913 records (for example to save money or prevent the detection of an 914 attack). This can be done either by altering flow records on the path 915 or by injecting forged flow records that pretend to be originated by 916 the original export process. In order to make an IPFIX protocol 917 resistant against such attacks, authentication and integrity must be 918 provided, as specified in section 6.3.3. 920 Special caution is required if security applications rely on flow 921 measurements. With forged flow records it is possible to trick on 922 security applications. It is for instance possible to pretend that a 923 DoS attack happens without even launching a real attack. 925 10.3. Denial of Service (DoS) Attacks 927 DoS attacks on routers or other middleboxes that have the IPFIX 928 protocol implemented would also affect the IPFIX protocol and impair 929 the sending of IPFIX records. Nevertheless, since such hazards are 930 not induced specifically by the IPFIX protocol the prevention of such 931 attacks is out of scope of this document. 933 Nevertheless IPFIX itself also causes potential hazards for DoS 934 attacks. All processes that expect the reception of traffic can be 935 target of a DoS attack. With the IPFIX export process this is only 936 the case if it supports the pull mode (which can be an optional 937 feature of the future IPFIX protocol according to this document). The 938 collecting process always expects data and therefore can be flooded 939 by forged flow records. 941 11. Acknowledgments 943 We like to thank all the people contributing to the requirements 944 discussion on the mailing list for a lot of valuable comments. 946 12. References 948 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 949 RFC 2026, October 1996. 951 [RFC3234] B. Carpenter, "Middleboxes: taxonomy and issues", RFC 3234, 952 February 2002. 954 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 955 Requirement Levels", RFC 2119, March 1997. 957 [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 958 "Requirements for Traffic Engineering Over MPLS", RFC 2702, 959 September 1999. 961 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 962 Switching Architecture", RFC 3031, January 2001. 964 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the 965 Differentiated Services Field (DS Field) in the IPv4 and 966 IPv6 Headers", RFC 2474, December 1998. 968 [RFC1213] K. McCloghrie, M. Rose. "Management Information Base for 969 Network Management of TCP/IP-based internets: MIB-II", RFC 970 1213, March 1991. 972 [RFC2720] N. Brownlee. "Traffic Flow Measurement: Meter MIB", RFC 973 2720, October 1999. 975 13. Authors' Addresses 977 Juergen Quittek 978 NEC Europe Ltd., Network Laboratories 979 Adenauerplatz 6 980 69115 Heidelberg 981 Germany 983 Phone: +49 6221 90511-15 984 EMail: quittek@ccrle.nec.de 986 Tanja Zseby 987 Fraunhofer Institute for Open Communication Systems (FOKUS) 988 Kaiserin-Augusta-Allee 31 989 10589 Berlin 990 Germany 992 Phone: +49 30 3463 7153 993 Email: zseby@fokus.fhg.de 995 Benoit Claise 996 Cisco Systems 997 De Kleetlaan 6a b1 998 1831 Diegem 999 Belgium 1001 Phone: +32 2 704 5622 1002 Email: bclaise@cisco.com 1004 Sebastian Zander 1005 Fraunhofer Institute for Open Communication Systems (FOKUS) 1006 Kaiserin-Augusta-Allee 31 1007 10589 Berlin 1008 Germany 1010 Phone: +49 30 3463 7287 1011 Email: zander@fokus.fhg.de 1013 Georg Carle 1014 Fraunhofer Institute for Open Communication Systems (FOKUS) 1015 Kaiserin-Augusta-Allee 31 1016 10589 Berlin 1017 Germany 1019 Phone: +49 30 3463 7149 1020 Email: carle@fokus.fhg.de 1022 K.C. Norseth 1023 Consultant 1024 934 S. Palos Verdes Dr. 1025 Kaysville, Utah 84037 USA 1027 Phone: 801.546.3316 1028 Email: kcn@norseth.com 1030 14. Full Copyright Statement 1032 Copyright (C) The Internet Society (2001). All Rights Reserved. 1034 This document and translations of it may be copied and furnished to 1035 others, and derivative works that comment on or otherwise explain it 1036 or assist in its implementation may be prepared, copied, published 1037 and distributed, in whole or in part, without restriction of any 1038 kind, provided that the above copyright notice and this paragraph are 1039 included on all such copies and derivative works. However, this 1040 document itself may not be modified in any way, such as by removing 1041 the copyright notice or references to the Internet Society or other 1042 Internet organizations, except as needed for the purpose of 1043 developing Internet standards in which case the procedures for 1044 copyrights defined in the Internet Standards process must be 1045 followed, or as required to translate it into languages other than 1046 English. 1048 The limited permissions granted above are perpetual and will not be 1049 revoked by the Internet Society or its successors or assigns. 1051 This document and the information contained herein is provided on an 1052 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1053 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1054 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1055 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1056 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1058 Appendix: Derivation of Requirements from Applications 1060 The following table documents, how the requirements stated in 1061 sections 3-7 are derived from requirements of the applications listed 1062 in section 2. 1064 Used abbreviations: 1065 M = MUST 1066 S = SHOULD 1067 O = MAY (OPTIONAL) 1068 - = DONT CARE 1070 -----------------------------------------------------------------------. 1071 IPFIX | 1072 ----------------------------------------------------------------. | 1073 E: QoS Monitoring | | 1074 ----------------------------------------------------------. | | 1075 D: Attack/Intrusion Detection | | | 1076 ----------------------------------------------------. | | | 1077 C: Traffic Engineering | | | | 1078 ----------------------------------------------. | | | | 1079 B: Traffic Profiling | | | | | 1080 ----------------------------------------. | | | | | 1081 A: Usage-based Accounting | | | | | | 1082 ----------------------------------. | | | | | | 1083 | | | | | | | 1084 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1085 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1086 | 4. | DISTINGUISHING FLOWS | 1087 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1088 | 4. | Combination of | M | M | M | M | M | M | 1089 | | required attributes | | | | | | | 1090 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1091 | 4.1. | in/out IF | S | M | M | S | S | M | 1092 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1093 | 4.2. | src/dst address | M | M | M | M | M | M | 1094 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1095 | 4.2. | Masking of IP adresses | M | M | M | M | M | M | 1096 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1097 | 4.2. | transport protocol | M | M | - | M | M | M | 1098 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1099 | 4.2. | version field | - | S | S | O | O | S | 1100 | | | | | (b) | | | | 1101 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1102 | 4.3. | src/dst port | M | M | - | M | M | M | 1103 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1104 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1105 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1106 | 4.4. | MPLS label (a) | S | S | M | O | S | M | 1107 | | | | | (c) | | | | 1108 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1109 | 4.5. | DSCP (a) | M | S | M | O | M | M | 1110 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1111 | 5. | METERING PROCESS | 1112 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1113 | 5.1. | Reliability | M | S | S | S | S | | 1114 |-------+-------------------------+-----+-----+-----+-----+-----+ M | 1115 | 5.1. | Indication of | - | M | M | M | M | | 1116 | | missing reliability | | | | | | | 1117 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1118 | 5.2. | Sampling (g) | O | O | O | O | O | O | 1119 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1120 | 5.3. | Overload Behavior | O | O | O | O | O | O | 1121 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1122 | 5.4. | Timestamps | M | O | O | S | M | M | 1123 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1124 | 5.5. | Time synchronization | S | S | S | S | S | S | 1125 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1126 | 5.6. | Flow timeout | M | S | - | O | O | M | 1127 | | | (d) | | | | | | 1128 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1129 | 5.7. | Ignore port copy | O | O | O | O | O | O | 1130 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1131 | 6. | DATA EXPORT | 1132 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1133 | 6.1. | INFORMATION MODEL | 1134 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1135 | 6.1. | IP Version | - | M | M | O | O | M | 1136 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1137 | 6.1. | src/dst address | M | M | M | M | M | M | 1138 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1139 | 6.1. | transport protocol | M | M | - | M | M | M | 1140 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1141 | 6.1. | src/dst port | M | M | - | M | M | M | 1142 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1143 | 6.1. | Packet counter (h) | S | M | M | S | S | M | 1144 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1145 | 6.1. | Byte counter | M | M | M | S | S | M | 1146 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1147 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1148 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1149 | 6.1. | Dropped Packet | O | M | M | S | M | M | 1150 | | Counter (h,i) | | | | | | | 1151 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1152 | 6.1. | ToS Byte | M | S | M | O | M | M | 1153 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1154 | 6.1. | Flow Label | M | S | M | O | M | M | 1155 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1156 | 6.1. | BGP AS# | - | S | M | - | - | M | 1157 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1158 | 6.1. | MPLS label (a) | S | S | M | O | S | M | 1159 | | | | | (c) | | | | 1160 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1161 | 6.1. | DSCP (a) | M | S | M | O | M | M | 1162 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1163 | 6.1. | Timestamps for | M | O | O | S | S | M | 1164 | | first/last packet | | | | | | | 1165 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1166 | 6.1. | Sampling configuration | M | M | M | M | M | M | 1167 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1168 | 6.1. | observation point | M | M | M | M | M | M | 1169 | | identifier | | | | | | | 1170 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1171 | 6.1. | export process | M | M | M | M | M | M | 1172 | | identifier | | | | | | | 1173 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1174 | 6.1. | TTL | O | O | O | O | O | O | 1175 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1176 | 6.1. | IP header flags | - | O | O | O | O | O | 1177 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1178 | 6.1. | TCP header flags | - | O | O | O | - | O | 1179 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1180 | 6.1. | Fragment counter | - | O | O | O | O | O | 1181 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1182 | 6.1. | Multicast | O | O | O | - | - | O | 1183 | | replication factor | | | | | | | 1184 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1185 | 6.2. | DATA MODEL | 1186 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1187 | 6.2. | Flexibility | O | O | O | O | O | O | 1188 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1189 | 6.2. | Extensibility | M | M | M | M | M | M | 1190 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1191 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1192 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1193 | 6.3. | DATA TRANSFER | 1194 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1195 | 6.3.1.| Congestion aware | M | M | M | M | M | M | 1196 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1197 | 6.3.2.| Reliability | M | S | S | S | S | M | 1198 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1199 | 6.3.3.| Confidentiality | S | S | S | S | S | S | 1200 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1201 | 6.3.4.| Integrity | M | M | M | M | M | M | 1202 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1203 | 6.3.5.| Authenticity | M | M | M | M | M | M | 1204 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1205 | 6.4. | REPORTING TIMES | 1206 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1207 | 6.4. | Push mode | M | O | O | M | S | M | 1208 | | | | (e) | (e) | |(e,f)| | 1209 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1210 | 6.4. | Pull mode | O | O | O | O | O | O | 1211 | | | | (e) | (e) | | (e) | | 1212 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1213 | 6.4.1.| Regular Interval | S | S | S | S | S | S | 1214 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1215 | 6.6. | Notifications | O | O | O | O | O | O | 1216 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1217 | 6.7. | Anonymization | O | O | O | O | O | O | 1218 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1219 | 7. | CONFIGURATION | 1220 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1221 | 7. | Config Measurement | M | M | M | M | M | M | 1222 | | & Data Export | | | | | | | 1223 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1224 | 7. | Config Observation Point| S | S | S | S | S | S | 1225 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1226 | 7. | Config Flow | S | S | S | S | S | S | 1227 | | Specifications | | | | | | | 1228 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1229 | 7. | Config Flow Timeouts | S | S | S | S | O | S | 1230 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1231 | 7. | Config Sampling | O | O | O | O | O | O | 1232 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1233 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1234 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1235 | 7. | Config Report | S | S | S | S | S | S | 1236 | | Data Format | | | | | | | 1237 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1238 | 7. | Config | O | O | O | O | O | O | 1239 | | Notifications | | | | | | | 1240 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1241 | 7. | Config Anonymization | O | O | O | O | O | O | 1242 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1243 | 8. | GENERAL REQUIREMENTS | 1244 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1245 | 8.1. | Openness | S | S | S | S | S | S | 1246 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1247 | 8.2. | Scalability: | | | | | | | 1248 | | data collection | M | S | M | O | S | M | 1249 | | from hundreds of | | | | | | | 1250 | | measurement devices | | | | | | | 1251 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1252 | 8.3. | Several Collectors | O | O | O | O | O | O | 1253 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1255 Remarks: 1256 (a) If feature is supported. 1257 (b) The differentiation of IPv4 and IPv6 is for TE of importance. 1258 So we tended to make this a MUST. Nevertheless, a SHOULD seems 1259 to be sufficient to perform most TE tasks and allows us to have 1260 a SHOULD for IPFIX instead of a MUST. 1261 (c) For TE in an MPLS network the label is essential. Therefore a 1262 MUST is given here leading to a MUST in IPFIX. 1263 (d) Precise time-based accounting requires reaction to a flow 1264 timeout. 1265 (e) Either push or pull has to be supported. 1266 (f) Required, in order to immediately report drop indications for 1267 SLA validation. 1268 (g) If sampling is supported the methods and parameters MUST be 1269 well defined. 1270 (h) If a packet is fragmented, each fragment is counted as an 1271 individual packet. 1272 (i) Only if measurement is done on data path i.e. has access to 1273 forwarding decision.