idnits 2.17.1 draft-ietf-ipfix-mediators-problem-statement-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 11, 2009) is 5240 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 (-10) exists of draft-ietf-ipfix-mib-09 -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: June 14, 2010 Cisco Systems, Inc. 6 December 11, 2009 8 IPFIX Mediation: Problem Statement 9 draft-ietf-ipfix-mediators-problem-statement-07 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 May 5, 2010. 46 Copyright Notice 48 Copyright (c) 2009 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 BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 77 3. IPFIX/PSAMP Documents Overview . . . . . . . . . . . . . . . . 7 78 3.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 7 79 3.2. PSAMP Documents Overview . . . . . . . . . . . . . . . . . 7 80 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 81 4.1. Coping with IP Traffic Growth . . . . . . . . . . . . . . 8 82 4.2. Coping with Multipurpose Traffic Measurement . . . . . . . 9 83 4.3. Coping with Heterogeneous Environments . . . . . . . . . . 9 84 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 5. Mediation Applicability Examples . . . . . . . . . . . . . . . 10 86 5.1. Adjusting Flow Granularity . . . . . . . . . . . . . . . . 10 87 5.2. Collecting Infrastructure . . . . . . . . . . . . . . . . 10 88 5.3. Correlation for Data Records . . . . . . . . . . . . . . . 11 89 5.4. Time Composition . . . . . . . . . . . . . . . . . . . . . 11 90 5.5. Spatial Composition . . . . . . . . . . . . . . . . . . . 12 91 5.6. Data Record Anonymization . . . . . . . . . . . . . . . . 13 92 5.7. Data Retention . . . . . . . . . . . . . . . . . . . . . . 13 93 5.8. IPFIX Export from a Branch Office . . . . . . . . . . . . 14 94 5.9. Distributing Data Records . . . . . . . . . . . . . . . . 15 95 5.10. Flow-based Sampling and Selection . . . . . . . . . . . . 16 96 5.11. Interoperability between Legacy Protocols and IPFIX . . . 17 97 6. IPFIX Mediators Implementation Specific Problems . . . . . . . 18 98 6.1. Loss of Original Exporter Information . . . . . . . . . . 18 99 6.2. Loss of Base Time Information . . . . . . . . . . . . . . 18 100 6.3. Transport Sessions Management . . . . . . . . . . . . . . 19 101 6.4. Loss of Options Template Information . . . . . . . . . . . 19 102 6.5. Template ID Management . . . . . . . . . . . . . . . . . . 19 103 6.6. Consideration for Network Topology . . . . . . . . . . . . 20 104 6.7. Exporting the Function Item . . . . . . . . . . . . . . . 20 105 6.8. Consideration for Aggregation . . . . . . . . . . . . . . 21 106 7. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 22 107 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 108 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 109 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 111 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 112 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 115 1. Introduction 117 An advantage of flow-based measurement is that it allows monitoring 118 large amount of traffic observed at distributed observation points. 119 While flow-based measurement can be applied to one of various 120 purposes and applications, it is difficult for flow-based measurement 121 to apply to multiple applications with very different requirements in 122 parallel. Network administrators need to adjust the parameters of 123 the metering devices to fulfill the requirements of every single 124 measurement application. Such configurations are often not supported 125 by the metering devices, either because of functional restrictions or 126 because of limited computational and memory resources, which inhibit 127 the metering of large amounts of traffic with the desired setup. 128 IPFIX Mediation fills the gap between restricted metering 129 capabilities and the requirements of measurement applications by 130 introducing an intermediate device called IPFIX Mediator. 132 The IPFIX requirements defined in [RFC3917] mention examples of 133 intermediate devices located between Exporters and Collectors, such 134 as IPFIX proxies or concentrators. But, there are no documents 135 defining a generalized concept for such intermediate devices. This 136 document addresses that issue by defining IPFIX Mediation, a 137 generalized intermediate device concept for IPFIX, and examining in 138 detail the motivations behind its application. 140 This document is structured as follows: section 2 describes the 141 terminology used in this document, section 3 gives an IPFIX/PSAMP 142 document overview, section 4 introduces general problems related to 143 flow-based measurement, section 5 describes some applicability 144 examples where IPFIX Mediations would be beneficial, and, finally, 145 section 6 describes some problems an IPFIX Mediation implementation 146 might face. 148 2. Terminology and Definitions 150 The IPFIX-specific and PSAMP-specific terminology used in this 151 document is defined in [RFC5101] and [RFC5476], respectively. In 152 this document, as in [RFC5101] and [RFC5476], the first letter of 153 each IPFIX-specific and PSAMP-specific term is capitalized along with 154 the IPFIX Mediation-specific term defined here. 156 In this document, we call "record stream" a stream of records 157 carrying flow- or packet-based information. The records may be 158 encoded as IPFIX Data Records in any other format. 160 Original Exporter 162 An Original Exporter is an IPFIX Device that hosts the Observation 163 Points where the metered IP packets are observed. 165 IPFIX Mediation 167 IPFIX Mediation is the manipulation and conversion of a record 168 stream for subsequent export using the IPFIX protocol. 170 The following terms are used in this document to describe the 171 architectural entities used by IPFIX Mediation. 173 Intermediate Process 175 An Intermediate Process takes a record stream as its input from 176 Collecting Processes, Metering Processes, IPFIX File Readers, 177 other Intermediate Processes, or other record sources; performs 178 some transformations on this stream, based upon the content of 179 each record, states maintained across multiple records, or other 180 data sources; and passes the transformed record stream as its 181 output to Exporting Processes, IPFIX File Writers, or other 182 Intermediate Processes, in order to perform IPFIX Mediation. 183 Typically, an Intermediate Process is hosted by an IPFIX Mediator. 184 Alternatively, an Intermediate Process may be hosted by an 185 Original Exporter. 187 IPFIX Mediator 189 An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation 190 by receiving a record stream from some data sources, hosting one 191 or more Intermediate Processes to transform that stream, and 192 exporting the transformed record stream into IPFIX Messages via an 193 Exporting Process. In the common case, an IPFIX Mediator receives 194 a record stream from a Collecting Process, but it could also 195 receive a record stream from data sources not encoded using IPFIX, 196 e.g., in the case of conversion from the NetFlow V9 protocol 197 [RFC3954] to IPFIX protocol. 199 Note that the IPFIX Mediator is a generalization of the 200 concentrator and proxy elements envisioned in the IPFIX 201 requirements [RFC3917]. IPFIX Mediators running appropriate 202 Intermediate Processes provide the functionality specified 203 therein. 205 3. IPFIX/PSAMP Documents Overview 207 3.1. IPFIX Documents Overview 209 The IPFIX protocol [RFC5101] provides network administrators with 210 access to IP flow information. The architecture for the export of 211 measured IP flow information from an IPFIX Exporting Process to a 212 Collecting Process is defined in [RFC5470], per the requirements 213 defined in [RFC3917]. The IPFIX protocol [RFC5101] specifies how 214 IPFIX Data Records and Templates are carried via a number of 215 transport protocols from IPFIX Exporting Processes to IPFIX 216 Collecting Processes. IPFIX has a formal description of IPFIX 217 Information Elements, their names, types, and additional semantic 218 information, as specified in [RFC5102]. [IPFIX-MIB] specifies the 219 IPFIX Management Information Base. Finally, [RFC5472] describes what 220 types of applications can use the IPFIX protocol and how they can use 221 the information provided. It furthermore shows how the IPFIX 222 framework relates to other architectures and frameworks. The storage 223 of IPFIX Messages in a file is specified in [RFC5655]. 225 3.2. PSAMP Documents Overview 227 The framework for packet selection and reporting [RFC5474] enables 228 network elements to select subsets of packets by statistical and 229 other methods and to export a stream of reports on the selected 230 packets to a Collector. The set of packet selection techniques 231 (sampling and filtering) standardized by PSAMP is described in 232 [RFC5475]. The PSAMP protocol [RFC5476] specifies the export of 233 packet information from a PSAMP Exporting Process to a Collector. 234 Like IPFIX, PSAMP has a formal description of its Information 235 Elements, their names, types, and additional semantic information. 236 The PSAMP information model is defined in [RFC5477]. [PSAMP-MIB] 237 describes the PSAMP Management Information Base. 239 4. Problem Statement 241 Network administrators generally face the problems of measurement 242 system scalability, flow-based measurement flexibility, and export 243 reliability, even if some techniques, such as packet Sampling, 244 Filtering, Data Records aggregation and export replication, have 245 already been developed. The problems consist of adjusting some 246 parameters of metering device to resources of the measurement system 247 while fulfilling appropriate conditions: data accuracy, flow 248 granularity, and export reliability. These conditions depend on two 249 factors. 251 o Measurement system capacity: 252 This consists of the bandwidth of the management network, the 253 storage capacity, and the performances of the collecting devices 254 and exporting devices. 256 o Application requirements: 257 Different applications, such as traffic engineering, detecting 258 traffic anomalies, and accounting, impose different Flow Record 259 granularities, and data accuracies. 261 The sustained growth of IP traffic has been overwhelming the 262 measurement system capacities. Furthermore, a large variety of 263 applications (e.g., QoS measurement, traffic engineering, security 264 monitoring) and the deployment of measurement system in heterogeneous 265 environments have been increasing the demand and complexity of IP 266 traffic measurements. 268 4.1. Coping with IP Traffic Growth 270 Enterprise or service provider networks already have multiple 10 Gb/s 271 links, their total traffic exceeding 100 Gb/s. In the near future, 272 broadband users' traffic will increase by approximately 40% every 273 year according to [TRAFGRW]. When administrators monitor IP traffic 274 sustaining its growth at multiple Exporters, the amount of exported 275 Flow Records from Exporters could exceed the ability of single 276 Collector. 278 To deal with this problem, current data reduction techniques (packet 279 Sampling and Filtering in [RFC5475], and aggregation of measurement 280 data) have been generally implemented on Exporters. Note that packet 281 Sampling leads to potential loss of small Flows. With both packet 282 Sampling and aggregation techniques, administrators might no longer 283 be able to detect and investigate subtle traffic changes and 284 anomalies as this requires detailed Flow information. With 285 Filtering, only a subset of the Data Records are exported. 287 Considering the potential drawbacks of packet Sampling, Filtering, 288 and Data Records aggregation, there is a need for a large-scale 289 collecting infrastructure that does not rely on data reduction 290 techniques. 292 4.2. Coping with Multipurpose Traffic Measurement 294 Different monitoring applications impose different requirements on 295 the monitoring infrastructure. Some of them require traffic 296 monitoring at a Flow level while others need information about 297 individual packets or just Flow aggregates. 299 To fulfill these divers requirements, an Exporter would need to 300 perform various complex metering tasks in parallel, which is a 301 problem due to limited resources. Hence, it can be advantageous to 302 run the Exporter with a much simpler setup and to perform appropriate 303 post-processing of the exported Data Records at a later stage. 305 4.3. Coping with Heterogeneous Environments 307 Network administrators use IPFIX Devices and PSAMP Devices from 308 various vendors, various software versions, various device types 309 (router, switch, or probe) in a single network domain. Even legacy 310 flow export protocols are still deployed in current network. This 311 heterogeneous environment leads to differences in Metering Process 312 capabilities, Exporting Process capacity (export rate, cache memory, 313 etc.), and data format. For example, probes and switches cannot 314 retrieve some derived packet properties from a routing table. 316 To deal with this problem, the measurement system needs to mediate 317 the differences. However, equipping all collecting devices with this 318 absorption function is difficult. 320 4.4. Summary 322 Due to resource limitations of the measurement system, it is 323 important to use traffic data reduction techniques as early as 324 possible, e.g., at the Exporter. However, this implementation is 325 made difficult by heterogeneous environment of exporting devices. On 326 the other hand, keeping data accuracy and flow granularity to meet 327 the requirements of different monitoring applications requires a 328 scalable and flexible collecting infrastructure. 330 This implies that a new Mediation function is required in typical 331 Exporter-Collector architectures. Based on some applicability 332 examples, the next section shows the limitation of the typical 333 Exporter-Collector architecture model and the IPFIX Mediation 334 benefits. 336 5. Mediation Applicability Examples 338 5.1. Adjusting Flow Granularity 340 A simplest set Flow Keys is a fixed 5-tuple of protocol, source and 341 destination IP addresses, and source and destination port numbers. A 342 shorter set of Flow Keys, such as a triple, a double, or a single 343 property, (for example network prefix, peering autonomous system 344 number, or BGP Next-Hop fields), creates more aggregated Flow 345 Records. This is especially useful for measuring router-level 346 traffic matrices in a core network domain and for easily adjusting 347 the performance of Exporters and Collectors. 349 Implementation analysis: 351 Implementations for this case depend on where Flow granularity is 352 adjusted. More suitable implementations use configurable Metering 353 Processes in Original Exporters. The cache in the Metering 354 Process can specify its own set of Flow Keys and extra fields. 355 The Original Exporter thus generates Flow Records of the desired 356 Flow granularity. 358 In the case where a Metering Process hosting no ability to change 359 the Flow Keys in Original Exporter creates Flow Records, or PSAMP 360 Packet Reports, an IPFIX Mediator can aggregate Data Records based 361 on a new set of Flow Keys. Even in the case of a Metering Process 362 hosting this ability, an IPFIX Mediator can further aggregate the 363 Flow Records. 365 5.2. Collecting Infrastructure 367 Increasing numbers of IPFIX Exporters, IP traffic growth, and the 368 variety of treatments expected to be performed on the Data Records 369 make it more and more difficult to implement all measurement 370 applications within a single Collector. 372 Implementation analysis: 374 To increase the collecting (e.g., the bandwidth capacity) and 375 processing capacity, distributed Collectors close to Exporters 376 need to be deployed. In such a case, those Collectors would 377 become IPFIX Mediators, re-exporting Data Records on demand to 378 centralized applications. To cope with the variety of measurement 379 applications, one possible implementation uses an Intermediate 380 Process deciding to which Collector(s) each record is exported. 381 More specific cases are described in section 5.9. 383 5.3. Correlation for Data Records 385 The correlation amongst Data Records or between Data Record and meta 386 data provides new metrics or information, including the following. 388 o One-to-one correlation between Data Records 390 * One way delay from the correlation of PSAMP Packet Reports from 391 different Exporters along a specific path. 393 * Packet inter-arrival time from the correlation of sequential 394 PSAMP Packet Reports from a Exporter. 396 * Treatment from the correlation of Data Records with common 397 properties, observed at incoming/outgoing interfaces. Examples 398 are the rate-limiting ratio, the compression ratio, the 399 optimization ratio, etc. 401 o Correlation amongst Data Records 403 Average/maximum/minimum values from correlating multiple Data 404 Records. Examples are the average/maximum/minimum number of 405 packets of the measured Flows, the average/maximum/minimum one way 406 delay, the average/maximum/minimum number of lost packets, etc. 408 o Correlation between Data Record and other meta data 410 Examples are some BGP attributes associated with Data Record by 411 looking up the routing table. 413 Implementation analysis: 415 One possible implementation for this case uses an Intermediate 416 Process located between the Metering Processes and Exporting 417 Processes on the Original Exporter, or alternatively a separate 418 IPFIX Mediator located between the Original Exporters and IPFIX 419 Collectors. 421 5.4. Time Composition 423 Time composition is defined as the aggregation of consecutive Data 424 Records with identical Flow Keys. It leads to the same output as 425 setting a longer active timeout on Original Exporters with one 426 advantage: the creation of new metrics such as average, maximum and 427 minimum values from Flow Records with a shorter time interval enables 428 administrators to keep track of changes that might have happened 429 during the time interval. 431 Implementation analysis: 433 One possible implementation for this case uses an Intermediate 434 Process located between the Metering Processes and Exporting 435 Processes on the Original Exporter, or alternatively a separate 436 IPFIX Mediator located between the Original Exporters and IPFIX 437 Collectors. 439 5.5. Spatial Composition 441 Spatial composition is defined as the aggregation of Data Records in 442 a set of Observation Points within an Observation Domain, across 443 multiple Observation Domains from a single Exporter, or even across 444 multiple Exporters. The spatial composition is divided into four 445 types. 447 o Cases 1: Spatial Composition within one Observation Domain 449 For example, in the case where link aggregation exists, Data 450 Records metered at physical interfaces belonging to the same trunk 451 can be merged. 453 o Cases 2: Spatial Composition across Observation Domains, but 454 within a single Original Exporter 456 For example, in the case where link aggregation exists, Data 457 Records metered at physical interfaces belonging to a same trunk 458 grouping beyond the line card can be merged. 460 o Cases 3: Spatial Composition across Exporters 462 Data Records metered within an administrative domain, such as the 463 west area and east area of an ISP network, can be merged. 465 o Cases 4: Spatial Composition across administrative domains 467 Data Records metered across administrative domains, such as across 468 different customer networks or different ISP networks, can be 469 merged. 471 Implementation analysis: 473 One possible implementation for the cases 1 and 2 uses an 474 Intermediate Process located between the Metering Processes and 475 Exporting Processes on the Original Exporter. A separate IPFIX 476 Mediator located between the Original Exporters and IPFIX 477 Collector is a valid solution for the cases 1, 2, 3, and 4. 479 5.6. Data Record Anonymization 481 IPFIX exports across administrative domains can be used to measure 482 traffic for wide-area traffic engineering or to analyze Internet 483 traffic trends, as described in the spatial composition across 484 administrative domains in the previous subsection. 485 In such a case, administrators need to adhere to privacy protection 486 policies and prevent access to confidential traffic measurements by 487 other people. Typically, anonymization techniques enable the 488 provision of traffic data to other people without violating these 489 policies. 491 Generally, anonymization modifies a data set to protect the identity 492 of the people or entities described by the data set from being 493 disclosed. It also attempts to preserve sets of network traffic 494 properties useful for a given analysis while ensuring the data cannot 495 be traced back to the specific networks, hosts, or users generating 496 the traffic. For example, IP address anonymization is particularly 497 important for avoiding the identification of users, hosts, and 498 routers. As another example, when an ISP provides traffic monitoring 499 service to end customers, network administrators take care of 500 anonymizing interface index fields which could disclose any 501 information about the vendor or software version of the Exporters. 503 Implementation analysis: 505 One possible implementation for this case uses an anonymization 506 function at the Original Exporter. However, this increases the 507 load on the Original Exporter. A more flexible implementation 508 uses a separate IPFIX Mediator between the Original Exporter and 509 Collector. 511 5.7. Data Retention 513 Data retention refers to the storage of traffic data by service 514 providers and commercial organizations. Legislative regulations 515 often require that network operators retain both IP traffic data and 516 call detail records, in wired and wireless networks, generated by end 517 users while using a service provider's services. The traffic data is 518 required for the purpose of the investigation, detection and 519 prosecution of serious crime, if necessary. Data retention services 520 examples are the following: 522 o Fixed telephony (includes fixed voice calls, voicemail, and 523 conference and data calls) 525 o Mobile telephony (includes mobile voice calls, voicemail, 526 conference and data calls, SMS, and MMS) 528 o Internet telephony (includes every multimedia session associated 529 with IP multimedia services) 531 o Internet e-mail 533 o Internet access 535 Data retention for Internet access services in particular requires a 536 measurement system with reliable export and huge storage as the data 537 must be available for a long period of time, typically at least six 538 months. 540 Implementation analysis: 542 Regarding export reliability requirement, the most suitable 543 implementation uses the SCTP transport protocol between the 544 Original Exporter and Collector. If an unreliable transport 545 protocol such as UDP is used, a legacy exporting device exports 546 Data Records to a nearby IPFIX Mediator through UDP, and then an 547 IPFIX Mediator could reliably export them to the IPFIX Collector 548 through SCTP. If an unreliable transport protocol such as UDP is 549 used and if there is no IPFIX Mediator, the legacy exporting 550 device should duplicate the exports to several Collectors to lower 551 the probability of loosing Flow Records. However, it might result 552 in network congestion, unless dedicated export links are used. 554 Regarding huge storage requirement, the collecting infrastructure 555 are described in section 5.2. 557 5.8. IPFIX Export from a Branch Office 559 Generally, in large enterprise networks, Data Records from branch 560 offices are gathered in a central office. However, in the long 561 distance branch office case, the bandwidth for transport IPFIX is 562 limited. Therefore, even if multiple Data Record types should be of 563 interest to the Collector (e.g., IPFIX Flow Records in both 564 directions, IPFIX Flow Records before and after WAN optimization 565 techniques, performance metrics associated with the IPFIX Flow 566 Records exported on regular interval, etc.), the export bandwidth 567 limitation is an important factor to pay attention to. 569 Implementation analysis: 571 One possible implementation for this case uses an IPFIX Mediator 572 located in a branch office. The IPFIX Mediator would aggregate 573 and correlate Data Records to cope with the export bandwidth 574 limitation. 576 5.9. Distributing Data Records 578 Recently, several networks have shifted towards integrated networks, 579 such as the pure IP and MPLS networks, which includes IPv4, IPv6, and 580 VPN traffic. Data Record types (IPv4, IPv6, MPLS, and VPN) need to 581 be analyzed separately and from different perspectives for different 582 organizations. A single Collector handling all Data Record types 583 might become a bottleneck in the collecting infrastructure. Data 584 Records distributed based on their respective types can be exported 585 to the appropriate Collector, resulting in the load distribution 586 amongst multiple Collectors. 588 Implementation analysis: 590 One possible implementation for this case uses the replications of 591 the IPFIX Message in an Original Exporter for multiple IPFIX 592 Collectors. Each Collector then extracts the Data Record required 593 by its own applications. However, the replication increases the 594 load of the Exporting Process and the waste of the bandwidth 595 between the Exporter and Collector. 597 A more sophisticated implementation uses an Intermediate Process 598 located between the Metering Processes and Exporting Processes in 599 an Original Exporter. The Intermediate Process determines to 600 which Collector a Data Record is exported depending on certain 601 field values. If a Original Exporter does not have this 602 capability, it exports Data Records to a nearby separate IPFIX 603 Mediator, and then the IPFIX Mediator could distribute them to the 604 appropriate IPFIX Collectors. 606 For example, in the case of distributing a specific customer's 607 Data Records, an IPFIX Mediator needs to identify the customer 608 networks. The Route Distinguisher (RD), ingress interface, 609 peering AS number, or BGP Next-Hop, or simply the network prefix 610 may be evaluated to distinguish different customer networks. In 611 the following figure, the IPFIX Mediator reroutes Data Records on 612 the basis of the RD value. This system enables each customer's 613 traffic to be inspected independently. 615 .---------. 616 |Traffic | 617 .---->|Collector|<==>Customer#A 618 | |#1 | 619 | '---------' 620 RD=100:1 621 .----------. .-----------. | 622 |IPFIX | |IPFIX |----' .---------. 623 |Exporter#1| |Mediator | RD=100:2 |Traffic | 624 | |------->| |--------->|Collector|<==>Customer#B 625 | | | | |#2 | 626 | | | |----. '---------' 627 '----------' '-----------' | 628 RD=100:3 629 | .---------. 630 | |Traffic | 631 '---->|Collector|<==>Customer#C 632 |#3 | 633 '---------' 635 Figure A: Distributing Data Records to Collectors using IPFIX 636 Mediator 638 5.10. Flow-based Sampling and Selection 640 Generally, the distribution of the number of packets per Flow seems 641 to be heavy-tailed. Most types of Flow Records are likely to be 642 small Flows consisting of a small number of packets. The measurement 643 system is overwhelmed with a huge amount of these small Flows. If 644 statistics information of small Flows is exported as merged data by 645 applying a policy or threshold, the load on the Exporter is reduced. 646 Furthermore, if the flow distribution is known, exporting only a 647 subset of the Data Records might be sufficient. 649 Implementation analysis: 651 One possible implementation for this case uses an Intermediate 652 Process located between the Metering Processes and Exporting 653 Processes on the Original Exporter, or alternatively a separate 654 IPFIX Mediator located between the Original Exporters and IPFIX 655 Collectors. A set of IPFIX Mediation functions, such as 656 filtering, selecting and aggregation is used in the IPFIX 657 Mediator. 659 5.11. Interoperability between Legacy Protocols and IPFIX 661 During the migration process from a legacy protocol such as NetFlow 662 [RFC3954] to IPFIX, both NetFlow exporting devices and IPFIX 663 Exporters are likely to coexist in the same network. Operators need 664 to continue measuring the traffic data from legacy exporting devices, 665 even after introducing IPFIX Collectors. 667 Implementation analysis: 669 One possible implementation for this case uses an IPFIX Mediator 670 that converts a legacy protocol to IPFIX. 672 6. IPFIX Mediators Implementation Specific Problems 674 6.1. Loss of Original Exporter Information 676 Both the Exporter IP address indicated by the source IP address of 677 the IPFIX Transport Session and the Observation Domain ID included in 678 the IPFIX Message header are likely to be lost during IPFIX 679 Mediation. In some cases, an IPFIX Mediator might drop the 680 information deliberately. In general, however, the Collector must 681 recognize the origin of the measurement information, such as the IP 682 address of the Original Exporter, the Observation Domain ID, or even 683 the Observation Point ID. Note that, if an IPFIX Mediator cannot 684 communicate the Original Exporter IP address, then the IPFIX 685 Collector will wrongly deduce that the IP address of the IPFIX 686 Mediator is that of the Original Exporter. 688 In the following figure, a Collector can identify two IP addresses: 689 10.1.1.3 (IPFIX Mediator) and 10.1.1.2 (Exporter#2), respectively. 690 The Collector, however, needs to somehow recognize both Exporter#1 691 and Exporter#2, which are the Original Exporters. The IPFIX Mediator 692 must be able to notify the Collector about the IP address of the 693 Original Exporter. 695 .----------. .--------. 696 |IPFIX | |IPFIX | 697 |Exporter#1|--------->|Mediator|---+ 698 | | | | | 699 '----------' '--------' | .---------. 700 IP:10.1.1.1 IP:10.1.1.3 '----->|IPFIX | 701 ODID:10 ODID:0 |Collector| 702 +----->| | 703 .----------. | '---------' 704 |IPFIX | | 705 |Exporter#2|-----------------------' 706 | | 707 '----------' 708 IP:10.1.1.2 709 ODID:20 711 Figure B: Loss of Original Exporter Information. 713 6.2. Loss of Base Time Information 715 The Export Time field included in the IPFIX Message header represents 716 a reference timestamp for Data Records. Some IPFIX Information 717 Elements, described in [RFC5102], carry delta timestamps that 718 indicate the time difference from the value of the Export Time field. 719 If the Data Records include any delta time fields and the IPFIX 720 Mediator overwrites the Export Time field when sending IPFIX 721 Messages, the delta time fields become meaningless and, because 722 Collectors cannot recognize this situation, wrong time values are 723 propagated. 725 6.3. Transport Sessions Management 727 Maintaining relationships between the incoming Transport Sessions and 728 the outgoing ones depends on the Mediator's implementation. If an 729 IPFIX Mediator relays multiple incoming Transport Sessions to a 730 single outgoing Transport Session, and if the IPFIX Mediators shuts 731 down its outgoing Transport Session, Data Records of the incoming 732 Transport Sessions would not be relayed any more. In the case of 733 resetting an incoming Transport Session, the behavior of the IPFIX 734 Mediator needs to be specified. 736 6.4. Loss of Options Template Information 738 In some cases, depending on the implementation of the IPFIX 739 Mediators, the information reported in the Data Records defined by 740 Options Templates could also be lost. If, for example, the Sampling 741 rate is not communicated from the Mediator to the Collector, the 742 Collector would miscalculate the traffic volume. This might lead to 743 crucial problems. Even if an IPFIX Mediator was to simply relay 744 received Data Records defined by Options Templates, the values of its 745 scope fields could become meaningless in the content of a different 746 Transport Sessions. The minimal information to be communicated by an 747 IPFIX Mediator must be specified. 749 6.5. Template ID Management 751 The Template ID is unique on the basis of the Transport Session and 752 Observation Domain ID. If an IPFIX Mediation is not able to manage 753 the relations amongst the Template IDs and the incoming Transport 754 Session information, and if the Template ID is used in the Options 755 Template scope, IPFIX Mediators would, for example, relay wrong 756 values in the scope field and in the Template Withdrawal Message. 757 The Collector would thus not be able to interpret the Template ID in 758 the Template Withdrawal Message and in the Options Template scope. 759 As a consequence, there is a risk that the Collector would then shut 760 down the IPFIX Transport Session. 762 For example, an IPFIX Mediator must maintain the state of the 763 incoming Transport Sessions in order to manage the Template ID on its 764 outgoing Transport Session correctly. Even if the Exporter Transport 765 Session re-initializes, the IPFIX Mediator must manage the 766 association of Template IDs in specific Transport Session. In the 767 following figure, the IPFIX Mediator exports three Templates (256, 768 257, and 258), received respectively from Exporter#3, Exporter#2, and 769 Exporter#1. If the Exporter#1 re-initializes, and the Template ID 770 value 258 is now replaced with 256, the IPFIX Mediator must correctly 771 manage the new mapping of (incoming Transport Session, Template ID) 772 and (outgoing Transport Session, Template ID) without shutting down 773 its outgoing Transport Session. 775 .----------. OLD: Template ID 258 776 |IPFIX | NEW: Template ID 256 777 |Exporter#1|----+ 778 | | | 779 '----------' X 780 .----------. | .-----------. .----------. 781 |IPFIX | '---------->| | | | 782 |Exporter#2|--------------->|IPFIX |-------------->|IPFIX | 783 | |Template ID 257 |Mediator |Template ID 258| Collector| 784 '----------' +---------->| |Template ID 257| | 785 .----------. | '-----------'Template ID 256'----------' 786 |IPFIX | | 787 |Exporter#3|----' 788 | | Template ID 256 789 '----------' 791 Figure C: Relaying from Multiple Transport Sessions to Single 792 Transport Session. 794 6.6. Consideration for Network Topology 796 While IPFIX Mediation can be applied anywhere, caution should be 797 taken as how to aggregate the counters, as there is a potential risk 798 of double-counting. For example, if three Exporters export PSAMP 799 Packet Reports related to the same Flow, the one-way delay can be 800 calculated, while summing up the number of packets and bytes does not 801 make sense. Alternatively, if three Exporters export Flow Records 802 entering an administrative domain, then the sum of the packets and 803 bytes is a valid operation. Therefore, the possible function to be 804 applied to Flow Records must take into consideration the measurement 805 topology. The information such as the network topology, or at least 806 the Observation Point and measurement direction, is required for 807 IPFIX Mediation. 809 6.7. Exporting the Function Item 811 In some case, the IPFIX Collector needs to recognize which specific 812 function(s) IPFIX Mediation has executed on the Data Records. The 813 IPFIX Collector cannot distinguish between time composition and 814 spatial composition, if the IPFIX Mediator does not export the 815 applied function. Some parameters related to the function also would 816 need to be exported. For example, in case of time composition, the 817 active timeout of original Flow Records is required to interpret the 818 minimum/maximum counter correctly. In case of spatial composition, 819 spatial area information on which Data Records is aggregated is 820 required. 822 6.8. Consideration for Aggregation 824 Whether the aggregation is based on time or spatial composition, 825 caution should be taken on how to aggregate non-key fields in IPFIX 826 Mediation. The IPFIX information model [RFC5102] specifies that the 827 value of non-key fields, which are derived from fields of packets or 828 from packet treatment and for which the value may change from packet 829 to packet within a single Flow, is determined by the first packet 830 observed for the corresponding Flow, unless the description of the 831 Information Element explicitly specifies a different semantics. 833 However, this simple rule might not be appropriate when aggregating 834 Flow Records which have different values in a non-key field. For 835 example, if Differentiated Services Code Point (DSCP) information is 836 to be exported, the following problem can be observed: If two Flows 837 with identical Flow Key values are measured at different Observation 838 Points, they may contain identical packets observed at different 839 locations in the network and at different points in time. On their 840 way from the first to the second Observation Point, the DSCP and 841 potentially some other packet fields may have changed. Hence, if the 842 Information Element ipDiffServCodePoint is included as a non-key 843 field, it can be useful to include the DSCP value observed at either 844 the first or the second Observation Point in the resulting Flow 845 Record, depending on the application. 847 Other potential solutions include: removing the Information Element 848 ipDiffServCodePoint from the Data Record when re-exporting the 849 aggregate Flow Record, changing the Information Element 850 ipDiffServCodePoint from a non key-field to a Flow Key when re- 851 exporting the aggregated Flow Record, or assigning a non valid value 852 for the Information Element to express to the Collector that this 853 Information Element is meaningless. 855 If packet Sampling or Filtering is applied, the IPFIX Mediator must 856 report an adjusted PSAMP Configured Selection Fraction when 857 aggregating IPFIX Flow Records with different sampling rates. 858 Finally, special care must be taken when aggregating Flow Records 859 resulting from different Sampling techniques such as Systematic 860 Count-Based Sampling and Random n-out-of-N Sampling for example. 862 7. Summary and Conclusion 864 This document described the problems that network administrators have 865 been facing, the applicability of IPFIX Mediation to these problems, 866 and the problems related to the implementation of IPFIX Mediators. 867 To assist the operations of the Exporters and Collectors, this 868 document demonstrates that there exist various IPFIX Mediation 869 functions from which the administrators may select. 871 However, there are still some open issues with the use of IPFIX 872 Mediators. These issues stem from the fact that no standards 873 regarding IPFIX Mediation have been set. In particular, the minimum 874 set of information that should be communicated between Original 875 Exporters and Collectors, the management between different IPFIX 876 Transport Sessions, and the internal components of IPFIX Mediators 877 should be standardized. 879 8. Security Considerations 881 A flow-based measurement system must prevent potential security 882 threats: the disclosure of confidential traffic data, injection of 883 incorrect data, and unauthorized access to traffic data. These 884 security threats of the IPFIX protocol are covered by the security 885 considerations section in [RFC5101] and are still valid for IPFIX 886 Mediators. 888 A measurement system must also prevent the following security threats 889 related to IPFIX Mediation: 891 o Attacks against IPFIX Mediator 893 IPFIX Mediators can be considered as a prime target for attacks, 894 as an alternative to IPFIX Exporters and Collectors. IPFIX 895 Proxies or Masquerading Proxies need to prevent unauthorized 896 access or denial-of-service (DoS) attacks from untrusted public 897 networks. 899 o Man-in-the-middle attack by untrusted IPFIX Mediator 901 The Exporter-Mediator-Collector structure model could be misused 902 for man-in-the-middle attack. 904 o Configuration on IPFIX Mediation 906 An accidental misconfiguration and unauthorized access to 907 configuration data could lead to the crucial problem of disclosure 908 of confidential traffic data. 910 9. IANA Considerations 912 This document has no actions for IANA. 914 10. Acknowledgements 916 We would like to thank the following persons: Gerhard Muenz for the 917 thorough detail review and significant contribution regarding the 918 improvement of whole sections; Keisuke Ishibashi for contribution 919 during the initial phases of the document; Brian Trammell for 920 contribution regarding the improvement of terminologies section; 921 Nevil Brownlee, Juergen Schoenwaelder, Motonori Shindo for the 922 technical reviews and feedback. 924 11. References 926 11.1. Normative References 928 [RFC5101] Claise, B., "Specification of the IP Flow Information 929 Export (IPFIX) Protocol for the Exchange of IP Traffic 930 Flow Information", January 2008. 932 [RFC5476] Claise, B., "Packet Sampling (PSAMP) Protocol 933 Specifications", March 2009. 935 11.2. Informative References 937 [IPFIX-MIB] 938 Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 939 "Definitions of Managed Objects for IP Flow Information 940 Export", draft-ietf-ipfix-mib-09 (work in progress) , 941 December 2009. 943 [PSAMP-MIB] 944 Dietz, T. and B. Claise, "Definitions of Managed Objects 945 for Packet Sampling", draft-ietf-psamp-mib-06 (work in 946 progress) , June 2006. 948 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 949 "Requirements for IP Flow Information Export(IPFIX)", 950 October 2004. 952 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 953 9", October 2004. 955 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 956 Meyer, "Information Model for IP Flow Information Export", 957 January 2008. 959 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 960 "Architecture for IP Flow Information Export", March 2009. 962 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 963 Flow Information Export (IPFIX) Applicability", 964 March 2009. 966 [RFC5474] Duffield, N., "A Framework for Packet Selection and 967 Reporting", March 2009. 969 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 970 Raspall, "Sampling and Filtering Techniques for IP Packet 971 Selection", March 2009. 973 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 974 Carle, "Information Model for Packet Sampling Exports", 975 March 2009. 977 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 978 Wagner, "Specification of the IP Flow Information Export 979 (IPFIX) File Format", October 2009. 981 [TRAFGRW] Cho, K., Fukuda, K., Esaki, H., and A. Kato, "The Impact 982 and Implications of the Growth in Residential User-to-User 983 Traffic", SIGCOMM2006, pp. 207-218, Pisa, Italy, September 984 2006. . 986 Authors' Addresses 988 Atsushi Kobayashi 989 NTT Information Sharing Platform Laboratories 990 3-9-11 Midori-cho 991 Musashino-shi, Tokyo 180-8585 992 Japan 994 Phone: +81-422-59-3978 995 Email: akoba@nttv6.net 997 Benoit Claise 998 Cisco Systems, Inc. 999 De Kleetlaan 6a b1 1000 Diegem 1831 1001 Belgium 1003 Phone: +32 2 704 5622 1004 Email: bclaise@cisco.com 1006 Haruhiko Nishida 1007 NTT Information Sharing Platform Laboratories 1008 3-9-11 Midori-cho 1009 Musashino-shi, Tokyo 180-8585 1010 Japan 1012 Phone: +81-422-59-3978 1013 Email: nishida.haruhiko@lab.ntt.co.jp 1015 Christoph Sommer 1016 University of Erlangen-Nuremberg 1017 Department of Computer Science 7 1018 Martensstr. 3 1019 Erlangen 91058 1020 Germany 1022 Phone: +49 9131 85-27993 1023 Email: christoph.sommer@informatik.uni-erlangen.de 1024 URI: http://www7.informatik.uni-erlangen.de/~sommer/ 1025 Falko Dressler 1026 University of Erlangen-Nuremberg 1027 Department of Computer Science 7 1028 Martensstr. 3 1029 Erlangen 91058 1030 Germany 1032 Phone: +49 9131 85-27914 1033 Email: dressler@informatik.uni-erlangen.de 1034 URI: http://www7.informatik.uni-erlangen.de/~dressler/ 1036 Stephan Emile 1037 France Telecom 1038 2 avenue Pierre Marzin 1039 Lannion, F-22307 1041 Fax: +33 2 96 05 18 52 1042 Email: emile.stephan@orange-ftgroup.com