idnits 2.17.1 draft-ietf-ipfix-mediators-problem-statement-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (March 27, 2010) is 5137 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) == Outdated reference: A later version (-06) exists of draft-ietf-ipfix-psamp-mib-00 -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group A. Kobayashi, Ed. 3 Internet-Draft NTT PF Lab. 4 Intended status: Informational B. Claise, Ed. 5 Expires: September 28, 2010 Cisco Systems, Inc. 6 March 27, 2010 8 IPFIX Mediation: Problem Statement 9 draft-ietf-ipfix-mediators-problem-statement-09 11 Abstract 13 Flow-based measurement is a popular method for various network 14 monitoring usages. The sharing of flow-based information for 15 monitoring applications having different requirements raises some 16 open issues in terms of measurement system scalability, flow-based 17 measurement flexibility, and export reliability that IPFIX Mediation 18 may help resolve. This document describes some problems related to 19 flow-based measurement that network administrators have been facing, 20 and then describes IPFIX Mediation applicability examples along with 21 the problems. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 28, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 65 3. IPFIX/PSAMP Documents Overview . . . . . . . . . . . . . . . . 7 66 3.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 7 67 3.2. PSAMP Documents Overview . . . . . . . . . . . . . . . . . 7 68 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Coping with IP Traffic Growth . . . . . . . . . . . . . . 8 70 4.2. Coping with Multipurpose Traffic Measurement . . . . . . . 9 71 4.3. Coping with Heterogeneous Environments . . . . . . . . . . 9 72 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5. Mediation Applicability Examples . . . . . . . . . . . . . . . 10 74 5.1. Adjusting Flow Granularity . . . . . . . . . . . . . . . . 10 75 5.2. Collecting Infrastructure . . . . . . . . . . . . . . . . 10 76 5.3. Correlation for Data Records . . . . . . . . . . . . . . . 11 77 5.4. Time Composition . . . . . . . . . . . . . . . . . . . . . 11 78 5.5. Spatial Composition . . . . . . . . . . . . . . . . . . . 12 79 5.6. Data Record Anonymization . . . . . . . . . . . . . . . . 13 80 5.7. Data Retention . . . . . . . . . . . . . . . . . . . . . . 13 81 5.8. IPFIX Export from a Branch Office . . . . . . . . . . . . 14 82 5.9. Distributing Data Records . . . . . . . . . . . . . . . . 15 83 5.10. Flow-based Sampling and Selection . . . . . . . . . . . . 16 84 5.11. Interoperability between Legacy Protocols and IPFIX . . . 17 85 6. IPFIX Mediators Implementation Specific Problems . . . . . . . 18 86 6.1. Loss of Original Exporter Information . . . . . . . . . . 18 87 6.2. Loss of Base Time Information . . . . . . . . . . . . . . 18 88 6.3. Transport Sessions Management . . . . . . . . . . . . . . 19 89 6.4. Loss of Options Template Information . . . . . . . . . . . 19 90 6.5. Template ID Management . . . . . . . . . . . . . . . . . . 19 91 6.6. Consideration for Network Topology . . . . . . . . . . . . 20 92 6.7. IPFIX Mediation Interpretation . . . . . . . . . . . . . . 20 93 6.8. Consideration for Aggregation . . . . . . . . . . . . . . 21 94 7. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 22 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 100 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 103 1. Introduction 105 An advantage of flow-based measurement is that it allows monitoring 106 large amount of traffic observed at distributed observation points. 107 While flow-based measurement can be applied to one of various 108 purposes and applications, it is difficult for flow-based measurement 109 to apply to multiple applications with very different requirements in 110 parallel. Network administrators need to adjust the parameters of 111 the metering devices to fulfill the requirements of every single 112 measurement application. Such configurations are often not supported 113 by the metering devices, either because of functional restrictions or 114 because of limited computational and memory resources, which inhibit 115 the metering of large amounts of traffic with the desired setup. 116 IPFIX Mediation fills the gap between restricted metering 117 capabilities and the requirements of measurement applications by 118 introducing an intermediate device called IPFIX Mediator. 120 The IPFIX requirements defined in [RFC3917] mention examples of 121 intermediate devices located between Exporters and Collectors, such 122 as IPFIX proxies or concentrators. But, there are no documents 123 defining a generalized concept for such intermediate devices. This 124 document addresses that issue by defining IPFIX Mediation, a 125 generalized intermediate device concept for IPFIX, and examining in 126 detail the motivations behind its application. 128 This document is structured as follows: section 2 describes the 129 terminology used in this document, section 3 gives an IPFIX/PSAMP 130 document overview, section 4 introduces general problems related to 131 flow-based measurement, section 5 describes some applicability 132 examples where IPFIX Mediations would be beneficial, and, finally, 133 section 6 describes some problems an IPFIX Mediation implementation 134 might face. 136 2. Terminology and Definitions 138 The IPFIX-specific and PSAMP-specific terminology used in this 139 document is defined in [RFC5101] and [RFC5476], respectively. In 140 this document, as in [RFC5101] and [RFC5476], the first letter of 141 each IPFIX-specific and PSAMP-specific term is capitalized along with 142 the IPFIX Mediation-specific term defined here. 144 In this document, we call "record stream" a stream of records 145 carrying flow- or packet-based information. The records may be 146 encoded as IPFIX Data Records or in any other format. 148 Original Exporter 150 An Original Exporter is an IPFIX Device that hosts the Observation 151 Points where the metered IP packets are observed. 153 IPFIX Mediation 155 IPFIX Mediation is the manipulation and conversion of a record 156 stream for subsequent export using the IPFIX protocol. 158 The following terms are used in this document to describe the 159 architectural entities used by IPFIX Mediation. 161 Intermediate Process 163 An Intermediate Process takes a record stream as its input from 164 Collecting Processes, Metering Processes, IPFIX File Readers, 165 other Intermediate Processes, or other record sources; performs 166 some transformations on this stream, based upon the content of 167 each record, states maintained across multiple records, or other 168 data sources; and passes the transformed record stream as its 169 output to Exporting Processes, IPFIX File Writers, or other 170 Intermediate Processes, in order to perform IPFIX Mediation. 171 Typically, an Intermediate Process is hosted by an IPFIX Mediator. 172 Alternatively, an Intermediate Process may be hosted by an 173 Original Exporter. 175 IPFIX Mediator 177 An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation 178 by receiving a record stream from some data sources, hosting one 179 or more Intermediate Processes to transform that stream, and 180 exporting the transformed record stream into IPFIX Messages via an 181 Exporting Process. In the common case, an IPFIX Mediator receives 182 a record stream from a Collecting Process, but it could also 183 receive a record stream from data sources not encoded using IPFIX, 184 e.g., in the case of conversion from the NetFlow V9 protocol 185 [RFC3954] to IPFIX protocol. 187 Note that the IPFIX Mediator is a generalization of the 188 concentrator and proxy elements envisioned in the IPFIX 189 requirements [RFC3917]. IPFIX Mediators running appropriate 190 Intermediate Processes provide the functionality specified 191 therein. 193 3. IPFIX/PSAMP Documents Overview 195 IPFIX Mediation can be applied to flow- or packet-based information. 196 The flow-based information is encoded by IPFIX protocol, and the 197 packet-based information is extracted by some sampling techniques and 198 then encoded by PSAMP protocol. Thus, this section describes 199 relevant documents for both protocols. 201 3.1. IPFIX Documents Overview 203 The IPFIX protocol [RFC5101] provides network administrators with 204 access to IP flow information. The architecture for the export of 205 measured IP flow information from an IPFIX Exporting Process to a 206 Collecting Process is defined in [RFC5470], per the requirements 207 defined in [RFC3917]. The IPFIX protocol [RFC5101] specifies how 208 IPFIX Data Records and Templates are carried via a number of 209 transport protocols from IPFIX Exporting Processes to IPFIX 210 Collecting Processes. IPFIX has a formal description of IPFIX 211 Information Elements, their names, types, and additional semantic 212 information, as specified in [RFC5102]. [IPFIX-MIB] specifies the 213 IPFIX Management Information Base. Finally, [RFC5472] describes what 214 types of applications can use the IPFIX protocol and how they can use 215 the information provided. It furthermore shows how the IPFIX 216 framework relates to other architectures and frameworks. The storage 217 of IPFIX Messages in a file is specified in [RFC5655]. 219 3.2. PSAMP Documents Overview 221 The framework for packet selection and reporting [RFC5474] enables 222 network elements to select subsets of packets by statistical and 223 other methods and to export a stream of reports on the selected 224 packets to a Collector. The set of packet selection techniques 225 (sampling and filtering) standardized by PSAMP is described in 226 [RFC5475]. The PSAMP protocol [RFC5476] specifies the export of 227 packet information from a PSAMP Exporting Process to a Collector. 228 Like IPFIX, PSAMP has a formal description of its Information 229 Elements, their names, types, and additional semantic information. 230 The PSAMP information model is defined in [RFC5477]. [PSAMP-MIB] 231 describes the PSAMP Management Information Base. 233 4. Problem Statement 235 Network administrators generally face the problems of measurement 236 system scalability, flow-based measurement flexibility, and export 237 reliability, even if some techniques, such as packet Sampling, 238 Filtering, Data Records aggregation and export replication, have 239 already been developed. The problems consist of adjusting some 240 parameters of metering device to resources of the measurement system 241 while fulfilling appropriate conditions: data accuracy, flow 242 granularity, and export reliability. These conditions depend on two 243 factors. 245 o Measurement system capacity: 246 This consists of the bandwidth of the management network, the 247 storage capacity, and the performances of the collecting devices 248 and exporting devices. 250 o Application requirements: 251 Different applications, such as traffic engineering, detecting 252 traffic anomalies, and accounting, impose different Flow Record 253 granularities, and data accuracies. 255 The sustained growth of IP traffic has been overwhelming the 256 measurement system capacities. Furthermore, a large variety of 257 applications (e.g., QoS measurement, traffic engineering, security 258 monitoring) and the deployment of measurement system in heterogeneous 259 environments have been increasing the demand and complexity of IP 260 traffic measurements. 262 4.1. Coping with IP Traffic Growth 264 Enterprise or service provider networks already have multiple 10 Gb/s 265 links, their total traffic exceeding 100 Gb/s. In the near future, 266 broadband users' traffic will increase by approximately 40% every 267 year according to [TRAFGRW]. When administrators monitor IP traffic 268 sustaining its growth at multiple Exporters, the amount of exported 269 Flow Records from Exporters could exceed the ability of single 270 Collector. 272 To deal with this problem, current data reduction techniques (packet 273 Sampling and Filtering in [RFC5475], and aggregation of measurement 274 data) have been generally implemented on Exporters. Note that packet 275 Sampling leads to potential loss of small Flows. With both packet 276 Sampling and aggregation techniques, administrators might no longer 277 be able to detect and investigate subtle traffic changes and 278 anomalies as this requires detailed Flow information. With 279 Filtering, only a subset of the Data Records are exported. 281 Considering the potential drawbacks of packet Sampling, Filtering, 282 and Data Records aggregation, there is a need for a large-scale 283 collecting infrastructure that does not rely on data reduction 284 techniques. 286 4.2. Coping with Multipurpose Traffic Measurement 288 Different monitoring applications impose different requirements on 289 the monitoring infrastructure. Some of them require traffic 290 monitoring at a Flow level while others need information about 291 individual packets or just Flow aggregates. 293 To fulfill these divers requirements, an Exporter would need to 294 perform various complex metering tasks in parallel, which is a 295 problem due to limited resources. Hence, it can be advantageous to 296 run the Exporter with a much simpler setup and to perform appropriate 297 post-processing of the exported Data Records at a later stage. 299 4.3. Coping with Heterogeneous Environments 301 Network administrators use IPFIX Devices and PSAMP Devices from 302 various vendors, various software versions, various device types 303 (router, switch, or probe) in a single network domain. Even legacy 304 flow export protocols are still deployed in current network. This 305 heterogeneous environment leads to differences in Metering Process 306 capabilities, Exporting Process capacity (export rate, cache memory, 307 etc.), and data format. For example, probes and switches cannot 308 retrieve some derived packet properties from a routing table. 310 To deal with this problem, the measurement system needs to mediate 311 the differences. However, equipping all collecting devices with this 312 absorption function is difficult. 314 4.4. Summary 316 Due to resource limitations of the measurement system, it is 317 important to use traffic data reduction techniques as early as 318 possible, e.g., at the Exporter. However, this implementation is 319 made difficult by the heterogeneous environment of exporting devices. 320 On the other hand, keeping data accuracy and flow granularity to meet 321 the requirements of different monitoring applications requires a 322 scalable and flexible collecting infrastructure. 324 This implies that a new Mediation function is required in typical 325 Exporter-Collector architectures. Based on some applicability 326 examples, the next section shows the limitation of the typical 327 Exporter-Collector architecture model and the IPFIX Mediation 328 benefits. 330 5. Mediation Applicability Examples 332 5.1. Adjusting Flow Granularity 334 A simplest set of Flow Keys is a fixed 5-tuple of protocol, source 335 and destination IP addresses, and source and destination port 336 numbers. A shorter set of Flow Keys, such as a triple, a double, or 337 a single property, (for example network prefix, peering autonomous 338 system number, or BGP Next-Hop fields), creates more aggregated Flow 339 Records. This is especially useful for measuring router-level 340 traffic matrices in a core network domain and for easily adjusting 341 the performance of Exporters and Collectors. 343 Implementation analysis: 345 Implementations for this case depend on where Flow granularity is 346 adjusted. More suitable implementations use configurable Metering 347 Processes in Original Exporters. The cache in the Metering 348 Process can specify its own set of Flow Keys and extra fields. 349 The Original Exporter thus generates Flow Records of the desired 350 Flow granularity. 352 In the case where a Metering Process hosting no ability to change 353 the Flow Keys in Original Exporter creates Flow Records, or PSAMP 354 Packet Reports, an IPFIX Mediator can aggregate Data Records based 355 on a new set of Flow Keys. Even in the case of a Metering Process 356 hosting this ability, an IPFIX Mediator can further aggregate the 357 Flow Records. 359 5.2. Collecting Infrastructure 361 Increasing numbers of IPFIX Exporters, IP traffic growth, and the 362 variety of treatments expected to be performed on the Data Records 363 make it more and more difficult to implement all measurement 364 applications within a single Collector. 366 Implementation analysis: 368 To increase the collecting (e.g., the bandwidth capacity) and 369 processing capacity, distributed Collectors close to Exporters 370 need to be deployed. In such a case, those Collectors would 371 become IPFIX Mediators, re-exporting Data Records on demand to 372 centralized applications. To cope with the variety of measurement 373 applications, one possible implementation uses an Intermediate 374 Process deciding to which Collector(s) each record is exported. 375 More specific cases are described in section 5.9. 377 5.3. Correlation for Data Records 379 The correlation amongst Data Records or between Data Record and meta 380 data provides new metrics or information, including the following. 382 o One-to-one correlation between Data Records 384 * One way delay from the correlation of PSAMP Packet Reports from 385 different Exporters along a specific path. For example, one 386 way delay is calculated from correlation of two PSAMP Packet 387 Reports including the packet digest and the arrival time at 388 Observation Point. This cases are described in section 6.2.1.2 389 in [RFC5475]. 391 * Packet inter-arrival time from the correlation of sequential 392 PSAMP Packet Reports from a Exporter. 394 * Treatment from the correlation of Data Records with common 395 properties, observed at incoming/outgoing interfaces. Examples 396 are the rate-limiting ratio, the compression ratio, the 397 optimization ratio, etc. 399 o Correlation amongst Data Records 401 Average/maximum/minimum values from correlating multiple Data 402 Records. Examples are the average/maximum/minimum number of 403 packets of the measured Flows, the average/maximum/minimum one way 404 delay, the average/maximum/minimum number of lost packets, etc. 406 o Correlation between Data Record and other meta data 408 Examples are some BGP attributes associated with Data Record by 409 looking up the routing table. 411 Implementation analysis: 413 One possible implementation for this case uses an Intermediate 414 Process located between the Metering Processes and Exporting 415 Processes on the Original Exporter, or alternatively a separate 416 IPFIX Mediator located between the Original Exporters and IPFIX 417 Collectors. 419 5.4. Time Composition 421 Time composition is defined as the aggregation of consecutive Data 422 Records with identical Flow Keys. It leads to the same output as 423 setting a longer active timeout on Original Exporters with one 424 advantage: the creation of new metrics such as average, maximum and 425 minimum values from Flow Records with a shorter time interval enables 426 administrators to keep track of changes that might have happened 427 during the time interval. 429 Implementation analysis: 431 One possible implementation for this case uses an Intermediate 432 Process located between the Metering Processes and Exporting 433 Processes on the Original Exporter, or alternatively a separate 434 IPFIX Mediator located between the Original Exporters and IPFIX 435 Collectors. 437 5.5. Spatial Composition 439 Spatial composition is defined as the aggregation of Data Records in 440 a set of Observation Points within an Observation Domain, across 441 multiple Observation Domains from a single Exporter, or even across 442 multiple Exporters. The spatial composition is divided into four 443 types. 445 o Cases 1: Spatial composition within one Observation Domain 447 For example, to measure the traffic for a single logical interface 448 in the case where link aggregation [IEEE802.3ad] exists, Data 449 Records metered at physical interfaces belonging to the same trunk 450 can be merged. 452 o Cases 2: Spatial composition across Observation Domains, but 453 within a single Original Exporter 455 For example, in the case where link aggregation exists, Data 456 Records metered at physical interfaces belonging to a same trunk 457 grouping beyond the line card can be merged. 459 o Cases 3: Spatial composition across Exporters 461 Data Records metered within an administrative domain, such as the 462 west area and east area of an ISP network, can be merged. 464 o Cases 4: Spatial composition across administrative domains 466 Data Records metered across administrative domains, such as across 467 different customer networks or different ISP networks, can be 468 merged. For example, an unique Collector knows in which customer 469 network an Explorter exists, and then works out the traffic data 470 per customer based on the Explorter IP address. 472 Implementation analysis: 474 One possible implementation for the cases 1 and 2 uses an 475 Intermediate Process located between the Metering Processes and 476 Exporting Processes on the Original Exporter. A separate IPFIX 477 Mediator located between the Original Exporters and IPFIX 478 Collector is a valid solution for the cases 1, 2, 3, and 4. 480 5.6. Data Record Anonymization 482 IPFIX exports across administrative domains can be used to measure 483 traffic for wide-area traffic engineering or to analyze Internet 484 traffic trends, as described in the spatial composition across 485 administrative domains in the previous subsection. 486 In such a case, administrators need to adhere to privacy protection 487 policies and prevent access to confidential traffic measurements by 488 other people. Typically, anonymization techniques enable the 489 provision of traffic data to other people without violating these 490 policies. 492 Generally, anonymization modifies a data set to protect the identity 493 of the people or entities described by the data set from being 494 disclosed. It also attempts to preserve sets of network traffic 495 properties useful for a given analysis while ensuring the data cannot 496 be traced back to the specific networks, hosts, or users generating 497 the traffic. For example, IP address anonymization is particularly 498 important for avoiding the identification of users, hosts, and 499 routers. As another example, when an ISP provides traffic monitoring 500 service to end customers, network administrators take care of 501 anonymizing interface index fields which could disclose any 502 information about the vendor or software version of the Exporters. 504 Implementation analysis: 506 One possible implementation for this case uses an anonymization 507 function at the Original Exporter. However, this increases the 508 load on the Original Exporter. A more flexible implementation 509 uses a separate IPFIX Mediator between the Original Exporter and 510 Collector. 512 5.7. Data Retention 514 Data retention refers to the storage of traffic data by service 515 providers and commercial organizations. Legislative regulations 516 often require that network operators retain both IP traffic data and 517 call detail records, in wired and wireless networks, generated by end 518 users while using a service provider's services. The traffic data is 519 required for the purpose of the investigation, detection and 520 prosecution of serious crime, if necessary. Data retention examples 521 relevant to IP networks are the following: 523 o Internet telephony (includes every multimedia session associated 524 with IP multimedia services) 526 o Internet e-mail 528 o Internet access 530 Data retention for these services in particular requires a 531 measurement system with reliable export and huge storage as the data 532 must be available for a long period of time, typically at least six 533 months. 535 Implementation analysis: 537 Regarding export reliability requirement, the most suitable 538 implementation uses the SCTP transport protocol between the 539 Original Exporter and Collector. If an unreliable transport 540 protocol such as UDP is used, a legacy exporting device exports 541 Data Records to a nearby IPFIX Mediator through UDP, and then an 542 IPFIX Mediator could reliably export them to the IPFIX Collector 543 through SCTP. If an unreliable transport protocol such as UDP is 544 used and if there is no IPFIX Mediator, the legacy exporting 545 device should duplicate the exports to several Collectors to lower 546 the probability of loosing Flow Records. However, it might result 547 in network congestion, unless dedicated export links are used. 549 Regarding huge storage requirement, the collecting infrastructure 550 is described in section 5.2. 552 5.8. IPFIX Export from a Branch Office 554 Generally, in large enterprise networks, Data Records from branch 555 offices are gathered in a central office. However, in the long 556 distance branch office case, the bandwidth for transporting IPFIX is 557 limited. Therefore, even if multiple Data Record types should be of 558 interest to the Collector (e.g., IPFIX Flow Records in both 559 directions, IPFIX Flow Records before and after WAN optimization 560 techniques, performance metrics associated with the IPFIX Flow 561 Records exported on regular interval, etc.), the export bandwidth 562 limitation is an important factor to pay attention to. 564 Implementation analysis: 566 One possible implementation for this case uses an IPFIX Mediator 567 located in a branch office. The IPFIX Mediator would aggregate 568 and correlate Data Records to cope with the export bandwidth 569 limitation. 571 5.9. Distributing Data Records 573 Recently, several networks have shifted towards integrated networks, 574 such as the pure IP and MPLS networks, which includes IPv4, IPv6, and 575 VPN traffic. Data Record types (IPv4, IPv6, MPLS, and VPN) need to 576 be analyzed separately and from different perspectives for different 577 organizations. A single Collector handling all Data Record types 578 might become a bottleneck in the collecting infrastructure. Data 579 Records distributed based on their respective types can be exported 580 to the appropriate Collector, resulting in the load distribution 581 amongst multiple Collectors. 583 Implementation analysis: 585 One possible implementation for this case uses the replications of 586 the IPFIX Message in an Original Exporter for multiple IPFIX 587 Collectors. Each Collector then extracts the Data Record required 588 by its own applications. However, the replication increases the 589 load of the Exporting Process and the waste of the bandwidth 590 between the Exporter and Collector. 592 A more sophisticated implementation uses an Intermediate Process 593 located between the Metering Processes and Exporting Processes in 594 an Original Exporter. The Intermediate Process determines to 595 which Collector a Data Record is exported depending on certain 596 field values. If a Original Exporter does not have this 597 capability, it exports Data Records to a nearby separate IPFIX 598 Mediator, and then the IPFIX Mediator could distribute them to the 599 appropriate IPFIX Collectors. 601 For example, in the case of distributing a specific customer's 602 Data Records, an IPFIX Mediator needs to identify the customer 603 networks. The Route Distinguisher (RD), ingress interface, 604 peering AS number, or BGP Next-Hop, or simply the network prefix 605 may be evaluated to distinguish different customer networks. In 606 the following figure, the IPFIX Mediator reroutes Data Records on 607 the basis of the RD value. This system enables each customer's 608 traffic to be inspected independently. 610 .---------. 611 |Traffic | 612 .---->|Collector|<==>Customer#A 613 | |#1 | 614 | '---------' 615 RD=100:1 616 .----------. .-----------. | 617 |IPFIX | |IPFIX |----' .---------. 618 |Exporter#1| |Mediator | RD=100:2 |Traffic | 619 | |------->| |--------->|Collector|<==>Customer#B 620 | | | | |#2 | 621 | | | |----. '---------' 622 '----------' '-----------' | 623 RD=100:3 624 | .---------. 625 | |Traffic | 626 '---->|Collector|<==>Customer#C 627 |#3 | 628 '---------' 630 Figure A: Distributing Data Records to Collectors using IPFIX 631 Mediator 633 5.10. Flow-based Sampling and Selection 635 Generally, the distribution of the number of packets per Flow seems 636 to be heavy-tailed. Most types of Flow Records are likely to be 637 small Flows consisting of a small number of packets. The measurement 638 system is overwhelmed with a huge amount of these small Flows. If 639 statistics information of small Flows is exported as merged data by 640 applying a policy or threshold, the load on the Exporter is reduced. 641 Furthermore, if the flow distribution is known, exporting only a 642 subset of the Data Records might be sufficient. 644 Implementation analysis: 646 One possible implementation for this case uses an Intermediate 647 Process located between the Metering Processes and Exporting 648 Processes on the Original Exporter, or alternatively a separate 649 IPFIX Mediator located between the Original Exporters and IPFIX 650 Collectors. A set of IPFIX Mediation functions, such as 651 filtering, selecting and aggregation is used in the IPFIX 652 Mediator. 654 5.11. Interoperability between Legacy Protocols and IPFIX 656 During the migration process from a legacy protocol such as NetFlow 657 [RFC3954] to IPFIX, both NetFlow exporting devices and IPFIX 658 Exporters are likely to coexist in the same network. Operators need 659 to continue measuring the traffic data from legacy exporting devices, 660 even after introducing IPFIX Collectors. 662 Implementation analysis: 664 One possible implementation for this case uses an IPFIX Mediator 665 that converts a legacy protocol to IPFIX. 667 6. IPFIX Mediators Implementation Specific Problems 669 6.1. Loss of Original Exporter Information 671 Both the Exporter IP address indicated by the source IP address of 672 the IPFIX Transport Session and the Observation Domain ID included in 673 the IPFIX Message header are likely to be lost during IPFIX 674 Mediation. In some cases, an IPFIX Mediator might drop the 675 information deliberately. In general, however, the Collector must 676 recognize the origin of the measurement information, such as the IP 677 address of the Original Exporter, the Observation Domain ID, or even 678 the Observation Point ID. Note that, if an IPFIX Mediator cannot 679 communicate the Original Exporter IP address, then the IPFIX 680 Collector will wrongly deduce that the IP address of the IPFIX 681 Mediator is that of the Original Exporter. 683 In the following figure, a Collector can identify two IP addresses: 684 192.0.2.3 (IPFIX Mediator) and 192.0.2.2 (Exporter#2), respectively. 685 The Collector, however, needs to somehow recognize both Exporter#1 686 and Exporter#2, which are the Original Exporters. The IPFIX Mediator 687 must be able to notify the Collector about the IP address of the 688 Original Exporter. 690 .----------. .--------. 691 |IPFIX | |IPFIX | 692 |Exporter#1|--------->|Mediator|---+ 693 | | | | | 694 '----------' '--------' | .---------. 695 IP:192.0.2.1 IP:192.0.2.3 '----->|IPFIX | 696 ODID:10 ODID:0 |Collector| 697 +------>| | 698 .----------. | '---------' 699 |IPFIX | | 700 |Exporter#2|-----------------------' 701 | | 702 '----------' 703 IP:192.0.2.2 704 ODID:20 706 Figure B: Loss of Original Exporter Information. 708 6.2. Loss of Base Time Information 710 The Export Time field included in the IPFIX Message header represents 711 a reference timestamp for Data Records. Some IPFIX Information 712 Elements, described in [RFC5102], carry delta timestamps that 713 indicate the time difference from the value of the Export Time field. 714 If the Data Records include any delta time fields and the IPFIX 715 Mediator overwrites the Export Time field when sending IPFIX 716 Messages, the delta time fields become meaningless and, because 717 Collectors cannot recognize this situation, wrong time values are 718 propagated. 720 6.3. Transport Sessions Management 722 Maintaining relationships between the incoming Transport Sessions and 723 the outgoing ones depends on the Mediator's implementation. If an 724 IPFIX Mediator relays multiple incoming Transport Sessions to a 725 single outgoing Transport Session, and if the IPFIX Mediators shuts 726 down its outgoing Transport Session, Data Records of the incoming 727 Transport Sessions would not be relayed any more. In the case of 728 resetting an incoming Transport Session, the behavior of the IPFIX 729 Mediator needs to be specified. 731 6.4. Loss of Options Template Information 733 In some cases, depending on the implementation of the IPFIX 734 Mediators, the information reported in the Data Records defined by 735 Options Templates could also be lost. If, for example, the Sampling 736 rate is not communicated from the Mediator to the Collector, the 737 Collector would miscalculate the traffic volume. This might lead to 738 crucial problems. Even if an IPFIX Mediator was to simply relay 739 received Data Records defined by Options Templates, the values of its 740 scope fields could become meaningless in the content of a different 741 Transport Sessions. The minimal information to be communicated by an 742 IPFIX Mediator must be specified. 744 6.5. Template ID Management 746 The Template ID is unique on the basis of the Transport Session and 747 Observation Domain ID. If an IPFIX Mediation is not able to manage 748 the relations amongst the Template IDs and the incoming Transport 749 Session information, and if the Template ID is used in the Options 750 Template scope, IPFIX Mediators would, for example, relay wrong 751 values in the scope field and in the Template Withdrawal Message. 752 The Collector would thus not be able to interpret the Template ID in 753 the Template Withdrawal Message and in the Options Template scope. 754 As a consequence, there is a risk that the Collector would then shut 755 down the IPFIX Transport Session. 757 For example, an IPFIX Mediator must maintain the state of the 758 incoming Transport Sessions in order to manage the Template ID on its 759 outgoing Transport Session correctly. Even if the Exporter Transport 760 Session re-initializes, the IPFIX Mediator must manage the 761 association of Template IDs in specific Transport Session. In the 762 following figure, the IPFIX Mediator exports three Templates (256, 763 257, and 258), received respectively from Exporter#3, Exporter#2, and 764 Exporter#1. If the Exporter#1 re-initializes, and the Template ID 765 value 258 is now replaced with 256, the IPFIX Mediator must correctly 766 manage the new mapping of (incoming Transport Session, Template ID) 767 and (outgoing Transport Session, Template ID) without shutting down 768 its outgoing Transport Session. 770 .----------. OLD: Template ID 258 771 |IPFIX | NEW: Template ID 256 772 |Exporter#1|----+ 773 | | | 774 '----------' X 775 .----------. | .-----------. .----------. 776 |IPFIX | '---------->| | | | 777 |Exporter#2|--------------->|IPFIX |-------------->|IPFIX | 778 | |Template ID 257 |Mediator |Template ID 258| Collector| 779 '----------' +---------->| |Template ID 257| | 780 .----------. | '-----------'Template ID 256'----------' 781 |IPFIX | | 782 |Exporter#3|----' 783 | | Template ID 256 784 '----------' 786 Figure C: Relaying from Multiple Transport Sessions to Single 787 Transport Session. 789 6.6. Consideration for Network Topology 791 While IPFIX Mediation can be applied anywhere, caution should be 792 taken as how to aggregate the counters, as there is a potential risk 793 of double-counting. For example, if three Exporters export PSAMP 794 Packet Reports related to the same Flow, the one-way delay can be 795 calculated, while summing up the number of packets and bytes does not 796 make sense. Alternatively, if three Exporters export Flow Records 797 entering an administrative domain, then the sum of the packets and 798 bytes is a valid operation. Therefore, the possible function to be 799 applied to Flow Records must take into consideration the measurement 800 topology. The information such as the network topology, or at least 801 the Observation Point and measurement direction, is required for 802 IPFIX Mediation. 804 6.7. IPFIX Mediation Interpretation 806 In some case, the IPFIX Collector needs to recognize which specific 807 function(s) IPFIX Mediation has executed on the Data Records. The 808 IPFIX Collector cannot distinguish between time composition and 809 spatial composition, if the IPFIX Mediator does not export the 810 applied function. Some parameters related to the function also would 811 need to be exported. For example, in case of time composition, the 812 active timeout of original Flow Records is required to interpret the 813 minimum/maximum counter correctly. In case of spatial composition, 814 spatial area information on which Data Records is aggregated is 815 required. 817 6.8. Consideration for Aggregation 819 Whether the aggregation is based on time or spatial composition, 820 caution should be taken on how to aggregate non-key fields in IPFIX 821 Mediation. The IPFIX information model [RFC5102] specifies that the 822 value of non-key fields, which are derived from fields of packets or 823 from packet treatment and for which the value may change from packet 824 to packet within a single Flow, is determined by the first packet 825 observed for the corresponding Flow, unless the description of the 826 Information Element explicitly specifies a different semantics. 828 However, this simple rule might not be appropriate when aggregating 829 Flow Records which have different values in a non-key field. For 830 example, if Differentiated Services Code Point (DSCP) information is 831 to be exported, the following problem can be observed: If two Flows 832 with identical Flow Key values are measured at different Observation 833 Points, they may contain identical packets observed at different 834 locations in the network and at different points in time. On their 835 way from the first to the second Observation Point, the DSCP and 836 potentially some other packet fields may have changed. Hence, if the 837 Information Element ipDiffServCodePoint is included as a non-key 838 field, it can be useful to include the DSCP value observed at either 839 the first or the second Observation Point in the resulting Flow 840 Record, depending on the application. 842 Other potential solutions include: removing the Information Element 843 ipDiffServCodePoint from the Data Record when re-exporting the 844 aggregate Flow Record, changing the Information Element 845 ipDiffServCodePoint from a non key-field to a Flow Key when re- 846 exporting the aggregated Flow Record, or assigning a non valid value 847 for the Information Element to express to the Collector that this 848 Information Element is meaningless. 850 If packet Sampling or Filtering is applied, the IPFIX Mediator must 851 report an adjusted PSAMP Configured Selection Fraction when 852 aggregating IPFIX Flow Records with different sampling rates. 853 Finally, special care must be taken when aggregating Flow Records 854 resulting from different Sampling techniques such as Systematic 855 Count-Based Sampling and Random n-out-of-N Sampling for example. 857 7. Summary and Conclusion 859 This document described the problems that network administrators have 860 been facing, the applicability of IPFIX Mediation to these problems, 861 and the problems related to the implementation of IPFIX Mediators. 862 To assist the operations of the Exporters and Collectors, this 863 document demonstrates that there exist various IPFIX Mediation 864 functions from which the administrators may select. 866 However, there are still some open issues with the use of IPFIX 867 Mediators. These issues stem from the fact that no standards 868 regarding IPFIX Mediation have been set. In particular, the minimum 869 set of information that should be communicated between Original 870 Exporters and Collectors, the mapping between different IPFIX 871 Transport Sessions, and the internal components of IPFIX Mediators 872 should be standardized. 874 8. Security Considerations 876 A flow-based measurement system must prevent potential security 877 threats: the disclosure of confidential traffic data, injection of 878 incorrect data, and unauthorized access to traffic data. These 879 security threats of the IPFIX protocol are covered by the security 880 considerations section in [RFC5101] and are still valid for IPFIX 881 Mediators. 883 A measurement system must also prevent the following security threats 884 related to IPFIX Mediation: 886 o Attacks against an IPFIX Mediator 888 IPFIX Mediators can be considered as a prime target for attacks, 889 as an alternative to IPFIX Exporters and Collectors. IPFIX 890 Proxies or Masquerading Proxies need to prevent unauthorized 891 access or denial-of-service (DoS) attacks from untrusted public 892 networks. 894 o Man-in-the-middle attack by untrusted IPFIX Mediator 896 The Exporter-Mediator-Collector structure model could be misused 897 for man-in-the-middle attack. 899 o Configuration on IPFIX Mediation 901 An accidental misconfiguration and unauthorized access to 902 configuration data could lead to the crucial problem of disclosure 903 of confidential traffic data. 905 o Unintentional exposure of end user information 907 The probability to collect fine-grained information on one 908 arbitrary end-user increases with the number of Observation 909 Points. An IPFIX Mediator facing such situation may have to apply 910 appropriate functions (e.g. anonymization or aggregation) to the 911 Data Records it produces. 913 o Multiple-tenancy policy on an IPFIX Mediator 915 An IPFIX Mediator handling traffic data from multiple tenants or 916 customers needs to protect from one another traffic data. For 917 example, an IPFIX Mediator needs to identify the customer's 918 identifier, e.g., ingress interface index, network address range, 919 VLAN ID, MAC address, and etc., when feeding customer's traffic 920 data to a customer own dedicated IPFIX Collector. If the IPFIX 921 Mediator can not identify each customer's traffic data, it may 922 need to drop the Data Records. In addition, another technique to 923 keep track of customer's identifier may be required when customer 924 site are movable, e.g., in the case of virtual machine moving to 925 another physical machine. 927 o Confidentiality protection via an IPFIX Mediator 929 To ensure security of Data Records in transit, transport of Data 930 Records should be confidentiality and integrity-protected, e.g. by 931 using Transport Layer Security (TLS) [RFC4346] or Datagram 932 Transport Layer Security (DTLS) [RFC4347]. However, an IPFIX 933 Collector can not know whether received Data Records are 934 transported as encrypted data between an Original Exporter and an 935 IPFIX Mediator. If this information is required on the IPFIX 936 Collector, it must be encoded in the IPFIX Mediator. 938 o Certification for an Original Exporter 940 An IPFIX Collector communicating via an IPFIX Mediator can not 941 verify the identity of an Original Exporter directly. If an 942 Original Exporter and an IPFIX Collector are located in different 943 administrative domains, an IPFIX Collector can not trust its Data 944 Records. If this information is required on the IPFIX Collector, 945 it must be encoded in the IPFIX Mediator. 947 9. IANA Considerations 949 This document has no actions for IANA. 951 10. Acknowledgements 953 We would like to thank the following persons: Gerhard Muenz for the 954 thorough detail review and significant contribution regarding the 955 improvement of whole sections; Keisuke Ishibashi for contribution 956 during the initial phases of the document; Brian Trammell for 957 contribution regarding the improvement of terminologies section; 958 Nevil Brownlee, Juergen Schoenwaelder, Motonori Shindo for the 959 technical reviews and feedback. 961 11. References 963 11.1. Normative References 965 [RFC5101] Claise, B., "Specification of the IP Flow Information 966 Export (IPFIX) Protocol for the Exchange of IP Traffic 967 Flow Information", January 2008. 969 [RFC5476] Claise, B., "Packet Sampling (PSAMP) Protocol 970 Specifications", March 2009. 972 11.2. Informative References 974 [IEEE802.3ad] 975 IEEE Computer Society, "Link Aggregation", IEEE Std 976 802.3ad-2000 , March 2000. 978 [IPFIX-MIB] 979 Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 980 "Definitions of Managed Objects for IP Flow Information 981 Export", draft-ietf-ipfix-mib-10 (work in progress) , 982 January 2010. 984 [PSAMP-MIB] 985 Dietz, T., Claise, B., and J. Quittek, "Definitions of 986 Managed Objects for Packet Sampling", 987 draft-ietf-ipfix-psamp-mib-00 (work in progress) , 988 March 2010. 990 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 991 "Requirements for IP Flow Information Export(IPFIX)", 992 October 2004. 994 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 995 9", October 2004. 997 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 998 (TLS) Protocol Version 1.1", April 2006. 1000 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1001 Security", April 2006. 1003 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 1004 Meyer, "Information Model for IP Flow Information Export", 1005 January 2008. 1007 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 1008 "Architecture for IP Flow Information Export", March 2009. 1010 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 1011 Flow Information Export (IPFIX) Applicability", 1012 March 2009. 1014 [RFC5474] Duffield, N., "A Framework for Packet Selection and 1015 Reporting", March 2009. 1017 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 1018 Raspall, "Sampling and Filtering Techniques for IP Packet 1019 Selection", March 2009. 1021 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 1022 Carle, "Information Model for Packet Sampling Exports", 1023 March 2009. 1025 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 1026 Wagner, "Specification of the IP Flow Information Export 1027 (IPFIX) File Format", October 2009. 1029 [TRAFGRW] Cho, K., Fukuda, K., Esaki, H., and A. Kato, "The Impact 1030 and Implications of the Growth in Residential User-to-User 1031 Traffic", SIGCOMM2006, pp. 207-218, Pisa, Italy, September 1032 2006. . 1034 Authors' Addresses 1036 Atsushi Kobayashi 1037 NTT Information Sharing Platform Laboratories 1038 3-9-11 Midori-cho 1039 Musashino-shi, Tokyo 180-8585 1040 Japan 1042 Phone: +81-422-59-3978 1043 Email: akoba@nttv6.net 1045 Benoit Claise 1046 Cisco Systems, Inc. 1047 De Kleetlaan 6a b1 1048 Diegem 1831 1049 Belgium 1051 Phone: +32 2 704 5622 1052 Email: bclaise@cisco.com 1054 Haruhiko Nishida 1055 NTT Information Sharing Platform Laboratories 1056 3-9-11 Midori-cho 1057 Musashino-shi, Tokyo 180-8585 1058 Japan 1060 Phone: +81-422-59-3978 1061 Email: nishida.haruhiko@lab.ntt.co.jp 1063 Christoph Sommer 1064 University of Erlangen-Nuremberg 1065 Department of Computer Science 7 1066 Martensstr. 3 1067 Erlangen 91058 1068 Germany 1070 Phone: +49 9131 85-27993 1071 Email: christoph.sommer@informatik.uni-erlangen.de 1072 URI: http://www7.informatik.uni-erlangen.de/~sommer/ 1073 Falko Dressler 1074 University of Erlangen-Nuremberg 1075 Department of Computer Science 7 1076 Martensstr. 3 1077 Erlangen 91058 1078 Germany 1080 Phone: +49 9131 85-27914 1081 Email: dressler@informatik.uni-erlangen.de 1082 URI: http://www7.informatik.uni-erlangen.de/~dressler/ 1084 Stephan Emile 1085 France Telecom 1086 2 avenue Pierre Marzin 1087 Lannion, F-22307 1089 Fax: +33 2 96 05 18 52 1090 Email: emile.stephan@orange-ftgroup.com