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