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