idnits 2.17.1 draft-ietf-ipfix-reqs-16.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? 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.) ** There are 196 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 1500 has weird spacing: '...for the purpo...' -- 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 2004) is 7217 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2119' is mentioned on line 142, but not defined == Unused Reference: 'RFC2119' is defined on line 1404, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 1771 (Obsoleted by RFC 4271) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Quittek 2 draft-ietf-ipfix-reqs-16.txt NEC Europe Ltd. 3 Category: Informational T. Zseby 4 Expires: December 2004 Fraunhofer FOKUS 5 B. Claise 6 Cisco Systems 7 S. Zander 8 Fraunhofer FOKUS 10 June 2004 12 Requirements for IP Flow Information Export 14 16 Status of this Memo 18 This document is an Internet-Draft and is subject to all provisions 19 of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This memo defines requirements for the export of measured IP flow 44 information out of routers, traffic measurement probes and 45 middleboxes. 47 Table of Contents 49 1. Introduction ................................................ 3 50 2. Terminology ................................................. 4 51 2.1. IP Traffic Flow ......................................... 4 52 2.2. Observation Point ....................................... 4 53 2.3. Metering Process ........................................ 5 54 2.4. Flow Record ............................................. 5 55 2.5. Exporting Process ....................................... 6 56 2.6. Collecting Process ...................................... 6 57 3. Applications Requiring IP Flow Information Export ........... 6 58 3.1. Usage-based Accounting .................................. 6 59 3.2. Traffic Profiling ....................................... 7 60 3.3. Traffic Engineering ..................................... 7 61 3.4. Attack/Intrusion Detection .............................. 7 62 3.5. QoS Monitoring .......................................... 8 63 4. Distinguishing Flows ........................................ 9 64 4.1. Encryption .............................................. 9 65 4.2. Interfaces .............................................. 9 66 4.3. IP Header Fields ........................................ 10 67 4.4. Transport Header Fields ................................. 10 68 4.5. MPLS Label .............................................. 10 69 4.6. DiffServ Code Point ..................................... 10 70 5. Metering Process ............................................ 10 71 5.1. Reliability ............................................. 11 72 5.2. Sampling ................................................ 11 73 5.3. Overload Behavior ....................................... 11 74 5.4. Timestamps .............................................. 12 75 5.5. Time Synchronization .................................... 12 76 5.6. Flow Expiration ......................................... 13 77 5.7. Multicast Flows ......................................... 13 78 5.8. Packet Fragmentation .................................... 13 79 5.9. Ignore Port Copy ........................................ 13 80 6. Data Export ................................................. 13 81 6.1. Information Model ....................................... 14 82 6.2. Data Model .............................................. 16 83 6.3. Data Transfer ........................................... 16 84 6.3.1. Congestion Awareness ................................ 16 85 6.3.2. Reliability ......................................... 16 86 6.3.3. Security ............................................ 17 87 6.4. Push and Pull Mode Reporting ............................ 17 88 6.5. Regular Reporting Interval .............................. 18 89 6.6. Notification on Specific Events ......................... 18 90 6.7. Anonymization ........................................... 18 91 7. Configuration ............................................... 18 92 7.1. Configuration of the Metering Process ................... 19 93 7.2. Configuration of the Exporting Process .................. 19 94 8. General Requirements ........................................ 19 95 8.1. Openness ................................................ 19 96 8.2. Scalability ............................................. 20 97 8.3. Several Collecting Processes ............................ 20 98 9. Special Device Considerations ............................... 20 99 10. Security Considerations .................................... 22 100 10.1. Disclosure of Flow Information Data .................... 23 101 10.2. Forgery of Flow Records ................................ 23 102 10.3. Denial of Service (DoS) Attacks ........................ 24 103 11. Acknowledgments ............................................ 24 104 12. Appendix: Derivation of Requirements from Applications ..... 25 105 13. Normative References ....................................... 30 106 14. Informative References ..................................... 30 107 15. Authors' Addresses ......................................... 31 108 16. IPR Notices ................................................ 32 109 17. Full Copyright Statement ................................... 32 111 1. Introduction 113 There are several applications that require flow-based IP traffic 114 measurements. Such measurements could be performed by a router while 115 forwarding the traffic, by a middlebox [RFC3234], or by a traffic 116 measurement probe attached to a line or a monitored port. This memo 117 defines requirements for exporting traffic flow information out of 118 these boxes for further processing by applications located on other 119 devices. They serve as input to the standardization of an IPFIX 120 protcol. 122 In section 3, a selection of such applications is presented. The 123 following sections list requirements derived from these applications. 125 In its early discussions the IPFIX Working Group chose to evaluate 126 existing flow export protocols at the same time as it was developing 127 this 'requirements' document. 129 Flow export, however, is not performed by a protocol acting alone, it 130 also requires a system of co-operating processes. In producing IPFIX 131 requirements, therefore, the Working Group decided to specify what 132 was required by thse various processes - the metering process, the 133 exporting process, etc. In these specifications we use lower-case 134 for the words must, may and should, to indicate that IPFIX 135 implementors have some freedom as to how to meet the requirements. 137 The Working Group's goal is to produce standards-track documents 138 describing the IPFX architecture, i.e. information model and flow 139 export protocol RFCs. As well as meeting the requirements set out in 140 this document, the information model and protocol documents will 141 provide a full specification of the IPFIX system, and will use 142 uppercase [RFC 2119] keywords as is usual in standards-track RFCs. 144 2. Terminology 146 The following terminology is used in this document: 148 2.1. IP Traffic Flow 150 There are several definitions of the term 'flow' being used by the 151 Internet community. Within this document we use the following one: 153 A flow is defined as a set of IP packets passing an observation point 154 in the network during a certain time interval. All packets belonging 155 to a particular flow have a set of common properties. Each property 156 is defined as the result of applying a function to the values of: 158 1. one or more packet header field (e.g. destination IP address), 159 transport header field (e.g. destination port number), or 160 application header field (e.g. RTP header fields [RFC1889]) 162 2. one or more characteristics of the packet itself (e.g. number 163 of MPLS labels, etc...) 165 3. one or more of fields derived from packet treatment (e.g. next 166 hop IP address, the output interface, etc...) 168 A packet is defined to belong to a flow if it completely satisfies 169 all the defined properties of the flow. 171 This definition covers the range from a flow containing all packets 172 observed at a network interface to a flow consisting of just a single 173 packet between two applications with a specific sequence number. 174 Please note that the flow definition does not necessarily match a 175 general application-level end-to-end stream. However, an application 176 may derive properties of application-level streams by processing 177 measured flow data. Also, please note that although packet 178 properties may depend on application headers, there is no requirement 179 defined in this document related to application headers. 181 2.2. Observation Point 183 The observation point is a location in the network where IP packets 184 can be observed. Examples are a line to which a probe is attached, a 185 shared medium such as an Ethernet-based LAN, a single port of a 186 router, or a set of interfaces (physical or logical) of a router. 188 Note that one observation point may be a superset of several other 189 observation points. For example one observation point can be an 190 entire line card. This would be the superset of the individual 191 observation points at the line card's interfaces. 193 2.3. Metering Process 195 The metering process generates flow records. Input to the process 196 are packet headers observed at an observation point and packet 197 treatment at the observation point, for example the selected output 198 interface. The metering process consists of a set of functions that 199 includes packet header capturing, timestamping, sampling, 200 classifying, and maintaining flow records. 202 The maintenance of flow records may include creating new records, 203 updating existing ones, computing flow statistics, deriving further 204 flow properties, detecting flow expiration, passing flow records to 205 the exporting process, and deleting flow records. 207 The sampling function and the classifying function may be applied 208 more than once with different parameters. Figure 1 shows the 209 sequence in which the functions are applied. Sampling is not 210 illustrated in the figure; it may be applied before any other 211 function. 213 packet header capturing 214 | 215 timestamping 216 | 217 v 218 +----->+ 219 | | 220 | classifying 221 | | 222 +------+ 223 | 224 maintaining flow records 225 | 226 v 228 Figure 1: Functions of the metering process 230 2.4. Flow Record 232 A flow record contains information about a specific flow that was 233 metered at an observation point. A flow record contains measured 234 properties of the flow (e.g. the total number of bytes of all packets 235 of the flow) and usually also characteristic properties of the flow 236 (e.g. source IP address). 238 2.5. Exporting Process 240 The exporting process sends flow records to one or more collecting 241 processes. The flow records are generated by one or more metering 242 processes. 244 2.6. Collecting Process 246 The collecting process receives flow records from one or more 247 exporting processes. The collecting process might store received 248 flow records or further process them, but these actions are out of 249 the scope of this document. 251 3. Applications Requiring IP Flow Information Export 253 This section describes a selection of applications requiring IP flow 254 information export. Because requirements for flow export listed in 255 further sections below are derived from these applications, their 256 selection is crucial. The goal of this requirements document is not 257 to cover all possible applications with all their flow export 258 requirements, but to cover applications which are considered to be of 259 significant importance in today's and/or future IP networks, and for 260 which requirements can be met with reasonable technical effort. 262 The list of applications should lead to a better understanding of the 263 requirements which is particularly important when designing or 264 implementing traffic flow metering functions. A detailed overview of 265 which requirement was derived from which application(s) is given in 266 the appendix. 268 Please note that the described applications can have a large number 269 of differing implementations. Requirement details or requirement 270 significance (required (must), recommended (should), optional (may)) 271 could differ for specific implementations and/or for specific 272 application scenarios. Therefore we derive the requirements from the 273 general functionality of the selected applications. Some particular 274 cases will even mandate more stringent requirements than the ones 275 defined in this document. For example, usage-based accounting is 276 certainly the application that will probably mandate the highest 277 degree of reliability amonst the applications discussed below. The 278 reliability reqirements defined in sections 5.1 and 6.3.2. are not 279 sufficient to guarantee the level of reliability that is needed for 280 many usage-based accounting systems. Particular reliability 281 requirements for accounting systems are discussed in [RFC2975]. 283 3.1. Usage-based Accounting 285 Several new business models for selling IP services and IP-based 286 services are currently under investigation. Beyond flat rate 287 services which do not need accounting, accounting can be based on 288 time or volume. Accounting data can serve as input for billing 289 systems. Accounting can be performed per user or per user group, it 290 can be performed just for basic IP service or individually per high- 291 level service and/or per content type delivered. For advanced/future 292 services, accounting may also be performed per class of service, per 293 application, per time of day, per (label switched) path used, etc. 295 3.2. Traffic Profiling 297 Traffic profiling is the process of characterizing IP flows by using 298 a model that represents key parameters of the flows such as flow 299 duration, volume, time and burstiness. It is a prerequisite for 300 network planning, network dimensioning, trend analysis, business 301 model development, and other activities. It depends heavily on the 302 particular traffic profiling objective(s), which statistics, and 303 which accuracy are required from the measurements. Typical 304 information needed for traffic profiling is the distribution of used 305 services and protocols in the network, the amount of packets of a 306 specific type (e.g. percentage of IPv6 packets) and specific flow 307 profiles. 309 Since objectives for traffic profiling can vary, this application 310 requires a high flexibility of the measurement infrastructure, 311 especially regarding the options for measurement configuration and 312 packet classification. 314 3.3. Traffic Engineering 316 Traffic Engineering (TE) comprises methods for measurement, modeling, 317 characterization and control of a network. The goal of TE is the 318 optimization of network resource utilization and traffic performance 319 [RFC2702]. Since control and administrative reaction to measurement 320 results requires access to the involved network nodes, TE mechanisms 321 and the required measurement function usually are performed within 322 one administrative domain. Typical parameters required for TE are 323 link utilization, load between specific network nodes, number, size 324 and entry/exit points of the active flows and routing information. 326 3.4. Attack/Intrusion Detection 328 Capturing flow information plays an important role for network 329 security, both for detection of security violation, and for 330 subsequent defense. In case of a Denial of Service (DOS) attack, 331 flow monitoring can allow detection of unusual situations or 332 suspicious flows. In a second step, flow analysis can be performed 333 in order to gather information about the attacking flows, and for 334 deriving a defense strategy. 336 Intrusion detection is a potentially more demanding application which 337 would not only look at specific characteristics of flows, but may 338 also use a stateful packet flow analysis for detecting specific, 339 suspicious activities, or unusually frequent activities. Such 340 activities may be characterized by specific communication patterns, 341 detectable by characteristic sequences of certain packet types. 343 3.5. QoS Monitoring 345 QoS monitoring is the passive measurement of quality parameters for 346 IP flows. In contrast to active measurements, passive measurements 347 utilize the existing traffic in the network for QoS analysis. Since 348 no test traffic is sent, passive measurements can only be applied in 349 situations where the traffic of interest is already present in the 350 network. One example application is the validation of QoS parameters 351 negotiated in a service level specification. Note that 352 passive/active measurement is also referred to as non- 353 intrusive/intrusive measurement or as measurement of 354 observed/synthetic traffic. 356 Passive measurements cannot provide the kind of controllable 357 experiments that can be achieved with active measurements. On the 358 other hand passive measurements do not suffer from undesired side 359 effects caused by sending test traffic (e.g. additional load, 360 potential differences in treatment of test traffic and real customer 361 traffic). 363 QoS monitoring often requires the correlation of data from multiple 364 observation points (e.g. for measuring one-way metrics). This 365 requires proper clock synchronization of the involved metering 366 processes. For some measurements, flow records and/or notifications 367 on specific events at the different observation points must be 368 correlated, for example the arrival of a certain packet. For this, 369 the provisioning of post-processing functions (e.g. the generation of 370 packet IDs) at the metering processes would be useful. Since QoS 371 monitoring can lead to a huge amount of measurement result data, it 372 would highly benefit from mechanisms to reduce the measurement data, 373 like aggregation of results and sampling. 375 Please note that not all requirements for QoS monitoring are covered 376 by the IPFIX requirements specified in the following sections. The 377 IPFIX requirements are targeted at per flow information including 378 summaries of per-packet properties for packets within a flow, but not 379 per-packet information itself. For example jitter measurement 380 requires timestamping each packet and reporting of all timestamps of 381 a flow, but the IPFIX requirements only cover timestamps of first and 382 last packet of a flow. 384 4. Distinguishing Flows 386 Packets are mapped to flows by evaluating their properties. Packets 387 with common properties are considered to belong to the same flow. A 388 packet showing at least one difference in the set of properties is 389 considered to belong to a different flow. 391 The following subsections list a set of properties which a metering 392 process must, should, or may be able to evaluate for mapping packets 393 to flows. Please note that requiring the ability to evaluate a 394 certain property does not imply that this property must be evaluated 395 for each packet. In other words, meeting the IPFIX requirements 396 means that the metering process in general must be able, via its 397 configuration, to somehow support to distinguish flows via all the 398 must fields, even if in certain circumstances/for certain 399 applications, only a subset of the must fields is needed and 400 effectively used to distinguish flows. 402 Which combination of properties is used for distinguishing flows and 403 how these properties are evaluated depends on the configuration of 404 the metering process. The configured choice of evaluated properties 405 strongly depends on the environment and purpose of the measurement 406 and on the information required by the collecting process. But in 407 any case, it must be ensured that a collecting process is able to 408 clearly identify for each received flow record which set of 409 properties was used for distinguishing this flow from other ones. 411 For specific deployments, only a subset of the required properties 412 listed below can be used to distinguish flows, for example in order 413 to aggregate the flow records and reduce the number of flow records 414 exported. On the other hand, some other deployments will require 415 distinguishing flows by some extra parameters, such as the TTL field 416 of the IP header or the BGP Autonomous System number [RFC1771] of the 417 IP destination address. 419 4.1. Encryption 421 If encryption is used, the metering process might not be able to 422 access all header fields. A metering process must meet the 423 requirements stated in this section 4 only for packets that have the 424 relevant header fields not encrypted. 426 4.2. Interfaces 428 The metering process must be able to separate flows by the incoming 429 interface or by the outgoing interface or by both of them. 431 4.3. IP Header Fields 433 The metering process must be able to separate flows by the following 434 fields of the IP header: 436 1. source IP address 438 2. destination IP address 440 3. protocol type (TCP, UDP, ICMP, ...) 442 For source address and destination address, separating by full match 443 must be supported as well as separation by prefix match. 445 The metering process should be able to separate flows by the IP 446 version number if the observation point is located at a device that 447 is supporting more than one IP version. 449 4.4. Transport Header Fields 451 The metering process must be able to separate flows by the port 452 numbers of the transport header in case of TCP or UDP being used as 453 transport protocol. The metering process should be able to separate 454 flows by the port numbers of the transport header in case of SCTP 455 [RFC2960]. 457 For separation, both, source and destination port number must be 458 supported for distinguishing flows, individually as well as in 459 combination. 461 4.5. MPLS Label 463 If the observation point is located at a device supporting 464 Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering 465 process must be able to separate flows by the MPLS label. 467 4.6. DiffServ Code Point 469 If the observation point is located at a device supporting 470 Differentiated Services (DiffServ) then the metering process must be 471 able to separate flows by the DiffServ Code Point (DSCP, see 472 [RFC2474]). 474 5. Metering Process 476 The following are requirements for the metering process. All 477 measurements must be conducted from the point of view of the 478 observation point. 480 5.1. Reliability 482 The metering process must either be reliable or the absence of 483 reliability must be known and indicated. The metering process is 484 reliable if each packet passing the observation point is metered 485 according to the configuration of the metering process. If, e.g. due 486 to some overload, not all passing packets can be included into the 487 metering process, then the metering process must be able to detect 488 this failure and to report it. 490 5.2. Sampling 492 Sampling describes the systematic or random selection of a subset of 493 elements (the sample) out of a set of elements (the parent 494 population). Usually the purpose of applying sampling techniques is 495 to estimate a parameter of the parent population by using only the 496 elements of the subset. Sampling techniques can be applied for 497 instance to select a subset of packets out of all packets of a flow 498 or to select a subset of flows out of all flows on a link. Sampling 499 methods differ in their sampling strategy (e.g. systematic or random) 500 and in the event that triggers the selection of an element. The 501 selection of one packet can for instance be triggered by its arrival 502 time (time-based sampling), by its position in the flow (count-based 503 sampling) or by the packet content (content-based sampling). 505 The metering process may support packet sampling. If sampling is 506 supported the sampling configuration must be well defined. The 507 sampling configuration includes the sampling method and all its 508 parameters. 510 If the sampling configuration is changed during operation, the new 511 sampling configuration with its parameters must be indicated to all 512 collecting processes receiving the affected flow records. Changing 513 the sampling configuration includes: adding a sampling function to 514 the metering process, removing a sampling function from the metering 515 process, change sampling method, and change sampling parameter(s). 517 In case of any change in the sampling configuration, all flow records 518 metered by the previous sampling configuration must be terminated and 519 exported according to the export configuration. The metering process 520 must not merge the flow records generated with the new sampling 521 configuration with the flow records generated with the previous 522 sampling configuration. 524 5.3. Overload Behavior 526 In case of an overload, for example lack of memory or processing 527 power, the metering process may change its behavior in order to cope 528 with the lack of resources. Possible reactions include: 530 - Reduce the number of flows to be metered. This can be achieved 531 by more coarse-grained flow measurement or by a restriction of 532 the flow records to a subset of the set of original ones. 534 - Start sampling packets before they are processed by the 535 metering process or - if sampling is already performed - reduce 536 the sampling frequency. 538 - Stop metering. 540 - Reducing the resource usage of competing processes on the same 541 device. Example: reducing the packet forwarding throughput 543 Overload behavior is not restricted to the four options listed above. 544 But in case the overload behavior induces a change of the metering 545 process behavior, the overload behavior must be clearly defined. 547 For some flows, the change of behavior might have an impact on the 548 data that would be stored in the associated flow records after the 549 change, for example if the packet classification is changed or the 550 sampling frequency. These flows must be considered as terminated and 551 the associated flow records must be exported separately from new ones 552 generated after the behavior change. The terminated flow records and 553 new ones generated after the behavior change must not be merged by 554 the metering process. The collecting process must be able to 555 distinguish the affected flow records generated before and after the 556 change of behavior. This requirement does not apply to flows and 557 associated flow records not affected by the change of metering 558 process behavior. 560 5.4. Timestamps 562 The metering process must be able to generate timestamps for the 563 first and the last observation of a packet of a flow at the 564 observation point. The timestamp resolution must be at least the one 565 of the sysUpTime [RFC3418], which is one centisecond. 567 5.5. Time Synchronization 569 It must be possible to synchronize timestamps generated by a metering 570 process with Coordinated Universal Time (UTC). 572 Note that the possibility of synchronizing timestamps of each single 573 metering process with UTC implies the possibility of synchronizing 574 timestamps generated by different metering processes. 576 Note that this does not necessarily imply that timestamps generated 577 by the metering process are UTC timestamps. For example, this 578 requirement can be met by using local system clock values as 579 timestamps and adding an additional timestamp when exporting a report 580 to a collecting process. Then the collecting process can synchronize 581 the timestamps by calculating the offset between UTC and the system 582 clock of the metering process. 584 5.6. Flow Expiration 586 The metering process must be able to detect flow expirations. A flow 587 is considered to be expired if no packet of this flow has been 588 observed for a given timeout interval. The metering process may 589 support means for detecting the expiration of a flow before a timeout 590 occurs, for example by detecting the FIN or RST bits in a TCP 591 connection. The procedure for detecting a flow expiration must be 592 clearly defined. 594 5.7. Multicast Flows 596 For multicast flows containing packets replicated to multiple output 597 interfaces, the metering process should be able to maintain discrete 598 flow records per different output interface. For example, the 599 metering process should be able to report an incoming multicast 600 packet that is replicated to four output interfaces in four different 601 flow records that differ by the output interface. 603 5.8. Packet Fragmentation 605 In case of IP packet fragmentation and depending on the 606 classification scheme, only the zero-offset fragment of a single 607 initial packet might contain sufficient information to classify the 608 packet. Note that this fragment should be the first one generated by 609 the router imposing the fragmentation [RFC791], but might not be the 610 first one observed by the IPFIX device, due reordering reasons. The 611 metering process may keep state of IP packet fragmentation in order 612 to map fragments that do not contain sufficient header information 613 correctly to flows. 615 5.9. Ignore Port Copy 617 The metering process may be able to ignore packets which are 618 generated by a port copy function acting at the device where the 619 observation point of a flow is located. 621 6. Data Export 623 The following are requirements for exporting flow records out of the 624 exporting process. Beside requirements on the data transfer, we 625 separate requirements concerning the information model from 626 requirements concerning the data model. Furthermore, we list 627 requirements on reporting times and notification on specific events, 628 and on anonymization of flow records. 630 6.1. Information Model 632 The information model for the flow information export is the list of 633 attributes of a flow to be contained in the report (including the 634 semantics of the attributes). 636 This section lists attributes an exporting process must, should or 637 may be able to report. This does not imply that each exported flow 638 record must contain all required attributes. But it implies that it 639 must be possible to configure the exporting process in a way that the 640 information of all required attributes can be transmitted from the 641 exporting process to the receiving collecting process(es) for each 642 exported flow. 644 In other words, meeting the IPFIX requirements means that the 645 exporting process in general must be able, via its configuration, to 646 somehow support to report all the must fields, even if in certain 647 circumstance or for certain applications, only a subset of the set of 648 all must fields is needed and effectively reported. 650 Beyond that, the exporting process might offer to report further 651 attributes not mentioned here. A particular flow record may contain 652 some of the "required" attributes as well as some additional ones, 653 for example covering future technologies. 655 This document does not impose that the following attributes are 656 reported for every single flow record, especially for repetitive 657 attributes. For example, if the observation point is the incoming 658 packet stream at the IP interface with the ifIndex value 3, then this 659 observation point does not have to be exported as part of every 660 single flow record. Exporting it just once might give sufficient 661 information to the collecting process. 663 The exporting process must be able to report the following attributes 664 for each metered flow: 666 1. IP version number 667 This requirement only applies if the observation point is 668 located at a device supporting more than one version of IP. 669 2. source IP address 670 3. destination IP address 671 4. IP protocol type (TCP,UDP,ICMP,...) 672 5. if protocol type is TCP or UDP: source TCP/UDP port number 673 6. if protocol type is TCP or UDP: destination TCP/UDP port number 674 7. packet counter 675 If a packet is fragmented, each fragment is counted as an 676 individual packet. 677 8. byte counter 678 The sum of the total length in bytes of all IP packets 679 belonging to the flow. The total length of a packet covers IP 680 header and IP payload. 681 9. type of service octet (in case of IPv4), traffic class 682 octet (in case of IPv6). According to RFC 2474 these octets 683 include the DiffServ Code Point that has a length of 6 bits. 684 10. in case of IPv6: Flow Label 685 11. if MPLS is supported at the observation point: the top MPLS 686 label or the corresponding forwarding equivalence class (FEC, 687 [RFC3031]) bound to that label. The FEC is typically defined 688 by an IP prefix. 689 12. timestamp of the first packet of the flow 690 13. timestamp of the last packet of the flow 691 14. if sampling is used: sampling configuration 692 15. unique identifier of the observation point 693 16. unique identifier of the exporting process 695 The exporting process should be able to report the following 696 attributes for each metered flow: 698 17. if protocol type is ICMP: ICMP type and code 699 18. input interface (ifIndex) 700 This requirement does not apply if the observation point is 701 located at a probe device. 702 19. output interface (ifIndex) 703 This requirement does not apply if the observation point is 704 located at a probe device. 705 20. multicast replication factor 706 the number of outgoing packets originating from a single 707 incoming multicast packet. This is a dynamic property of 708 multicast flows, that may change over time. For unicast flows 709 it has the constant value 1. The reported value must be the 710 value of the factor at the time the flow record is exported. 712 The exporting process may be able to report the following attributes 713 for each metered flow: 715 21. Time To Live (in case of IPv4) or Hop Limit (in case of IPv6) 716 22. IP header flags 717 23. TCP header flags 718 24. dropped packet counter at the observation point 719 If a packet is fragmented, each fragment must be counted as an 720 individual packet. 721 25. fragmented packet counter 722 counter of all packets for which the fragmented bit is set in 723 the IP header 724 26. next hop IP address 725 27. source BGP Autonomous System number (see [RFC1771]) 726 28. destination BGP Autonomous System number 727 29. next hop BGP Autonomous System number 729 6.2. Data Model 731 The data model describes how information is represented in flow 732 records. 734 The data model must be extensible for future attributes to be added. 735 Even if a set of attributes is fixed in the flow record, the data 736 model must provide a way of extending the record by configuration or 737 for certain implementations. 739 The data model used for exporting flow information must be flexible 740 concerning the flow attributes contained in flow records. A flexible 741 record format would offer the possibility of defining records in a 742 flexible (customizable) way regarding the number and type of 743 contained attributes. 745 The Data Model should be independent of the underlying transport 746 protocol, i.e. the data transfer. 748 6.3. Data Transfer 750 Requirements for the data transfer include reliability, congestion 751 awareness, and security requirements. For meeting these requirements 752 the exporting process can utilize existing security features provided 753 by the device hosting the process and/or provided by the transport 754 network. For example it can use existing security technologies for 755 authentication and encryption or it can rely on physical protection 756 of a separated network for transferring flow information. 758 6.3.1. Congestion Awareness 760 For the data transfer, a congestion aware protocol must be supported. 762 6.3.2. Reliability 764 Loss of flow records during the data transfer from the exporting 765 process to the collecting process must be indicated at the collecting 766 process. This indication must allow the collecting process to gauge 767 the number of flow records lost. Possible reasons for flow records 768 loss include but are not limited to: 770 1. Metering process limitations: lack of memory, processing power, 771 etc. These limitations are already covered in section 5.1. 773 2. Exporting process limitations: lack of memory, processing 774 power, etc. 776 3. Data transfer problems: packets that carry flow records sent 777 from the exporting process to the collecting process, are 778 dropped by the network. Examples are connection failures and 779 losses by a transport protocol that specifically offers 780 congestion avoidance without persistent transport-level 781 reliability. 783 4. Collecting process limitations: it may be experiencing 784 congestion and not able to buffer new flows records. 786 5. Operation and Maintenance: the collecting process is taken down 787 for maintenance or other administrative purposes. 789 Please note that if an unreliable transport protocol is used, 790 reliability can be provided by higher layers. If reliability is 791 provided by higher layers, only lack of overall reliability must be 792 indicated. For example reordering could be dealt with by adding a 793 sequence number to each packet. 795 The data transfer between exporting process and collecting process 796 must be open to reliability extensions including at least 797 - retransmission of lost flow records, 798 - detection of disconnection and fail-over, and 799 - acknowledgement of flow records by the collecting process. 800 This extensibility may be used to provide additional reliability. 801 The extended protocol must still meet the requirements described in 802 this section, particularly, it must still be congestion aware. 803 Therefore, extensions using retransmissions must use exponential 804 backoff. 806 6.3.3. Security 808 Confidentiality of IPFIX data transferred from an exporting process 809 to a collecting process must be ensured. 811 Integrity of IPFIX data transferred from an exporting process to a 812 collecting process must be ensured. 814 Authenticity of IPFIX data transferred from an exporting process to a 815 collecting process must be ensured. 817 The security requirements have been derived from an analysis of 818 potential security threads. The analysis is summarized in Section 819 10. 821 6.4. Push and Pull Mode Reporting 823 In general, there are two ways of deciding on reporting times: push 824 mode and pull mode. In push mode, the exporting process decides 825 without an external trigger when to send flow records. In pull mode, 826 sending flow records is triggered by an explicit request from a 827 collecting process. The exporting process must support push mode 828 reporting, it may support pull mode reporting. 830 6.5. Regular Reporting Interval 832 The exporting process should be capable of reporting measured traffic 833 data regularly according to a given interval length. 835 6.6. Notification on Specific Events 837 The exporting process may be capable of sending notifications to a 838 collecting process, if a specific event occurs. Such an event can be 839 for instance the arrival of the first packet of a new flow, or the 840 termination of a flow after flow timeout. 842 6.7. Anonymization 844 The exporting process may be capable of anonymizing source and 845 destination IP addresses in flow data before exporting them. It may 846 support anonymization of port numbers and other fields. Please note 847 that anonymization is not originally an application requirement, but 848 derived from general requirements for treatment of measured traffic 849 data within a network. 851 For several applications anonymization cannot be applied, for example 852 for accounting and traffic engineering. However, for protecting the 853 network user's privacy, anonymization should be applied whenever 854 possible. In many cases it is sufficient if anonymization is 855 performed at the collecting process after flow information has been 856 exported. This provides a reasonable protection of privacy as long 857 as confidentiality of the export is provided. 859 It would be desirable to request that all IPFIX exporters provide 860 anonymization of flow records, but algorithms for anonymization are 861 still a research issue. Several are known but the security they 862 provide and their other properties are not yet studied sufficiently. 863 Also, there is no standardized method for anonymization. Therefore, 864 the requirement for the exporting process supporting anonymization is 865 qualified with 'may' and not with 'must'. 867 If anonymized flow data is exported, this must be clearly indicated 868 to all receiving collecting processes, such that they can distinguish 869 anonymized data from non-anonymized data. 871 7. Configuration 873 If configuration is done remotely, security should be provided for 874 the configuration process covering confidentiality, integrity and 875 authenticity. The means used for remote configuration are out of the 876 scope of this document. 878 7.1. Configuration of the Metering Process 880 The metering process must provide a way of configuring traffic 881 measurement. The following parameters of the metering process should 882 be configurable: 884 1. specification of the observation point 885 e.g. an interface or a list of interfaces to be monitored. 886 2. specifications of flows to be metered 887 3. flow timeouts 889 The following parameters may be configurable: 891 4. sampling method and parameters, if feature is supported 892 5. overload behavior, if feature is supported 894 7.2. Configuration of the Exporting Process 896 The exporting process must provide a way of configuring the data 897 export. The following parameters of the exporting process should be 898 configurable: 900 1. reporting data format 901 Specifying the reporting data format must include a selection 902 of attributes to be reported for each flow. 903 2. the collecting process(es) to which flows are reported 904 3. the reporting interval 905 This requirement only applies if the exporting process supports 906 reporting in regular intervals. 907 4. notifications to be sent to the collecting process(es) 908 This requirement only applies if the exporting process supports 909 notifications. 910 5. flow anonymization 911 This requirement only applies if the exporting process supports 912 flow anonymization. 914 8. General Requirements 916 8.1. Openness 918 IPFIX specifications should be open to future technologies. This 919 includes extensibility of configuration of the metering process and 920 the exporting process. 922 Openness is also required concerning the extensibility of the data 923 model, as stated in section 6.2. 925 8.2. Scalability 927 Data collection from hundreds of different exporting processes must 928 be supported. The collecting process must be able to distinguish 929 several hundred exporting processes by their identifiers. 931 8.3. Several Collecting Processes 933 The exporting process may be able to export flow information to more 934 than one collecting process. If an exporting process is able to 935 export flow records to multiple collecting processes then it must be 936 able to ensure that the flow records can be identified so that 937 duplicates can be detected between different collecting processes and 938 double counting problems can be avoided. 940 9. Special Device Considerations 942 This document intends to avoid constraining the architecture of 943 probes, routers, and other devices hosting observation points, 944 metering processes, exporting processes, and/or collecting processes. 945 It can be expected that typically observation point, metering 946 process, and exporting process are co-located at a single device. 947 However, the requirements defined in this document do not exclude 948 devices that derive from this configuration. Figure 2 shows some 949 examples. 951 All examples are composed of one or more of the following elements: 952 observation point (O), metering process (M), exporting process (E), 953 collecting process (C). The observation points shown in the figure 954 are always the most fine-granular ones supported by the respective 955 device. 957 +---+ +-----+ +---------+ +---------+ 958 | E-+-> | E--+-> | E----+-> <-+--E E--+-> 959 | | | | | | | / \ | | | | | 960 | M | | M | | M M | | M M | 961 | | | | /|\ | | /|\ /|\ | | /|\ /|\ | 962 | O | | OOO | | OOO OOO | | OOO OOO | 963 +---+ +-----+ +---------+ +---------+ 964 Probe Basic Complex Multiple 965 Router Router Exporting 966 Processes 968 +---+ +---+ +---+ 969 | E-+-> | E-+-> | E-+------------->---+ 970 | | | | | | | | | +---+ +-+-----+ 971 +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> 972 | | | | | | | | | | +---+ +-+-----+ 973 +-+-+ +-+-+ | O | | M | | E-+->---+ 974 | | | | +---+ | | | | | | 975 | M | +-+-+ | O | | M | 976 | | | | | | +---+ | | | +-----+ 977 | O | | O | | O | ->-+-C-E-+-> 978 +---+ +---+ +---+ +-----+ 980 Protocol Remote Concentrator Proxy 981 Converter Observation 983 Figure 2: IPFIX-related Devices 985 A very simple device is a probe. A typical probe contains a single 986 observation point, a single metering process, and a single exporting 987 process. 989 A basic router extends this structure by multiple observation points. 990 Here, the observation point of a particular flow may be one of the 991 displayed most fine-granular observation points, but also it may be a 992 set of them. 994 A more complex router may host more than one metering process, for 995 example one per line card. Please note that here, the observation 996 point of a single flow cannot exceed the set of most fine-granular 997 observation points linked to a single metering process, because only 998 the metering process can merge packets observed at different fine- 999 granular observation points to a joint flow. An observation point 1000 containing all most fine-granular observation points of this router 1001 is not possible with this structure. Alternatively, a complex router 1002 may host different exporting processes for flow records generated by 1003 different metering processes. 1005 A protocol converter makes use of a metering process that can be 1006 accessed only by protocol(s) other than the one defined for IPFIX, 1007 for example, the SNMP and the Meter MIB module [RFC2720]. Then the 1008 exporting process receives flow record from a remote metering process 1009 and exports these records using the IPFIX protocol. Please note that 1010 this document does not make any particular assumption on how metering 1011 processes and export processes exchange information, as long as all 1012 individual requirements for these processes are met. Also the 1013 locations of metering processes are not of any relevance for this 1014 document (in contrast to the locations of observation points and the 1015 exporting processes). 1017 In the example of remote packet observation in Figure 2 the metering 1018 process and the observation point are not co-located. Packet headers 1019 captured at an observation point may be exported as raw data to a 1020 device hosting metering process and exporting process. Again, this 1021 document does not make any particular assumption on how packet 1022 headers are transferred from observation points to metering 1023 processes, as long as all requirements for the metering processes are 1024 met. 1026 An intermediate structure between protocol converter and remote 1027 observation (not shown in the Figure) would be a split metering 1028 process, for example performing timestamping and sampling at the 1029 device hosting the observation point and performing packet 1030 classification at another device hosting the exporting process. 1032 A concentrator receives flow records via the IPFIX protocol, merges 1033 them into more aggregated flow records, and exports them again using 1034 the IPFIX protocol. Please note that for the final flow records the 1035 resulting observation point may be a superset of the more fine- 1036 granular observation points at the first level devices. The metering 1037 process of the final flow records is composed by the (partial) 1038 metering processes at the first level devices and the partial 1039 metering process at the concentrator. 1041 Finally, a very simple IPFIX-related device is a proxy. It just 1042 receives flow records using the IPFIX protocol and sends them further 1043 using the same protocol. A proxy might be useful for traversing 1044 firewalls or other gateways. 1046 10. Security Considerations 1048 An IPFIX protocol must be capable of transporting data over the 1049 public Internet. Therefore it cannot be excluded that an attacker 1050 captures or modifies packets or inserts additional packets. 1052 This section describes security requirements for IPFIX. Like other 1053 requirements, the security requirements differ among the considered 1054 applications. The incentive to modify collected data for accounting 1055 or intrusion detection for instance is usually higher than the 1056 incentive to change data collected for traffic profiling. A detailed 1057 list of the required security features per application can be found 1058 in the appendix. 1060 The suggestion of concrete solutions for achieving the required 1061 security properties should be part of an IPFIX architecture and 1062 protocol. It is out of scope of this document. Also methods for 1063 remote configuration of the metering processes and exporting 1064 processes are out of scope. Therefore, threats that are caused by 1065 data exchange for remote configuration are not considered here. 1067 The following potential security hazards for an IPFIX protocol have 1068 been identified: disclosure of IP flow information, forgery of flow 1069 records, and Denial of Service (DoS) attacks. 1071 10.1. Disclosure of Flow Information Data 1073 The content of data exchanged by an IPFIX protocol (for example IPFIX 1074 flow records) should be kept confidential between the involved 1075 parties (exporting process and collecting process). Observation of 1076 IPFIX flow records gives an attacker information about the active 1077 flows in the network, communication endpoints and traffic patterns. 1078 This information cannot only be used to spy on user behavior but also 1079 to plan and conceal future attacks. Therefore, the requirements 1080 specified in section 6.3.3. include confidentiality of the 1081 transferred data. This can be achieved for instance by encryption. 1083 Also the privacy of users acting as sender or receiver of the 1084 measured traffic needs to be protected when they use the Internet. 1085 In many contries the right to store user-specific data (including the 1086 user's traffic profiles) is restricted by law or by regulations. 1088 In addition to encryption, this kind of privacy can also be protected 1089 by anonymizing flow records. For many traffic flow measurements, 1090 anonymized data is as useful as precise data. Therefore, it is 1091 desirable to support anonymization in IPFIX implementations. It is 1092 beyond the scope of the IPFIX working group to develop and 1093 standardize anonymization methods. However, the requirements for 1094 extensibility of the IPFIX protocol are sufficient to support 1095 anonymized flow records when appropriate methods are standardized. 1097 10.2. Forgery of Flow Records 1099 If flow records are used in accounting and/or security applications, 1100 there are potentially strong incentives to forge exported IPFIX flow 1101 records (for example to save money or prevent the detection of an 1102 attack). This can be done either by altering flow records on the 1103 path or by injecting forged flow records that pretend to be 1104 originated by the original exporting process. 1106 Special caution is required if security applications rely on flow 1107 measurements. With forged flow records it is possible to trick 1108 security applications. For example, an application may be lead to 1109 falsely conclude that a DoS attack is in progress. If such an 1110 injection of IPFIX traffic flow records fools the security 1111 application, causing it to erroneously conclude that a DoS attack is 1112 underway, then the countermeasures employed by the security 1113 application may actually deny useful non-malicious services. 1115 In order to make an IPFIX protocol resistant against such attacks, 1116 authentication and integrity must be provided, as specified in 1117 section 6.3.3. 1119 10.3. Denial of Service (DoS) Attacks 1121 DoS attacks on routers or other middleboxes that have the IPFIX 1122 protocol implemented would also affect the IPFIX protocol and impair 1123 the sending of IPFIX records. Nevertheless, since such hazards are 1124 not induced specifically by the IPFIX protocol the prevention of such 1125 attacks is out of scope of this document. 1127 However, IPFIX itself also causes potential hazards for DoS attacks. 1128 All processes that expect the reception of traffic can be target of a 1129 DoS attack. With the exporting process this is only the case if it 1130 supports the pull mode (which can be an optional feature of the IPFIX 1131 protocol according to this document). The collecting process always 1132 expects data and therefore can be flooded by flow records. 1134 11. Acknowledgments 1136 Many thanks Georg Carle for contributing to the application analysis, 1137 to K.C. Norseth for several fine-tunings, to Sandra Tartarelli for 1138 checking the appendix, and to a lot of further people on the mailing 1139 list providing valuable comments and suggestions including Nevil 1140 Brownlee, Carter Bullard, Paul Calato, Ram Gopal, Tal Givoly, Jeff 1141 Meyer, Reinaldo Penno, Sonia Panchen, Simon Leinen, David Plonka, 1142 Ganesh Sadasivan, Kevin Zhang, and many more. 1144 12. Appendix: Derivation of Requirements from Applications 1146 The following table documents, how the requirements stated in 1147 sections 3-7 are derived from requirements of the applications listed 1148 in section 2. 1150 Used abbreviations: 1151 M = must 1152 S = should 1153 O = may (optional) 1154 - = DONT CARE 1156 -----------------------------------------------------------------------. 1157 IPFIX | 1158 ----------------------------------------------------------------. | 1159 E: QoS Monitoring | | 1160 ----------------------------------------------------------. | | 1161 D: Attack/Intrusion Detection | | | 1162 ----------------------------------------------------. | | | 1163 C: Traffic Engineering | | | | 1164 ----------------------------------------------. | | | | 1165 B: Traffic Profiling | | | | | 1166 ----------------------------------------. | | | | | 1167 A: Usage-based Accounting | | | | | | 1168 ----------------------------------. | | | | | | 1169 | | | | | | | 1170 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1171 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1172 | 4. | DISTINGUISHING FLOWS | 1173 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1174 | 4. | Combination of | M | M | M | M | M | M | 1175 | | required attributes | | | | | | | 1176 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1177 | 4.1. | in/out IF | S | M | M | S | S | M | 1178 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1179 | 4.2. | src/dst address | M | M | M | M | M | M | 1180 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1181 | 4.2. | Masking of IP adresses | M | M | M | M | M | M | 1182 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1183 | 4.2. | transport protocol | M | M | - | M | M | M | 1184 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1185 | 4.2. | version field | - | S | S | O | O | S | 1186 | | | | | (b) | | | | 1187 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1188 | 4.3. | src/dst port | M | M | - | M | M | M | 1189 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1190 | 4.4. | MPLS label (a) | S | S | M | O | S | M | 1191 | | | | | (c) | | | | 1192 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1193 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1194 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1195 | 4.5. | DSCP (a) | M | S | M | O | M | M | 1196 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1197 | 5. | METERING PROCESS | 1198 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1199 | 5.1. | Reliability | M | S | S | S | S | | 1200 |-------+-------------------------+-----+-----+-----+-----+-----+ M | 1201 | 5.1. | Indication of | - | M | M | M | M | | 1202 | | missing reliability | | | | | | | 1203 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1204 | 5.2. | Sampling (d,e) | O | O | O | O | O | O | 1205 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1206 | 5.3. | Overload Behavior (f) | O | O | O | O | O | O | 1207 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1208 | 5.4. | Timestamps | M | O | O | S | M | M | 1209 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1210 | 5.5. | Time synchronization | M | S | S | S | M | M | 1211 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1212 | 5.6. | Flow timeout | M | S | - | O | O | M | 1213 | | | (g) | | | | | | 1214 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1215 | 5.7. | Multicast flows | S | O | O | O | S | S | 1216 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1217 | 5.8. | Packet fragmentation | O | O | - | - | - | O | 1218 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1219 | 5.9. | Ignore port copy | O | O | O | O | O | O | 1220 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1221 | 6. | DATA EXPORT | 1222 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1223 | 6.1. | INFORMATION MODEL | 1224 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1225 | 6.1. | IP Version | - | M | M | O | O | M | 1226 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1227 | 6.1. | src/dst address | M | M | M | M | M | M | 1228 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1229 | 6.1. | transport protocol | M | M | - | M | M | M | 1230 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1231 | 6.1. | src/dst port | M | M | - | M | M | M | 1232 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1233 | 6.1. | Packet counter (h) | S | M | M | S | S | M | 1234 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1235 | 6.1. | Byte counter | M | M | M | S | S | M | 1236 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1237 | 6.1. | ToS (IPv4) or traffic | M | S | M | O | M | M | 1238 | | class octet (IPv6) | | | | | | | 1239 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1240 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1241 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1242 | 6.1. | Flow Label (IPv6) | M | S | M | O | M | M | 1243 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1244 | 6.1. | MPLS label (a) | S | S | M | O | S | M | 1245 | | | | | (c) | | | | 1246 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1247 | 6.1. | Timestamps for | M | O | O | S | S | M | 1248 | | first/last packet | | | | | | | 1249 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1250 | 6.1. | Sampling configuration | M | M | M | M | M | M | 1251 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1252 | 6.1. | observation point | M | M | M | M | M | M | 1253 | | identifier | | | | | | | 1254 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1255 | 6.1. | export process | M | M | M | M | M | M | 1256 | | identifier | | | | | | | 1257 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1258 | 6.1. | ICMP type and code (i) | S | S | - | S | S | S | 1259 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1260 | 6.1. | input/output interface | S | S | S | S | S | S | 1261 | | (j) | | | | | | | 1262 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1263 | 6.1. | Multicast | O | S | S | - | S | S | 1264 | | replication factor | | | | | | | 1265 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1266 | 6.1. | TTL | O | O | O | O | O | O | 1267 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1268 | 6.1. | IP header flags | - | O | O | O | O | O | 1269 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1270 | 6.1. | TCP header flags | - | O | O | O | - | O | 1271 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1272 | 6.1. | Dropped Packet | O | O | O | O | O | O | 1273 | | Counter (h,k) | | | | | | | 1274 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1275 | 6.1. | Fragment counter | - | O | O | O | O | O | 1276 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1277 | 6.1. | next hop IP address | O | O | O | O | - | O | 1278 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1279 | 6.1. | src / dst / next hop | - | O | O | - | - | O | 1280 | | BGP AS # | | | | | | | 1281 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1282 | 6.2. | DATA MODEL | 1283 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1284 | 6.2. | Flexibility | M | S | M | M | M | M | 1285 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1286 | 6.2. | Extensibility | M | S | M | M | M | M | 1287 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1288 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1289 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1290 | 6.3. | DATA TRANSFER | 1291 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1292 | 6.3.1.| Congestion aware | M | M | M | M | M | M | 1293 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1294 | 6.3.2.| Reliability | M | S | S | S | S | M | 1295 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1296 | 6.3.3.| Confidentiality | M | S | S | M | S | M | 1297 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1298 | 6.3.4.| Integrity | M | M | M | M | M | M | 1299 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1300 | 6.3.5.| Authenticity | M | M | M | M | M | M | 1301 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1302 | 6.4. | REPORTING TIMES | 1303 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1304 | 6.4. | Push mode | M | O | O | M | S | M | 1305 | | | | (l) | (l) | |(l,m)| | 1306 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1307 | 6.4. | Pull mode | O | O | O | O | O | O | 1308 | | | | (l) | (l) | | (l) | | 1309 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1310 | 6.4.1.| Regular interval | S | S | S | S | S | S | 1311 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1312 | 6.6. | Notifications | O | O | O | O | O | O | 1313 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1314 | 6.7. | Anonymization (n) | O | O | O | O | O | O | 1315 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1316 | 7. | CONFIGURATION | 1317 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1318 | 7. | Secure remote | S | S | S | S | S | S | 1319 | | configuration (a) | | | | | | | 1320 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1321 | 7.1. | Config observation point| S | S | S | S | S | S | 1322 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1323 | 7.1. | Config flow | S | S | S | S | S | S | 1324 | | specifications | | | | | | | 1325 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1326 | 7.1. | Config flow timeouts | S | S | S | S | O | S | 1327 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1328 | 7.1. | Config sampling | O | O | O | O | O | O | 1329 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1330 | 7.1. | Config overload | O | O | O | O | O | O | 1331 | | behavior (a) | | | | | | | 1332 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1333 | 7.2. | Config report | S | S | S | S | S | S | 1334 | | data format | | | | | | | 1335 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1336 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1337 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1338 | 7.2. | Config | S | S | S | S | S | S | 1339 | | notifications | | | | | | | 1340 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1341 | 8. | GENERAL REQUIREMENTS | 1342 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1343 | 8.1. | Openness | S | S | S | S | S | S | 1344 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1345 | 8.2. | Scalability: | | | | | | | 1346 | | data collection | M | S | M | O | S | M | 1347 | | from hundreds of | | | | | | | 1348 | | measurement devices | | | | | | | 1349 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1350 | 8.3. | Several collectors | O | O | O | O | O | O | 1351 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1353 Remarks: 1354 (a) If feature is supported. 1355 (b) The differentiation of IPv4 and IPv6 is for TE of importance. 1356 So we tended to make this a must. Nevertheless, a should seems 1357 to be sufficient to perform most TE tasks and allows us to have 1358 a should for IPFIX instead of a must. 1359 (c) For TE in an MPLS network the label is essential. Therefore a 1360 must is given here leading to a must in IPFIX. 1361 (d) If sampling is supported, the methods and parameters must be 1362 well defined. 1363 (e) If sampling is supported, sampling configuration changes must 1364 be indicated to all collecting processes. 1365 (f) If overload behavior is supported and it induces changes in the 1366 metering process behavior, the overload behavior must be 1367 clearly defined. 1368 (g) Precise time-based accounting requires reaction to a flow 1369 timeout. 1370 (h) If a packet is fragmented, each fragment is counted as an 1371 individual packet. 1372 (i) If protocol type is ICMP. 1373 (j) This requirement does not apply if the observation point is 1374 located at a probe device. 1375 (k) Only if measurement is done on data path i.e. has access to 1376 forwarding decision. 1377 (l) Either push or pull has to be supported. 1378 (m) Required, in order to immediately report drop indications for 1379 SLA validation. 1380 (n) Anonymization must be clearly indicated to all receiving 1381 collecting processes. 1383 13. Normative References 1385 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1386 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, 1387 L. and V. Paxson, "Stream Control Transmission Protocol", 1388 RFC 2960, October 2000. 1390 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol 1391 Label Switching Architecture", RFC 3031, January 2001. 1393 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition 1394 of the Differentiated Services Field (DS Field) in the IPv4 1395 and IPv6 Headers", RFC 2474, December 1998. 1397 [RFC791] J. Postel. "Internet Protocol", RFC791, September 1981. 1399 14. Informative References 1401 [RFC3234] B. Carpenter, "Middleboxes: taxonomy and issues", RFC 3234, 1402 February 2002. 1404 [RFC2119] S. Bradner "Key words for use in RFCs to Indicate 1405 Requirement Levels", RFC 2119, March 1997. 1407 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1408 "RTP: A Transport Protocol for Real-Time Applications", RFC 1409 1889, January 1996. 1411 [RFC2975] Aboba, B., Arkko, J. and D. Harrington, "Introduction to 1412 Accounting Management", RFC 2975, October 2000. 1414 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. 1415 McManus, "Requirements for Traffic Engineering Over MPLS", 1416 RFC 2702, September 1999. 1418 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 1419 (BGP-4)", RFC 1771, March 1995. 1421 [RFC3418] R. Presuhn (Ed.), "Management Information Base (MIB) for the 1422 Simple Network Management Protocol (SNMP)", RFC 3418, 1423 December 2002. 1425 [RFC2720] N. Brownlee, "Traffic Flow Measurement: Meter MIB", RFC 1426 2720, October 1999. 1428 15. Authors' Addresses 1430 Juergen Quittek 1431 NEC Europe Ltd., Network Laboratories 1432 Kurfuersten-Anlage 36 1433 69115 Heidelberg 1434 Germany 1436 Phone: +49 6221 90511 15 1437 EMail: quittek@netlab.nec.de 1439 Tanja Zseby 1440 Fraunhofer Institute for Open Communication Systems (FOKUS) 1441 Kaiserin-Augusta-Allee 31 1442 10589 Berlin 1443 Germany 1445 Phone: +49 30 3463 7153 1446 Email: zseby@fokus.fhg.de 1448 Benoit Claise 1449 Cisco Systems 1450 De Kleetlaan 6a b1 1451 1831 Diegem 1452 Belgium 1454 Phone: +32 2 704 5622 1455 Email: bclaise@cisco.com 1457 Sebastian Zander 1458 Fraunhofer Institute for Open Communication Systems (FOKUS) 1459 Kaiserin-Augusta-Allee 31 1460 10589 Berlin 1461 Germany 1463 Phone: +49 30 3463 7287 1464 Email: zander@fokus.fhg.de 1466 16. IPR Notices 1468 The IETF takes no position regarding the validity or scope of any 1469 intellectual property or other rights that might be claimed to 1470 pertain to the implementation or use of the technology described in 1471 this document or the extent to which any license under such rights 1472 might or might not be available; neither does it represent that it 1473 has made any effort to identify any such rights. Information on the 1474 IETF's procedures with respect to rights in standards-track and 1475 standards-related documentation can be found in BCP-11. Copies of 1476 claims of rights made available for publication and any assurances of 1477 licenses to be made available, or the result of an attempt made to 1478 obtain a general license or permission for the use of such 1479 proprietary rights by implementors or users of this specification can 1480 be obtained from the IETF Secretariat. 1482 The IETF invites any interested party to bring to its attention any 1483 copyrights, patents or patent applications, or other proprietary 1484 rights which may cover technology that may be required to practice 1485 this standard. Please address the information to the IETF Executive 1486 Director. 1488 17. Full Copyright Statement 1490 Copyright (C) The Internet Society (2004). All Rights Reserved. 1492 This document and translations of it may be copied and furnished to 1493 others, and derivative works that comment on or otherwise explain it 1494 or assist in its implementation may be prepared, copied, published 1495 and distributed, in whole or in part, without restriction of any 1496 kind, provided that the above copyright notice and this paragraph are 1497 included on all such copies and derivative works. However, this 1498 document itself may not be modified in any way, such as by removing 1499 the copyright notice or references to the Internet Society or other 1500 Internet organizations, except as needed for the purpose of 1501 developing Internet standards in which case the procedures for 1502 copyrights defined in the Internet Standards process must be 1503 followed, or as required to translate it into languages other than 1504 English. 1506 The limited permissions granted above are perpetual and will not be 1507 revoked by the Internet Society or its successors or assigns. 1509 This document and the information contained herein is provided on an 1510 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1511 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1512 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1513 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1514 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.