idnits 2.17.1 draft-ietf-ipfix-reqs-10.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 198 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 1437 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 2003) is 7621 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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: 4 errors (**), 0 flaws (~~), 2 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-10.txt NEC Europe Ltd. 3 Category: Informational T. Zseby 4 Expires: December 2003 Fraunhofer FOKUS 5 B. Claise 6 Cisco Systems 7 S. Zander 8 Fraunhofer FOKUS 10 June 2003 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 (2003). 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 ................................................. 3 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 ........................................ 8 64 4.1. Interfaces .............................................. 9 65 4.2. IP Header Fields ........................................ 9 66 4.3. Transport Header Fields ................................. 10 67 4.4. MPLS Label .............................................. 10 68 4.5. DiffServ Code Point ..................................... 10 69 4.6. Header Compression and Encryption ....................... 10 70 5. Metering Process ............................................ 10 71 5.1. Reliability ............................................. 10 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 ......................................... 12 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 ....................................... 13 82 6.2. Data Model .............................................. 15 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 .............................. 17 89 6.6. Notification on Specific Events ......................... 17 90 6.7. Anonymization ........................................... 18 91 7. Configuration ............................................... 18 92 7.1. Configuration of the Metering Process ................... 18 93 7.2. Configuration of the Exporting Process .................. 18 94 8. General Requirements ........................................ 19 95 8.1. Openness ................................................ 19 96 8.2. Scalability ............................................. 19 97 8.3. Several Collecting Processes ............................ 19 98 9. Special Device Considerations ............................... 19 99 10. Security Considerations .................................... 22 100 10.1. Disclosure of Flow Information Data .................... 22 101 10.2. Forgery of Flow Records ................................ 22 102 10.3. Denial of Service (DoS) Attacks ........................ 23 103 11. Acknowledgments ............................................ 23 104 12. Appendix: Derivation of Requirements from Applications ..... 24 105 13. Normative References ....................................... 29 106 14. Informative References ..................................... 29 107 15. Authors' Addresses ......................................... 30 108 16. Full Copyright Statement ................................... 31 110 1. Introduction 112 There are several applications that require flow-based IP traffic 113 measurements. Such measurements could be performed by a router while 114 forwarding the traffic, by a middlebox [RFC3234], or by a traffic 115 measurement probe attached to a line or a monitored port. This memo 116 defines requirements for exporting traffic flow information out of 117 these boxes for further processing by applications located on other 118 devices. They serve as input to the standardization of an IPFIX 119 protcol. 121 In section 3, a selection of such applications is presented. The 122 following sections list requirements derived from these applications. 124 Many requirements in this document are not explicitly stated as IPFIX 125 protocol requirements, but as requirements for the metering process, 126 the exporting process, or for other traffic measurement components. 127 However, every requirement that needs support from the IPFIX protocol 128 MUST be covered by the IPFIX protocol specification and related 129 standard documents independent of the significance of the 130 requirement, which can be MANDATORY (MUST), RECOMMENDED (SHOULD), or 131 OPTIONAL (MAY). 133 Note that the protocol specification and related standard documents 134 themselves also assign significance attributes to its features, such 135 that a protocol implementation does not necessarily need to implement 136 all features. However, the implementations significance atributes 137 need to match those of the corresponding IPFIX requirements. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 Furthermore, the following terminology is used: 147 2.1. IP Traffic Flow 149 There are several definitions of the term 'flow' being used by the 150 Internet community. Within this document we use the following one: 152 A flow is defined as a set of IP packets passing an observation point 153 in the network during a certain time interval. All packets belonging 154 to a particular flow have a set of common properties. Each property 155 is defined as the result of applying a function to the values of: 157 1. one or more packet header field (e.g. destination IP address), 158 transport header field (e.g. destination port number), or 159 application header field (e.g. RTP header fields [RFC1889]) 161 2. one or more characteristics of the packet itself (e.g. number 162 of MPLS labels, etc...) 164 3. one or more of fields derived from packet treatment (e.g. next 165 hop IP address, the output interface, etc...) 167 A packet is defined to belong to a flow if it completely satisfies 168 all the defined properties of the flow. 170 This definition covers the range from a flow containing all packets 171 observed at a network interface to a flow consisting of just a single 172 packet between two applications with a specific sequence number. 173 Please note that the flow definition does not necessarily match a 174 general application-level end-to-end stream. However, an application 175 may derive properties of application-level streams by processing 176 measured flow data. Also, please note that although packet properties 177 may depend on application headers, there is no requirement defined in 178 this document related to application headers. 180 2.2. Observation Point 182 The observation point is a location in the network where IP packets 183 can be observed. Examples are a line to which a probe is attached, a 184 shared medium such as an Ethernet-based LAN, a single port of a 185 router, or a set of interfaces (physical or logical) of a router. 187 Note that one observation point may be a superset of several other 188 observation points. For example one observation point can be an 189 entire line card. This would be the superset of the individual 190 observation points at the line card's interfaces. 192 2.3. Metering Process 194 The metering process generates flow records. Input to the process are 195 packet headers observed at an observation point and packet treatment 196 at the observation point, for example the selected output interface. 197 The metering process consists of a set of functions that includes 198 packet header capturing, timestamping, sampling, classifying, and 199 maintaining flow records. 201 The maintenance of flow records may include creating new records, 202 updating existing ones, computing flow statistics, deriving further 203 flow properties, detecting flow expiration, passing flow records to 204 the exporting process, and deleting flow records. 206 The sampling function and the classifying function may be applied 207 more than once with different parameters. Figure 1 shows the sequence 208 in which the functions are applied. Sampling is not illustrated in 209 the figure, it may be applied before any other function. 211 packet header capturing 212 | 213 timestamping 214 | 215 v 216 +----->+ 217 | | 218 | classifying 219 | | 220 +------+ 221 | 222 maintaining flow records 223 | 224 v 226 Figure 1: Functions of the metering process 228 2.4. Flow Record 230 A flow record contains information about a specific flow that was 231 metered at an observation point. A flow record contains measured 232 properties of the flow (e.g. the total number of bytes of all packets 233 of the flow) and usually also characteristic properties of the flow 234 (e.g. source IP address). 236 2.5. Exporting Process 238 The exporting process sends flow records to one or more collecting 239 processes. The flow records are generated by one or more metering 240 processes. 242 2.6. Collecting Process 244 The collecting process receives flow records from one or more 245 exporting processes. The collecting process might store received flow 246 records or further process them, but these actions are out of the 247 scope of this document. 249 3. Applications Requiring IP Flow Information Export 251 This section describes a selection of applications requiring IP flow 252 information export. Because requirements for flow export listed in 253 further sections below are derived from these applications, their 254 selection is crucial. The goal of this requirements document is not 255 to cover all possible applications with all their flow export 256 requirements, but to cover applications which are considered to be of 257 significant importance in today's and/or future IP networks, and for 258 which requirements can be met with reasonable technical effort. 260 The list of applications should lead to a better understanding of the 261 requirements which is particularly important when designing or 262 implementing traffic flow metering functions. A detailed overview of 263 which requirement was derived from which application(s) is given in 264 the appendix. 266 Please note, that the described applications can have a large number 267 of differing implementations. Requirement details or requirement 268 significance (MANDATORY (MUST), RECOMMENDED (SHOULD), OPTIONAL (MAY)) 269 could differ for specific implementations and/or for specific 270 application scenarios. Therefore we derive the requirements from the 271 general functionality of the selected applications. Some particular 272 cases will even mandate more stringent requirements than the ones 273 defined in this document. For example, usage-based accounting is 274 certainly the application that will probably mandate the highest 275 degree of reliability amonst the applications discussed below. The 276 reliability reqirements defined in sections 5.1 and 6.3.2. are not 277 sufficient to guarantee the level of reliability that is needed for 278 many usage-based accounting systems. Particular reliability 279 requirements for accounting systems are discussed in [RFC2975]. 281 3.1. Usage-based Accounting 283 Several new business models for selling IP services and IP-based 284 services are currently under investigation. Beyond flat rate services 285 which do not need accounting, accounting can be based on time or 286 volume. Accounting data can serve as input for billing systems. 287 Accounting can be performed per user or per user group, it can be 288 performed just for basic IP service or individually per high-level 289 service and/or per content type delivered. For advanced/future 290 services, accounting may also be performed per class of service, per 291 application, per time of day, per used (label switched) path, etc. 293 3.2. Traffic Profiling 295 Traffic profiling is the process of characterizing IP flows by using 296 a model that represents key parameters of the flows such as flow 297 duration, volume, time and burstiness. It is a prerequisite for 298 network planning, network dimensioning, trend analysis, business 299 models development, and other activities. It heavily depends on the 300 particular traffic profiling objective(s) what statistics and 301 accuracy are required from the measurements. Typical information 302 needed for traffic profiling is the distribution of used services and 303 protocols in the network, the amount of packets of a specific type 304 (e.g. percentage of IPv6 packets) and specific flow profiles. 306 Since objectives for traffic profiling can vary, this application 307 requires a high flexibility of the measurement infrastructure, 308 especially regarding the options for measurement configuration and 309 packet classification. 311 3.3. Traffic Engineering 313 Traffic Engineering (TE) comprises methods for measurement, modeling, 314 characterization and control of a network. The goal of TE is the 315 optimization of network resource utilization and traffic performance 316 [RFC2702]. Since control and administrative reaction to measurement 317 results requires access to the involved network nodes, TE mechanisms 318 and the required measurement function usually are performed within 319 one administrative domain. Typical parameters required for TE are 320 link utilization, load between specific network nodes, number, size 321 and entry/exit points of the active flows and routing information. 323 3.4. Attack/Intrusion Detection 325 Capturing of flow information plays an important role for network 326 security, both for detection of security violation, and for 327 subsequent defense. In case of a Denial of Service (DOS) attack, flow 328 monitoring can allow detection of unusual situations or suspicious 329 flows. In a second step, flow analysis can be performed in order to 330 gather information about the attacking flows, and for deriving a 331 defense strategy. 333 Intrusion detection is a potentially more demanding application which 334 would not only look at specific characteristics of flows, but may 335 also use a stateful packet flow analysis for detecting specific, 336 suspicious activities, or unusually frequent activities. Such 337 activities may be characterized by specific communication patterns, 338 detectable by characteristic sequences of certain packet types. 340 3.5. QoS Monitoring 342 QoS monitoring is the passive measurement of quality parameters for 343 IP flows. In contrast to active measurements, passive measurements 344 utilize the existing traffic in the network for QoS analysis. Since 345 no test traffic is sent, passive measurements can only be applied in 346 situations where the traffic of interest is already present in the 347 network. One example application is the validation of QoS parameters 348 negotiated in a service level specification. Note that passive/active 349 measurement is also referred to as non-intrusive/intrusive 350 measurement or as measurement of observed/synthetic traffic. 352 Passive measurements cannot provide the kind of controllable 353 experiments that can be achieved with active measurements. On the 354 other hand passive measurements do not suffer from undesired side 355 effects caused by sending test traffic (e.g. additional load, 356 potential differences in treatment of test traffic and real customer 357 traffic). 359 QoS monitoring often requires the correlation of data from multiple 360 observation points (e.g. for measuring one-way metrics). This 361 requires proper clock synchronization of the involved metering 362 processes. For some measurements, flow records and/or notifications 363 on specific events at the different observation points must be 364 correlated, for example the arrival of a certain packet. For this, 365 the provisioning of post-processing functions (e.g. the generation of 366 packet IDs) at the metering processes would be useful. Since QoS 367 monitoring can lead to a huge amount of measurement result data, it 368 would highly benefit from mechanisms to reduce the measurement data, 369 like aggregation of results and sampling. 371 Please note that not all requirements for QoS monitoring are covered 372 by the IPFIX requirements specified in the following sections. The 373 IPFIX requirements are targeted at per flow information including 374 summaries of per-packet properties for packets within a flow, but not 375 per-packet information itself. For example jitter measurement 376 requires timestamping each packet and reporting of all timestamps of 377 a flow, but the IPFIX requirements only cover timestamps of first and 378 last packet of a flow. 380 4. Distinguishing Flows 382 Packets are mapped to flows by evaluating their properties. Packets 383 with common properties are considered to belong to the same flow. A 384 packet showing at least one difference in the set of properties is 385 considered to belong to a different flow. 387 The following subsections list a set of properties which a metering 388 process MUST, SHOULD, or MAY be able to evaluate for mapping packets 389 to flows. Please note that requiring the ability to evaluate a 390 certain property does not imply that this property must be evaluated 391 for each packet. In other words, meeting the IPFIX requirements 392 means that the metering process in general must be able, via its 393 configuration, to somehow support to distinguish flows via all the 394 MUST fields, even if in certain circumstances/for certain 395 applications, only a subset of the MUST fields is needed and 396 effectively used to distinguish flows. 398 Which combination of properties is used for distinguishing flows and 399 how these properties are evaluated depends on the configuration of 400 the metering process. The configured choice of evaluated properties 401 strongly depends on the environment and purpose of the measurement 402 and on the information required by the collecting process. But 403 anyway, it MUST be ensured that a collecting process is able to 404 clearly identify for each received flow record which set of 405 properties was used for distinguishing this flow from other ones. 407 For specific deployments, only a subset of the REQUIRED properties 408 listed below can be used to distinguish flows, for example in order 409 to aggregate the flow records and reduce the number of flow records 410 exported. On the other hand, some other deployments will require 411 distinguishing flows by some extra parameters, like for example the 412 TTL field of the IP header or the BGP Autonomous System number 413 [RFC1771] of the IP destination address. 415 4.1. Interfaces 417 The metering process MUST be able to separate flows by the incoming 418 interface or by the outgoing interface or by both of them. 420 4.2. IP Header Fields 422 The metering process MUST, SHOULD, or MAY be able to separate flows 423 by the following fields of the IP header as indicated. 425 1. source IP address (MUST) 427 2. destination IP address (MUST) 429 3. protocol type (TCP,UDP,ICMP,...) (MUST) 431 4. IP version number (SHOULD) 432 This requirement only applies if the observation point is 433 located at a device that is supporting more than IP version. 435 For source address and destination address, separating by full match 436 MUST be supported as well as separation by prefix match. 438 4.3. Transport Header Fields 440 The metering process MUST be able to separate flows by the port 441 numbers of the transport header in case of TCP or UDP being used as 442 transport protocol. Both, source and destination port number MUST be 443 supported for distinguishing flows, individually as well as in 444 combination. 446 4.4. MPLS Label 448 If the observation point is located at a device supporting 449 Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering 450 process MUST be able to separate flows by the MPLS label. 452 4.5. DiffServ Code Point 454 If the observation point is located at a device supporting 455 Differentiated Services (DiffServ) then the metering process MUST be 456 able to separate flows by the DiffServ Code Point (DSCP, see 457 [RFC2474]). 459 4.6. Header Compression and Encryption 461 If header compression or encryption is used, the metering process 462 might not be able to access all header fields. A metering process 463 MUST meet the requirements stated in this section 4 only for packets 464 that have the relevant header fields not compressed and not 465 encrypted. 467 5. Metering Process 469 The following are requirements for the metering process. All 470 measurements MUST be conducted from the point of view of the 471 observation point. 473 5.1. Reliability 475 The metering process MUST either be reliable or missing reliability 476 MUST be known and indicated. The metering process is reliable if each 477 packet passing the observation point is metered according to the 478 configuration of the metering process. If, e.g. due to some overload, 479 not all passing packets can be included into the metering process, 480 then the metering process MUST be able to detect this failure and to 481 report about it. 483 5.2. Sampling 485 Sampling describes the systematic or random selection of a subset of 486 elements (the sample) out of a set of elements (the parent 487 population). Usually the purpose of applying sampling techniques is 488 to estimate a parameter of the parent population by using only the 489 elements of the subset. Sampling techniques can be applied for 490 instance to select a subset of packets out of all packets of a flow 491 or to select a subset of flows out of all flows on a link. Sampling 492 methods differ in their sampling strategy (e.g. systematic or random) 493 and in the event that triggers the selection of an element. The 494 selection of one packet can for instance be triggered by its arrival 495 time (time-based sampling), by its position in the flow (count-based 496 sampling) or by the packet content (content-based sampling). 498 The metering process MAY support packet sampling. If sampling is 499 supported the sampling configuration MUST be well defined. The 500 sampling configuration includes the sampling method and all its 501 parameters. 503 If the sampling configuration is changed during operation, the new 504 sampling configuration with its parameters MUST be indicated to all 505 collecting processes receiving the affected flow records. Changing 506 the sampling configuration includes: adding a sampling function to 507 the metering process, removing a sampling function from the metering 508 process, change sampling method, and change sampling parameter(s). 510 In case of any change in the sampling configuration, all flow records 511 metered by the previous sampling configuration MUST be terminated and 512 exported according to the export configuration. The metering process 513 MUST NOT merge the flow records generated with the new sampling 514 configuration with the flow records generated with the previous 515 sampling configuration. 517 5.3. Overload Behavior 519 In case of an overload, for example lack of memory or processing 520 power, the metering process MAY change its behavior in order to cope 521 with the lack of resources. Possible reactions include: 523 - Reduce the number of flows to be metered. This can be achieved 524 by more coarse-grained flow measurement or by a restriction of 525 the flow records to a subset of the set of original ones. 527 - Start sampling packets before they are processed by the 528 metering process or - if sampling is already performed - reduce 529 the sampling frequency. 531 - Stop metering. 533 - Reducing the resource usage of competing processes on the same 534 device. Example: reducing the packet forwarding throughput 536 Overload behavior is not restricted to the four options listed above. 537 But in case the overload behavior induces a change of the metering 538 process behavior, the overload behavior MUST be clearly defined. 540 For some flows, the change of behavior might have an impact on the 541 data that would be stored in the associated flow records after the 542 change, for example if the packet classification is changed or the 543 sampling frequency. These flows MUST be considered as terminated and 544 the associated flow records MUST be exported separately from new ones 545 generated after the behavior change. The terminated flow records and 546 new ones generated after the behavior change MUST NOT be merged by 547 the metering process. The collecting process MUST be able to 548 distinguish the affected flow records generated before and after the 549 change of behavior. This requirement does not apply to flows and 550 associated flow records not affected by the change of metering 551 process behavior. 553 5.4. Timestamps 555 The metering process MUST be able to generate timestamps for the 556 first and the last observation of a packet of a flow at the 557 observation point. The timestamp resolution MUST be at least the one 558 of the sysUpTime [RFC3418], which is one centisecond. 560 5.5. Time Synchronization 562 It MUST be possible to synchronize timestamps generated by a metering 563 process with Coordinated Universal Time (UTC). 565 Note that the possibility of synchronizing timestamps of each single 566 metering process with UTC implies the possibility of synchronizing 567 timestamps generated by different metering processes. 569 Note that this does not necessarily imply that timestamps generated 570 by the metering process are UTC timestamps. For example, this 571 requirement can be met by using local system clock values as 572 timestamps and adding an additional timestamp when exporting a report 573 to a collecting process. Then the collecting process can synchronize 574 the timestamps by calculating the offset between UTC and the system 575 clock of the metering process. 577 5.6. Flow Expiration 579 The metering process MUST be able to detect flow expirations. A flow 580 is considered to be expired if no packet of this flow has been 581 observed for a given timeout interval. The metering process MAY 582 support means for detecting the expiration of a flow before a timeout 583 occurs, for example by detecting the FIN or RST bits in a TCP 584 connection. The procedure for detecting a flow expiration MUST be 585 clearly defined. 587 5.7. Multicast Flows 589 For multicast flows containing packets replicated to multiple output 590 interfaces, the metering process SHOULD be able to maintain discrete 591 flow records per different output interface. For example, the 592 metering process SHOULD be able to report an incoming multicast 593 packet that is replicated to four output interfaces in four different 594 flow records that differ by the output interface. 596 5.8. Packet Fragmentation 598 In case of IP packet fragmentation and depending on the 599 classification scheme, only the zero-offset fragment of a single 600 initial packet might contain sufficient information to classify the 601 packet. Note that this fragment should be the first one generated by 602 the router imposing the fragmentation [RFC791], but might not be the 603 first one observed by the IPFIX device, due reordering reasons. The 604 metering process MAY keep state of IP packet fragmentation in order 605 to map fragments that do not contain sufficient header information 606 correctly to flows. 608 5.9. Ignore Port Copy 610 The metering process MAY be able to ignore packets which are 611 generated by a port copy function acting at the device where the 612 observation point of a flow is located. 614 6. Data Export 616 The following are requirements for exporting flow records out of the 617 exporting process. Beside requirements on the data transfer, we 618 separate requirements concerning the information model from 619 requirements concerning the data model. Furthermore, we list 620 requirements on reporting times, notification on specific events, and 621 on anonymization of flow records. 623 6.1. Information Model 625 The information model for the flow information export is the list of 626 attributes of a flow to be contained in the report (including the 627 semantics of the attributes). 629 This section lists attributes an exporting process MUST, SHOULD or 630 MAY be able to report. This does not imply that each exported flow 631 record MUST contain all REQUIRED attributes. But it implies that it 632 MUST be possible to configure the exporting process in a way that the 633 information of all REQUIRED attributes can be transmitted from the 634 exporting process to the receiving collecting process(es) for each 635 exported flow. 637 In other words, meeting the IPFIX requirements means that the 638 exporting process in general must be able, via its configuration, to 639 somehow support to report all the MUST fields, even if in certain 640 circumstance or for certain applications, only a subset of the set of 641 all MUST fields is needed and effectively reported. 643 Beyond that, the exporting process might offer to report further 644 attributes not mentioned here. A particular flow record may contain 645 some of the "REQUIRED" attributes as well as some additional ones, 646 for example covering future technologies. 648 This document does not impose that the following attributes are 649 reported for every single flow record, especially for repetitive 650 attributes. For example, if the observation point is the incoming 651 packet stream at the IP interface with the ifIndex value 3, then this 652 observation point does not have to be exported as part of every 653 single flow record. Exporting it just once might give sufficient 654 information to the collecting process. 656 The exporting process MUST be able to report the following attributes 657 for each metered flow: 659 1. IP version number 660 This requirement only applies if the observation point is 661 located at a device supporting more than one version of IP. 662 2. source IP address 663 3. destination IP address 664 4. IP protocol type (TCP,UDP,ICMP,...) 665 5. if protocol type is TCP or UDP: source TCP/UDP port number 666 6. if protocol type is TCP or UDP: destination TCP/UDP port number 667 7. packet counter 668 If a packet is fragmented, each fragment is counted as an 669 individual packet. 670 8. byte counter 671 The sum of the total length in bytes of all IP packets 672 belonging to the flow. The total length of a packet covers IP 673 header and IP payload. 674 9. type of service octet (in case of IPv4), traffic class 675 octet (in case of IPv6). According to RFC 2474 these octets 676 include the DiffServ Code Point that has a length of 6 bit. 677 10. in case of IPv6: Flow Label 678 11. if MPLS is supported at the observation point: the top MPLS 679 label or the corresponding forwarding equivalence class (FEC, 680 [RFC3031]) bound to that label. The FEC is typically defined by 681 an IP prefix. 683 12. timestamp of the first packet of the flow 684 13. timestamp of the last packet of the flow 685 14. if sampling is used: sampling configuration 686 15. unique identifier of the observation point 687 16. unique identifier of the exporting process 689 The exporting process SHOULD be able to report the following 690 attributes for each metered flow: 692 17. if protocol type is ICMP: ICMP type and code 693 18. input interface (ifIndex) 694 This requirement does not apply if the observation point is 695 located at a probe device. 696 19. output interface (ifIndex) 697 This requirement does not apply if the observation point is 698 located at a probe device. 699 20. multicast replication factor 700 the number of outgoing packets originating from a single 701 incoming multicast packet. This is a dynamic property of 702 multicast flows, that may change over time. For unicast flows 703 it has the constant value 1. The reported value MUST be the 704 value of the factor at the time the flow record is exported. 706 The exporting process MAY be able to report the following attributes 707 for each metered flow: 709 21. Time To Live (in case of IPv4) or Hop Limit (in case of IPv6) 710 22. IP header flags 711 23. TCP header flags 712 24. dropped packet counter at the observation point 713 If a packet is fragmented, each fragment MUST be counted as an 714 individual packet. 715 25. fragmented packet counter 716 counter of all packets for which the fragmented bit is set in 717 the IP header 718 26. next hop IP address 720 27. source BGP Autonomous System number (see [RFC1771]) 722 28. destination BGP Autonomous System number 724 29. next hop BGP Autonomous System number 726 6.2. Data Model 728 The data model describes how information is represented in flow 729 records. 731 The data model MUST be extensible for future attributes to be added. 732 Even if a set of attributes is fixed in the flow record, the data 733 model MUST provide a way of extending the record by configuration or 734 for certain implementations. 736 The data model used for exporting flow information MUST be flexible 737 concerning the flow attributes contained in flow records. A flexible 738 record format would offer the possibility of defining records in a 739 flexible (customizable) way regarding the number and type of 740 contained attributes. 742 The Data Model SHOULD be independent of the underlying transport 743 protocol, i.e. the data transfer. 745 6.3. Data Transfer 747 Requirements for the data transfer include reliability, congestion 748 awareness, and security requirements. For meeting these requirements 749 the exporting process can utilize existing security features provided 750 by the device hosting the process and/or provided by the transport 751 network. For example it can use existing security technologies for 752 authentication and encryption or it can rely on physical protection 753 of a separated network for transferring flow information. 755 6.3.1. Congestion Awareness 757 For the data transfer, a congestion aware protocol MUST be supported. 759 6.3.2. Reliability 761 Loss of flow records during the data transfer from the exporting 762 process to the collecting process MUST be indicated at the collecting 763 process. This indication MUST allow the collecting process to gauge 764 the number of flow records lost. Possible reasons for flow records 765 loss include but are not limited to: 767 1. Metering process limitations: lack of memory, processing power, 768 etc. These limitations are already covered in section 5.1. 770 2. Exporting process limitations: lack of memory, processing 771 power, etc. 773 3. Data transfer problems: packets that carry flow records sent 774 from the exporting process to the collecting process, are 775 dropped by the network. Examples are connection failures, 776 congestions in combination with an unreliable transport 777 protocol, etc. 779 4. Collecting process limitations: it may be experiencing 780 congestion and not able to buffer new flows records. 782 5. Operation and Maintenance: the collecting process is taken down 783 for maintenance or other administrative purposes. 785 Please note that if an unreliable transport protocol is used, 786 reliability can be provided by higher layers. If reliability is 787 provided by higher layers, only lack of overall reliability MUST be 788 indicated. For example reordering could be dealt with by adding a 789 sequence number to each packet. 791 The data transfer between exporting process and collecting process 792 MUST be open to reliability extensions including at least 793 - retransmission of lost flow records, 794 - detection of disconnection and fail-over, and 795 - acknowledgement of flow records by the collecting process. 796 This extensibility MAY be used to provide additional reliability. 798 6.3.3. Security 800 Confidentiality of flow specific data transferred from an exporting 801 process to a collecting process SHOULD be ensured. 803 Integrity of IPFIX data transferred from an exporting process to a 804 collecting process MUST be ensured. 806 Authenticity of IPFIX data transferred from an exporting process to a 807 collecting process MUST be ensured. 809 The security requirements have been derived from an analysis of 810 potential security threads. The analysis is summarized in Section 10. 812 6.4. Push and Pull Mode Reporting 814 In general, there are two ways of deciding on reporting times: push 815 mode and pull mode. In push mode, the exporting process decides 816 without an external trigger when to send flow records. In pull mode, 817 sending flow records is triggered by an explicit request from a 818 collecting process. The exporting process MUST support push mode 819 reporting, it MAY support pull mode reporting. 821 6.5. Regular Reporting Interval 823 The exporting process SHOULD be capable of reporting measured traffic 824 data regularly according to a given interval length. 826 6.6. Notification on Specific Events 828 The exporting process MAY be capable of sending notifications to a 829 collecting process, if a specific event occurs. Such an event can be 830 for instance the arrival of the first packet of a new flow, or the 831 termination of a flow after flow timeout. 833 6.7. Anonymization 835 The exporting process MAY be capable of anonymizing source and 836 destination IP addresses in flow data before exporting them. It MAY 837 support anonymization of port numbers and other fields. Please note 838 that anonymization is not originally an application requirement, but 839 derived from general requirements for treatment of measured traffic 840 data within a network. 842 When anonymized flow data is exported, this MUST be clearly indicated 843 to all receiving collecting processes, such that they can distinguish 844 anonymized data from non-anonymized data. 846 7. Configuration 848 If configuration is done remotely, security SHOULD be provided for 849 the configuration process covering confidentiality, integrity and 850 authenticity. The means used for remote configuration are out of the 851 scope of this document. 853 7.1. Configuration of the Metering Process 855 The metering process MUST provide a way of configuring traffic 856 measurement. The following parameters of the metering process SHOULD 857 be configurable: 859 1. specification of the observation point 860 e.g. an interface or a list of interfaces to be monitored. 861 2. specifications of flows to be metered 862 3. flow timeouts 864 The following parameters MAY be configurable: 866 4. sampling method and parameters, if feature is supported 867 5. overload behavior, if feature is supported 869 7.2. Configuration of the Exporting Process 871 The exporting process MUST provide a way of configuring the data 872 export. The following parameters of the exporting process SHOULD be 873 configurable: 875 1. reporting data format 876 Specifying the reporting data format MUST include a selection 877 of attributes to be reported for each flow. 878 2. the collecting process(es) to which flows are reported 879 3. the reporting interval 880 This requirement only applies if the exporting process supports 881 reporting in regular intervals. 883 4. notifications to be sent to the collecting process(es) 884 This requirement only applies if the exporting process supports 885 notifications. 886 5. flow anonymization 887 This requirement only applies if the exporting process supports 888 flow anonymization. 890 8. General Requirements 892 8.1. Openness 894 IPFIX specifications SHOULD be open to future technologies. This 895 includes extensibility of configuration of the metering process and 896 the exporting process. 898 Openness is also required concerning the extensibility of the data 899 model, as stated in section 6.2. 901 8.2. Scalability 903 Data collection from hundreds of different exporting processes MUST 904 be supported. The collecting process MUST be able to distinguish 905 several hundred exporting processes by their identifiers. 907 8.3. Several Collecting Processes 909 The exporting process MAY be able to export flow information to more 910 than one collecting process. If an exporting process is able to 911 export flow records to multiple collecting processes then it MUST be 912 able to ensure that the flow records can be identified so that 913 duplicates can be detected between different collecting processes and 914 double counting problems can be avoided. 916 9. Special Device Considerations 918 This document intends to avoid constraining the architecture of 919 probes, routers, and other devices hosting observation points, 920 metering processes, exporting processes, and/or collecting processes. 921 It can be expected that typically observation point, metering 922 process, and exporting process are co-located at a single device. 923 However, the requirements defined in this document do not exclude 924 devices that derive from this configuration. Figure 2 shows some 925 examples. 927 +---+ +-----+ +---------+ +---------+ 928 | E-+-> | E--+-> | E----+-> <-+--E E--+-> 929 | | | | | | | / \ | | | | | 930 | M | | M | | M M | | M M | 931 | | | | /|\ | | /|\ /|\ | | /|\ /|\ | 932 | O | | OOO | | OOO OOO | | OOO OOO | 933 +---+ +-----+ +---------+ +---------+ 934 Probe Basic Complex Multiple 935 Router Router Exporting 936 Processes 938 +---+ +---+ +---+ 939 | E-+-> | E-+-> | E-+------------->---+ 940 | | | | | | | | | +---+ +-+-----+ 941 +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> 942 | | | | | | | | | | +---+ +-+-----+ 943 +-+-+ +-+-+ | O | | M | | E-+->---+ 944 | | | | +---+ | | | | | | 945 | M | +-+-+ | O | | M | 946 | | | | | | +---+ | | | +-----+ 947 | O | | O | | O | ->-+-C-E-+-> 948 +---+ +---+ +---+ +-----+ 950 Protocol Remote Concentrator Proxy 951 Converter Observation 953 Figure 2: IPFIX-related Devices 955 All examples are composed of one or more of the following elements: 956 observation point (O), metering process (M), exporting process (E), 957 collecting process (C). The observation points shown in the figure 958 are always the most fine-granular ones supported by the respective 959 device. 961 A very simple device is a probe. A typical probe contains a single 962 observation point, a single metering process, and a single exporting 963 process. 965 A basic router extends this structure by multiple observation points. 966 Here, the observation point of a particular flow may be one of the 967 displayed most fine-granular observation points, but also it may be a 968 set of them. 970 A more complex router may host more than one metering process, for 971 example one per line card. Please note that here, the observation 972 point of a single flow cannot exceed the set of most fine-granular 973 observation points linked to a single metering process, because only 974 the metering process can merge packets observed at different fine- 975 granular observation points to a joint flow. An observation point 976 containing all most fine-granular observation points of this router 977 is not possible with this structure. Alternatively, a complex router 978 may host different exporting processes for flow records generated by 979 different metering processes. 981 A protocol converter makes use of a metering process that can be 982 accessed only by another protocol than the one defined for IPFIX, for 983 example the SNMP and the Meter MIB module [RFC2720]. Then the 984 exporting process receives flow record from a remote metering process 985 and exports these records using the IPFIX protocol. Please note, that 986 this document does not make any particular assumption on how metering 987 processes and export processes exchange information, as long as all 988 individual requirements for these processes are met. Also the 989 locations of metering processes are not of any relevance for this 990 document (in contrast to the locations of observation points and the 991 exporting processes). 993 In the example of remote packet observation in Figure 2 the metering 994 process and the observation point are not co-located. Packet header 995 captured at an observation point may be exported as raw data to a 996 device hosting metering process and exporting process. Again, this 997 document does not make any particular assumption on how packet 998 headers are transferred from observation points to metering 999 processes, as long as all requirements for the metering processes are 1000 met. 1002 An intermediate structure between protocol converter and remote 1003 observation (not shown in the Figure) would be a split metering 1004 process, for example performing timestamping and sampling at the 1005 device hosting the observation point and performing packet 1006 classification at another device hosting the exporting process. 1008 A concentrator receives flow records via the IPFIX protocol, merges 1009 them into more aggregated flow records, and exports them again using 1010 the IPFIX protocol. Please note, that for the final flow records the 1011 resulting observation point may be a superset of the more fine- 1012 granular observation points at the first level devices. The metering 1013 process of the final flow records is composed by the (partial) 1014 metering processes at the first level devices and the partial 1015 metering process at the concentrator. 1017 Finally, a very simple IPFIX-related device is a proxy. It just 1018 receives flow records using the IPFIX protocol and sends them further 1019 using the same protocol. A proxy might be useful for traversing 1020 firewalls or other gateways. 1022 10. Security Considerations 1024 An IPFIX protocol must be capable to transport data over the public 1025 Internet. Therefore it cannot be excluded that an attacker captures 1026 or modifies packets or inserts additional packets. 1028 This section describes security requirements for IPFIX. Like other 1029 requirements, the security requirements differ among the considered 1030 applications. The incentive to modify collected data for accounting 1031 or intrusion detection for instance is usually higher than the 1032 incentive to change data collected for traffic profiling. A detailed 1033 list of the required security features per application can be found 1034 in the appendix. 1036 The suggestion of concrete solutions for achieving the required 1037 security properties should be part of an IPFIX architecture and 1038 protocol. It is out of scope of this document. Also methods for 1039 remote configuration of the metering processes and exporting 1040 processes are out of scope. Therefore, threats that are caused by 1041 data exchange for remote configuration are not considered here. 1043 The following potential security hazards for an IPFIX protocol have 1044 been identified: disclosure of IP flow information, forgery of flow 1045 records, and Denial of Service (DoS) attacks. 1047 10.1. Disclosure of Flow Information Data 1049 The content of data exchanged by an IPFIX protocol (for example IPFIX 1050 flow records) should be kept confidential between the involved 1051 parties (exporting process and collecting process). Observation of 1052 IPFIX flow records gives an attacker information about the active 1053 flows in the network, communication endpoints and traffic patterns. 1054 This information cannot only be used to spy out user behavior but 1055 also to plan and conceal future attacks. Therefore, the requirements 1056 specified in section 6.3.3. include confidentiality of the 1057 transferred data. This can be achieved for instance by encryption. 1059 10.2. Forgery of Flow Records 1061 If flow records are used in accounting and/or security applications, 1062 there are potentially strong incentives to forge exported IPFIX flow 1063 records (for example to save money or prevent the detection of an 1064 attack). This can be done either by altering flow records on the path 1065 or by injecting forged flow records that pretend to be originated by 1066 the original exporting process. 1068 Special caution is required if security applications rely on flow 1069 measurements. With forged flow records it is possible to trick on 1070 security applications. It is for instance possible to pretend that a 1071 DoS attack happens without even launching a real attack. If such an 1072 injection of IPFIX traffic flow records fools the security 1073 application, pretending that a DoS attack is underway, then the 1074 countermeasures employed by the security application may actually 1075 deny useful non-malicious services. 1077 In order to make an IPFIX protocol resistant against such attacks, 1078 authentication and integrity must be provided, as specified in 1079 section 6.3.3. 1081 10.3. Denial of Service (DoS) Attacks 1083 DoS attacks on routers or other middleboxes that have the IPFIX 1084 protocol implemented would also affect the IPFIX protocol and impair 1085 the sending of IPFIX records. Nevertheless, since such hazards are 1086 not induced specifically by the IPFIX protocol the prevention of such 1087 attacks is out of scope of this document. 1089 However, IPFIX itself also causes potential hazards for DoS attacks. 1090 All processes that expect the reception of traffic can be target of a 1091 DoS attack. With the exporting process this is only the case if it 1092 supports the pull mode (which can be an optional feature of the IPFIX 1093 protocol according to this document). The collecting process always 1094 expects data and therefore can be flooded by flow records. 1096 11. Acknowledgments 1098 Many thanks Georg Carle for contributing to the application analysis, 1099 to K.C. Norseth for several fine-tunings, to Sandra Tartarelli for 1100 checking the appendix, and to a lot of further people on the mailing 1101 list providing valuable comments and suggestions including Nevil 1102 Brownlee, Carter Bullard, Paul Calato, Ram Gopal, Tal Givoly, Jeff 1103 Meyer, Reinaldo Penno, Sonia Panchen, Simon Leinen, David Plonka, 1104 Ganesh Sadasivan, Kevin Zhang, and many more. 1106 12. Appendix: Derivation of Requirements from Applications 1108 The following table documents, how the requirements stated in 1109 sections 3-7 are derived from requirements of the applications listed 1110 in section 2. 1112 Used abbreviations: 1113 M = MUST 1114 S = SHOULD 1115 O = MAY (OPTIONAL) 1116 - = DONT CARE 1118 -----------------------------------------------------------------------. 1119 IPFIX | 1120 ----------------------------------------------------------------. | 1121 E: QoS Monitoring | | 1122 ----------------------------------------------------------. | | 1123 D: Attack/Intrusion Detection | | | 1124 ----------------------------------------------------. | | | 1125 C: Traffic Engineering | | | | 1126 ----------------------------------------------. | | | | 1127 B: Traffic Profiling | | | | | 1128 ----------------------------------------. | | | | | 1129 A: Usage-based Accounting | | | | | | 1130 ----------------------------------. | | | | | | 1131 | | | | | | | 1132 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1133 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1134 | 4. | DISTINGUISHING FLOWS | 1135 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1136 | 4. | Combination of | M | M | M | M | M | M | 1137 | | required attributes | | | | | | | 1138 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1139 | 4.1. | in/out IF | S | M | M | S | S | M | 1140 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1141 | 4.2. | src/dst address | M | M | M | M | M | M | 1142 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1143 | 4.2. | Masking of IP adresses | M | M | M | M | M | M | 1144 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1145 | 4.2. | transport protocol | M | M | - | M | M | M | 1146 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1147 | 4.2. | version field | - | S | S | O | O | S | 1148 | | | | | (b) | | | | 1149 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1150 | 4.3. | src/dst port | M | M | - | M | M | M | 1151 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1152 | 4.4. | MPLS label (a) | S | S | M | O | S | M | 1153 | | | | | (c) | | | | 1154 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1155 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1156 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1157 | 4.5. | DSCP (a) | M | S | M | O | M | M | 1158 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1159 | 5. | METERING PROCESS | 1160 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1161 | 5.1. | Reliability | M | S | S | S | S | | 1162 |-------+-------------------------+-----+-----+-----+-----+-----+ M | 1163 | 5.1. | Indication of | - | M | M | M | M | | 1164 | | missing reliability | | | | | | | 1165 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1166 | 5.2. | Sampling (d,e) | O | O | O | O | O | O | 1167 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1168 | 5.3. | Overload Behavior (f) | O | O | O | O | O | O | 1169 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1170 | 5.4. | Timestamps | M | O | O | S | M | M | 1171 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1172 | 5.5. | Time synchronization | M | S | S | S | M | M | 1173 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1174 | 5.6. | Flow timeout | M | S | - | O | O | M | 1175 | | | (g) | | | | | | 1176 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1177 | 5.7. | Multicast flows | S | O | O | O | S | S | 1178 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1179 | 5.8. | Packet fragmentation | O | O | - | - | - | O | 1180 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1181 | 5.9. | Ignore port copy | O | O | O | O | O | O | 1182 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1183 | 6. | DATA EXPORT | 1184 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1185 | 6.1. | INFORMATION MODEL | 1186 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1187 | 6.1. | IP Version | - | M | M | O | O | M | 1188 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1189 | 6.1. | src/dst address | M | M | M | M | M | M | 1190 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1191 | 6.1. | transport protocol | M | M | - | M | M | M | 1192 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1193 | 6.1. | src/dst port | M | M | - | M | M | M | 1194 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1195 | 6.1. | Packet counter (h) | S | M | M | S | S | M | 1196 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1197 | 6.1. | Byte counter | M | M | M | S | S | M | 1198 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1199 | 6.1. | ToS (IPv4) or traffic | M | S | M | O | M | M | 1200 | | class octet (IPv6) | | | | | | | 1201 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1202 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1203 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1204 | 6.1. | Flow Label (IPv6) | M | S | M | O | M | M | 1205 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1206 | 6.1. | MPLS label (a) | S | S | M | O | S | M | 1207 | | | | | (c) | | | | 1208 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1209 | 6.1. | Timestamps for | M | O | O | S | S | M | 1210 | | first/last packet | | | | | | | 1211 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1212 | 6.1. | Sampling configuration | M | M | M | M | M | M | 1213 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1214 | 6.1. | observation point | M | M | M | M | M | M | 1215 | | identifier | | | | | | | 1216 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1217 | 6.1. | export process | M | M | M | M | M | M | 1218 | | identifier | | | | | | | 1219 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1220 | 6.1. | ICMP type and code (i) | S | S | - | S | S | S | 1221 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1222 | 6.1. | input/output interface | S | S | S | S | S | S | 1223 | | (j) | | | | | | | 1224 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1225 | 6.1. | Multicast | O | S | S | - | S | S | 1226 | | replication factor | | | | | | | 1227 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1228 | 6.1. | TTL | O | O | O | O | O | O | 1229 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1230 | 6.1. | IP header flags | - | O | O | O | O | O | 1231 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1232 | 6.1. | TCP header flags | - | O | O | O | - | O | 1233 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1234 | 6.1. | Dropped Packet | O | O | O | O | O | O | 1235 | | Counter (h,k) | | | | | | | 1236 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1237 | 6.1. | Fragment counter | - | O | O | O | O | O | 1238 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1239 | 6.1. | next hop IP address | O | O | O | O | - | O | 1240 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1241 | 6.1. | src / dst / next hop | - | O | O | - | - | O | 1242 | | BGP AS # | | | | | | | 1243 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1244 | 6.2. | DATA MODEL | 1245 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1246 | 6.2. | Flexibility | M | S | M | M | M | M | 1247 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1248 | 6.2. | Extensibility | M | S | M | M | M | M | 1249 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1250 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1251 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1252 | 6.3. | DATA TRANSFER | 1253 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1254 | 6.3.1.| Congestion aware | M | M | M | M | M | M | 1255 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1256 | 6.3.2.| Reliability | M | S | S | S | S | M | 1257 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1258 | 6.3.3.| Confidentiality | S | S | S | S | S | S | 1259 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1260 | 6.3.4.| Integrity | M | M | M | M | M | M | 1261 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1262 | 6.3.5.| Authenticity | M | M | M | M | M | M | 1263 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1264 | 6.4. | REPORTING TIMES | 1265 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1266 | 6.4. | Push mode | M | O | O | M | S | M | 1267 | | | | (l) | (l) | |(l,m)| | 1268 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1269 | 6.4. | Pull mode | O | O | O | O | O | O | 1270 | | | | (l) | (l) | | (l) | | 1271 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1272 | 6.4.1.| Regular interval | S | S | S | S | S | S | 1273 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1274 | 6.6. | Notifications | O | O | O | O | O | O | 1275 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1276 | 6.7. | Anonymization (n) | O | O | O | O | O | O | 1277 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1278 | 7. | CONFIGURATION | 1279 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1280 | 7. | Secure remote | S | S | S | S | S | S | 1281 | | configuration (a) | | | | | | | 1282 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1283 | 7.1. | Config observation point| S | S | S | S | S | S | 1284 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1285 | 7.1. | Config flow | S | S | S | S | S | S | 1286 | | specifications | | | | | | | 1287 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1288 | 7.1. | Config flow timeouts | S | S | S | S | O | S | 1289 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1290 | 7.1. | Config sampling | O | O | O | O | O | O | 1291 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1292 | 7.1. | Config overload | O | O | O | O | O | O | 1293 | | behavior (a) | | | | | | | 1294 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1295 | 7.2. | Config report | S | S | S | S | S | S | 1296 | | data format | | | | | | | 1297 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1298 | Sect. | Requirement | A | B | C | D | E | IPFIX| 1299 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1300 | 7.2. | Config | S | S | S | S | S | S | 1301 | | notifications | | | | | | | 1302 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1303 | 7.2. | Config anonymization (a)| S | S | S | S | S | S | 1304 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1305 | 8. | GENERAL REQUIREMENTS | 1306 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1307 | 8.1. | Openness | S | S | S | S | S | S | 1308 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1309 | 8.2. | Scalability: | | | | | | | 1310 | | data collection | M | S | M | O | S | M | 1311 | | from hundreds of | | | | | | | 1312 | | measurement devices | | | | | | | 1313 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1314 | 8.3. | Several collectors | O | O | O | O | O | O | 1315 |-------+-------------------------+-----+-----+-----+-----+-----+------| 1317 Remarks: 1318 (a) If feature is supported. 1319 (b) The differentiation of IPv4 and IPv6 is for TE of importance. 1320 So we tended to make this a MUST. Nevertheless, a SHOULD seems 1321 to be sufficient to perform most TE tasks and allows us to have 1322 a SHOULD for IPFIX instead of a MUST. 1323 (c) For TE in an MPLS network the label is essential. Therefore a 1324 MUST is given here leading to a MUST in IPFIX. 1325 (d) If sampling is supported, the methods and parameters MUST be 1326 well defined. 1327 (e) If sampling is supported, sampling configuration changes MUST 1328 be indicated to all collecting processes. 1329 (f) If overload behavior is supported and it induces changes in the 1330 metering process behavior, the overload behavior MUST be 1331 clearly defined. 1332 (g) Precise time-based accounting requires reaction to a flow 1333 timeout. 1334 (h) If a packet is fragmented, each fragment is counted as an 1335 individual packet. 1336 (i) If protocol type is ICMP. 1337 (j) This requirement does not apply if the observation point is 1338 located at a probe device. 1339 (k) Only if measurement is done on data path i.e. has access to 1340 forwarding decision. 1341 (l) Either push or pull has to be supported. 1342 (m) Required, in order to immediately report drop indications for 1343 SLA validation. 1344 (n) Anonymization MUST be clearly indicated to all receiving 1345 collecting processes. 1347 13. Normative References 1349 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 1350 Switching Architecture", RFC 3031, January 2001. 1352 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the 1353 Differentiated Services Field (DS Field) in the IPv4 and 1354 IPv6 Headers", RFC 2474, December 1998. 1356 [RFC791] J. Postel. "Internet Protocol", RFC791, September 1981. 1358 14. Informative References 1360 [RFC3234] B. Carpenter, "Middleboxes: taxonomy and issues", RFC 3234, 1361 February 2002. 1363 [RFC2119] S. Bradner "Key words for use in RFCs to Indicate 1364 Requirement Levels", RFC 2119, March 1997. 1366 [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: 1367 A Transport Protocol for Real-Time Applications", RFC 1889, 1368 January 1996. 1370 [RFC2975] B. Aboba, J. Arkko, D. Harrington, "Introduction to 1371 Accounting Management", RFC 2975, October 2000. 1373 [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 1374 "Requirements for Traffic Engineering Over MPLS", RFC 2702, 1375 September 1999. 1377 [RFC1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", 1378 RFC 1771, March 1995. 1380 [RFC3418] R. Presuhn (Ed.), "Management Information Base (MIB) for the 1381 Simple Network Management Protocol (SNMP)", RFC 3418, 1382 December 2002. 1384 [RFC2720] N. Brownlee. "Traffic Flow Measurement: Meter MIB", RFC 1385 2720, October 1999. 1387 15. Authors' Addresses 1389 Juergen Quittek 1390 NEC Europe Ltd., Network Laboratories 1391 Kurfuersten-Anlage 36 1392 69115 Heidelberg 1393 Germany 1395 Phone: +49 6221 90511 15 1396 EMail: quittek@ccrle.nec.de 1398 Tanja Zseby 1399 Fraunhofer Institute for Open Communication Systems (FOKUS) 1400 Kaiserin-Augusta-Allee 31 1401 10589 Berlin 1402 Germany 1404 Phone: +49 30 3463 7153 1405 Email: zseby@fokus.fhg.de 1407 Benoit Claise 1408 Cisco Systems 1409 De Kleetlaan 6a b1 1410 1831 Diegem 1411 Belgium 1413 Phone: +32 2 704 5622 1414 Email: bclaise@cisco.com 1416 Sebastian Zander 1417 Fraunhofer Institute for Open Communication Systems (FOKUS) 1418 Kaiserin-Augusta-Allee 31 1419 10589 Berlin 1420 Germany 1422 Phone: +49 30 3463 7287 1423 Email: zander@fokus.fhg.de 1425 16. Full Copyright Statement 1427 Copyright (C) The Internet Society (2003). All Rights Reserved. 1429 This document and translations of it may be copied and furnished to 1430 others, and derivative works that comment on or otherwise explain it 1431 or assist in its implementation may be prepared, copied, published 1432 and distributed, in whole or in part, without restriction of any 1433 kind, provided that the above copyright notice and this paragraph are 1434 included on all such copies and derivative works. However, this 1435 document itself may not be modified in any way, such as by removing 1436 the copyright notice or references to the Internet Society or other 1437 Internet organizations, except as needed for the purpose of 1438 developing Internet standards in which case the procedures for 1439 copyrights defined in the Internet Standards process must be 1440 followed, or as required to translate it into languages other than 1441 English. 1443 The limited permissions granted above are perpetual and will not be 1444 revoked by the Internet Society or its successors or assigns. 1446 This document and the information contained herein is provided on an 1447 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1448 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1449 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1450 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1451 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.