[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 5982

IPFIX Working Group                                    A. Kobayashi, Ed.
Internet-Draft                                               NTT PF Lab.
Intended status: Informational                              May 13, 2008
Expires: November 14, 2008


                   IPFIX Mediation: Problem Statement
            draft-ietf-ipfix-mediators-problem-statement-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 1, 2008.


















Kobayashi, et al.       Expires November 1, 2008                [Page 1]


Internet-Draft         Mediation Problem Statement            April 2008


Abstract

   Flow-based measurement is currently a popular method for traffic
   monitoring.  To construct a measurement system, an IPFIX mediation
   device (IPFIX Mediator), which reroutes, filters, aggregates, or
   modifies Flow information, may help scalability and several other
   purposes.  This document describes the applicability of an IPFIX
   Mediator and the problems that the IPFIX Mediator might encounter.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Flow-Based Mediation Devices: Examples of Applicability  . . .  6
     3.1.  Inter-domain IPFIX Exporting . . . . . . . . . . . . . . .  6
     3.2.  Data Retention . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Interoperability between Legacy Protocols and IPFIX  . . .  6
     3.4.  Flow Distribution to Specific Collectors . . . . . . . . .  7
     3.5.  Aggregation and Harmonization of Metering Process Rules  .  7
   4.  Approaches to Scalability  . . . . . . . . . . . . . . . . . .  8
     4.1.  Adjusting Sampling Rates . . . . . . . . . . . . . . . . .  8
     4.2.  Exporting Aggregated Flows from Original Exporters . . . .  9
     4.3.  Hierarchical Model of Flow Aggregation . . . . . . . . . .  9
     4.4.  Flow-Based Collector Selection . . . . . . . . . . . . . .  9
     4.5.  Flow Selection Sampling  . . . . . . . . . . . . . . . . . 10
     4.6.  Information Elements and Flow Keys Selection . . . . . . . 11
   5.  Problems with using IPFIX Mediators  . . . . . . . . . . . . . 12
     5.1.  Loss of Observation Point Information  . . . . . . . . . . 12
     5.2.  Loss of Base Time Information  . . . . . . . . . . . . . . 13
     5.3.  Loss of Option Template Information  . . . . . . . . . . . 13
     5.4.  Observation Domain ID and Template ID Management . . . . . 14
     5.5.  Transport Sessions Management  . . . . . . . . . . . . . . 14
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22










Kobayashi, et al.       Expires November 1, 2008                [Page 2]


Internet-Draft         Mediation Problem Statement            April 2008


1.  Introduction

   While the requirements for IPFIX defined in [RFC3917] mention an
   intermediate device between Exporters and Collectors, such as an
   IPFIX Proxy or an Concentrator, there is no document to define this
   intermediate device, termed IPFIX Mediator.  This document presents
   several application examples, problems and weak points regarding the
   specification of IPFIX Mediators.

   In section 2, the terminologies and concepts used in this document
   are presented.  In section 3, several application examples of IPFIX
   Mediators are listed.  Especially, the more effective usage in large-
   scale networks is presented in section 4.  It describes the
   approaches to scalability of a flow-based measurement system and some
   solutions regarding IPFIX Mediators.  Finally, section 5 describes
   the issues regarding the implementation of an IPFIX Mediator.



































Kobayashi, et al.       Expires November 1, 2008                [Page 3]


Internet-Draft         Mediation Problem Statement            April 2008


2.  Terminology

   The terminology used in this document is fully aligned with that
   defined in [RFC5101].  Other terms related to IPFIX Mediation are
   defined here.  All these terms are capitalized in this document.

   IPFIX Mediator

      An IPFIX Mediator is a device that routes Flow Records or changes
      the Flow Records information.  It hosts at least one Collecting
      Process and one Exporting Process.  An IPFIX Mediator is formally
      defined to consist of one or more Collecting Processes, zero or
      more intermediate processes and one or more Exporting Processes.
      Figure A shows the relationship among these processes.


         .-------------------------------------------------.
         |  .----------.                       .----------.|
         | .----------.|    .------------.    .----------.||
         |.----------.||   .------------.|   .----------.|||
   IPFIX ||Collecting|||   |Intermediate||   |Exporting ||||IPFIX
   ----->||Processes ||'-->|Proceses    ||-->|Processes ||'|----->
         ||          |'    |(optional)  |'   |          |' |
         |'----------'     '------------'    '----------'  |
         '-------------------------------------------------'

               Figure A: Basic IPFIX Mediator Model.

      Basically, IPFIX Mediators have two types of mediation functions,
      as follows.

      *  IPFIX Protocol Mediation

         This type of IPFIX Mediator forwards input Flow Records to
         Collectors.  IPFIX Protocol Mediation does not change
         information, but simply relays the Flow Records from receiving
         IPFIX Transport Sessions to exporting IPFIX Transport Sessions.
         Examples are an IPFIX Proxy and an IPFIX protocol converter,
         both described in [RFC3917], as well as an IPFIX Distributor.

      *  IPFIX Flow Mediation

         This type of IPFIX Mediator creates new sets of Flow Records
         from input Flow Records.  The Flow Mediation consists of a set
         of functions that include Flow aggregation, selection, or
         modification.  The modification of Flow Records includes
         changing the value of specified Information Elements, or
         changing the Template and record structure.  Examples are an



Kobayashi, et al.       Expires November 1, 2008                [Page 4]


Internet-Draft         Mediation Problem Statement            April 2008


         IPFIX Concentrator, which are described in [RFC3917], and an
         IPFIX Masquerading Proxy.

      Being a stand-alone device is not necessary, as these functions
      can be included in the Exporter, such as router or switch.

   Original Exporter

      An Original Exporter is an Exporter which hosts Observation Points
      where IP packets can be directly observed, as opposed to an IPFIX
      Mediator, which hosts an Exporting Process, but doesn't have any
      Observation Point.

   IPFIX Proxy

      An IPFIX Proxy acts as a proxy for an Original Exporter, which
      hosts Observation Points.  It may receive Flow Records and send
      them to one or multiple Collectors.

   IPFIX Concentrator

      An IPFIX Concentrator receives Flow Records, aggregates them, then
      exports the aggregated Flow Records.

   IPFIX Distributor

      An IPFIX Distributor classifies the input Flow Records based on
      their contents.  Depending on their classification, such as IPv4
      and IPv6, it exports them to one or more of several different
      Collectors, replicating input Flow Records, if necessary.

   IPFIX Masquerading Proxy

      An IPFIX Masquerading Proxy screens out a part of data of input
      Flow Records according to configured policies.  It can thus, for
      example, hide the network topology information or customers' IP
      addresses.














Kobayashi, et al.       Expires November 1, 2008                [Page 5]


Internet-Draft         Mediation Problem Statement            April 2008


3.  Flow-Based Mediation Devices: Examples of Applicability

3.1.  Inter-domain IPFIX Exporting

   Inter-domain IPFIX Exporting can be used to measure traffic for wide-
   area traffic engineering, or to analyze the behavior of Internet
   traffic.  In cases like this, network operators need to adhere to
   privacy policies and prevent from spreading confidential information.
   Using an IPFIX Masquerading Proxy allows them to operate on Flow
   Records safely by anonymizing and filtering them.

3.2.  Data Retention

   Data retention refers to the storage of data records by service
   providers and commercial organizations.  According the European
   Commission directives, service providers are required to retain both
   IP and voice traffic data, in wireline and wireless networks,
   generated by end users while using SPs services.  The goal of data
   retention is to ensure that call detail records and flow records are
   available if necessary for the purpose of detection, investigation,
   and prosecution of serious crimes.  The European Commission
   directives define the following data retention services:

   o  Fixed telephony (includes fixed voice, voicemail, and conference
      and data calls)

   o  Mobile telephony (includes mobile voice, voicemail, conference and
      data calls, SMS, and MMS)

   o  Internet telephony (includes every multimedia session associated
      with IP multimedia services)

   o  Internet e-mail

   o  Internet access

   By monitoring Flow Records, IPFIX can fulfill these requirement of
   Internet access services.

3.3.  Interoperability between Legacy Protocols and IPFIX

   During the migration process from legacy protocols such as NetFlow
   [RFC3954] to IPFIX, both NetFlow and IPFIX Exporters will need to co-
   exist in the same network.  An IPFIX Mediator which converts a legacy
   protocol to IPFIX will allow operators to continue measuring Flows
   from legacy Exporters, even after introducing IPFIX Collectors.





Kobayashi, et al.       Expires November 1, 2008                [Page 6]


Internet-Draft         Mediation Problem Statement            April 2008


3.4.  Flow Distribution to Specific Collectors

   Recently, several networks seem to have shifted towards Integrated
   Networks, such as the Internet and MPLS, which includes IPv4, IPv6,
   and VPN traffic.  Flow Records of these types need to be analyzed
   separately and from different perspectives.  However, handling them
   separately without improving the capability of the Collector is
   difficult.  If the Original Exporter can not classify specific Flow
   Records based on their contents and distribute them, the Collector
   has to be able to handle all kinds of unclassified Flow Records.
   Aside from the Original Exporter, IPFIX Distributors assisting Flow
   distribution would be necessary.  Each individual Collector can
   analyze the distributed Flow Records based on the nature of each
   network.

3.5.  Aggregation and Harmonization of Metering Process Rules

   Because of a Collector's performance limit, adjusting metering
   process rules, such as sampling rate, the active/inactive timeout,
   and the Flow Key [RFC5101], is necessary.  Also, IPFIX Concentrators
   could adjust the load of the measurement system by aggregating input
   Flow Records within a given time interval.  By changing the Flow Key
   and time outs, the granularity of the Flows increases, and the number
   of Flow Records decreases.  This function is especially important in
   large scale networks, which require scalable measurement systems.


























Kobayashi, et al.       Expires November 1, 2008                [Page 7]


Internet-Draft         Mediation Problem Statement            April 2008


4.  Approaches to Scalability

   Usually, network operators measure traffic at several Observation
   Points for a specific purpose, typically sampling packets with rates
   ranging from 1/10,000 to 1/100.  This value depends on several
   factors, such as the capacity of the management network, the
   available storage and speed of the Collector, and the load on the
   routers/switches.

   Currently, network providers extensively use flow-based measurements.
   The number of Observation Points in the networks can even be
   increased to improve the effectiveness of these methods.  In the near
   future, we anticipate that the advanced features of IPFIX, such as
   the monitoring of wide-area traffic matrices and QoS performance,
   will accelerate IPFIX utilization.

   On the other hand, the increasing amount of traffic brought about by
   broadband users might have an impact on measurement parameters, such
   as the sampling rate or granularity of Flows.  Generally, large-scale
   networks already have multiple 10 Gb/s links, their total traffic
   exceeding 100 Gb/s.  In the near future, broadband users' traffic
   will increase by approximately 50% per year according to [TRAFGRW].
   When operators monitor traffic of 500 Gb/s with a sampling rate of
   1/1000, the amount of exported Flow Records from Exporters could
   exceed 50 kFlows/s.  This value is beyond the ability of a single
   Collector.

   It should be noted that the current sampling rate might become
   infeasible for Exporters within the next five years.  To avert this,
   network operators can consider several solutions.  This section
   explains how operators can cope with such a huge amount of Flow
   Records using available IPFIX solutions.

4.1.  Adjusting Sampling Rates

   Adjusting the sampling rate reduces the amount of Flow Records, and a
   flow-based measurement system can thus easily adapt to the ability of
   the Collecting and Exporting Processes.  However, in that case, Flows
   with small traffic volumes could easily get lost.  If traffic
   incidents happened, network operators would no longer be able to
   investigate traffic behavior.  While traffic volumes on networks
   continue to increase, network operators will not be able to maintain
   the sampling rates currently used.  In the near future, flow-based
   measurement systems possibly will not be able to detect traffic
   anomalies which can currently be detected.






Kobayashi, et al.       Expires November 1, 2008                [Page 8]


Internet-Draft         Mediation Problem Statement            April 2008


4.2.  Exporting Aggregated Flows from Original Exporters

   The simplest types of Flows are those comprised of all packets having
   a fixed five tuple of protocol, source and destination IP addresses,
   and source and destination port numbers.  On the other hand, choosing
   a shorter Flow Key, such as a three tuple or two tuple, or a single
   Flow Key, such as a network prefix, peering AS number, or BGP Next-
   Hop, creates more aggregated Flow Records.  This solution is
   especially useful for measurements of traffic exchange in an entire
   network domain and for easy adjustments to the performance of a
   Collector.  However, in-depth monitoring of traffic behavior is no
   longer possible, as it is with the five tuple.

   Another approach involves the router, which has several different
   caches.  Each cache is optimized for a specific application, so it
   has its own series of Flow Keys and its contents are sent to a
   specific Collector.  There is a Collector for security, another for
   capacity planning, and so on.  The content and granularity of the
   Flow satisfies the requirements of each Collector.

4.3.  Hierarchical Model of Flow Aggregation

   In large-scale networks, creating a hierarchical aggregation system
   by using IPFIX Concentrators can prove to be very useful.  Collecting
   the aggregated Flow Records exported by IPFIX Concentrators from
   whole networks enables measuring of the traffic behavior of entire
   networks.  In addition, if IPFIX Concentrators store the received
   Flow Records, and then the stored Flow Records are allowed to be
   retrieved by other devices, this architecture might actually become a
   most useful distributed-collection system.  As described in
   [I-D.dressler-ipfix-aggregation], in the case of a measurement system
   consisting of both aggregating and non-aggregating Exporters, an
   IPFIX Concentrator can assist the latter by aggregating received Flow
   Records to any granularity.

4.4.  Flow-Based Collector Selection

   In general, a distributive system allows the work of the Collectors
   to be divided.  Classifying Flow Records based on the value of
   specified Information Elements can prove to be very useful for
   achieving scalability.  In the simplest case, Original Exporters
   export all Flow Records without requiring any additional functions.
   An IPFIX Distributor classifies Flow Records based on the value of
   specified Information Elements and exports the classified Flow
   Records to individual Collectors.  This is called Flow-Based
   Collector Selection.

   In particular, in an integrated network situation, the nature of each



Kobayashi, et al.       Expires November 1, 2008                [Page 9]


Internet-Draft         Mediation Problem Statement            April 2008


   network is different, although several kinds of networks, such as
   VPNs and the Internet, share a physical network.  This function
   allows individual Collectors related to each network to analyze
   traffic behavior for their own specific purposes.

   An IPFIX Distributor could, for example, distribute Flow Records
   based on the value of RD (Route Distinguisher), ingress IF, peering
   AS number, or BGP next hop, all of which identify the customer.  As
   shown in the following figure, the IPFIX Distributor distributes Flow
   Records based on RD.  This system allows each customer's traffic to
   be inspected independently.

                                            .---------.
                                            |Traffic  |
                                      .---->|Collector|<==>Customer#A
                                      |     |#1       |
                                      |     '---------'
                                   RD=100:1
                     .-----------.    |
   .--------.        |IPFIX      |----'     .---------.
   |IPFIX   |        |Distributor| RD=100:2 |Traffic  |
   |router#1|------->|           |--------->|Collector|<==>Customer#B
   |        |        |           |          |#2       |
   '--------'        |           |----.     '---------'
                     '-----------'    |
                                   RD=100:3
                                      |     .---------.
                                      |     |Traffic  |
                                      '---->|Collector|<==>Customer#C
                                            |#3       |
                                            '---------'

                Figure B: Flow-Based Collector Selection.

   There currently is no description of a flow-based collector selection
   function in IPFIX.  In the current implementation, many Exporters
   send all Flow Records to multiple Collectors and those Collectors
   drop uninteresting Flow Records to reduce their load.  This wastes
   network resources.

4.5.  Flow Selection Sampling

   The Flow selection sampling method is described in
   [I-D.peluso-flowselection] in detail.  Generally, the distribution of
   the number of packets per Flow seems to be heavy-tailed.  Most types
   of Flow Records are likely to be small Flows consisting of a small
   number of packets.  The flow-based measurement system, in particular
   the Collecting Process and Exporting Process, is burdened with a huge



Kobayashi, et al.       Expires November 1, 2008               [Page 10]


Internet-Draft         Mediation Problem Statement            April 2008


   number of these small Flows.  If statistics information of small
   Flows is exported as merging data by applying a policy or threshold,
   the burden on measurement system is reduced.  In addition, if this
   function is in the IPFIX Mediator, it is beneficial for enhancing the
   scalability.

4.6.  Information Elements and Flow Keys Selection

   Originally, the Flow Keys [RFC5101] on the routers were defined by a
   fixed seven tuple of packet fields.  However, one way to scale the
   system is to be able to specify the Template Records for specific
   needs.  This extra flexibility in the Metering Process allows
   administrators to specify their own set of Flow Keys and extra
   Information Elements in the Template Record.  On one hand, this
   optimizes the Metering Process, because only Flows of interest are
   looked at.  On the other hand, it optimizes the Exporting Process,
   because only the information of interest is exported.  Finally, this
   reduces load of the Collecting Process as less Flow Records are
   handled, and Flow Record filtering and aggregating are required.
































Kobayashi, et al.       Expires November 1, 2008               [Page 11]


Internet-Draft         Mediation Problem Statement            April 2008


5.  Problems with using IPFIX Mediators

   As described in the previous section, less demanding sampling rates
   make small flows invisible, while aggregated Flow Records make
   elements, e.g. port numbers or IP addresses, invisible.  Even if
   traffic grows, network operators would like to maintain the same
   sampling rate and granularity of flows as much as possible.  A
   hierarchical structure and flow-based Collector selection are useful
   for creating a scalable collection system.  These solutions can be
   implemented by using IPFIX Mediators, such as IPFIX Concentrators and
   IPFIX Distributors.  In this section, we focus on the problems
   related to the use of IPFIX Mediators.

5.1.  Loss of Observation Point Information

   Both the Exporter IP address indicated by the source IP address of
   the IPFIX session as well as the Observation Domain ID included in
   the IPFIX header are likely to be lost in the mediation process
   performed by an IPFIX Mediator.  This IP address and Observation
   Domain ID indicate the Observation Point information from the
   viewpoint of the entire network domain.  Such information is
   necessary for guaranteeing the continuity of the work of the top
   level Collector.  Even if an IPFIX Mediator could, with some new
   mechanism, notify Collectors of this Observation Point information,
   older Collectors might not accept it.  These Collectors would then
   wrongly assume that the IP address of the IPFIX Mediator is that of
   the Original Exporter.  The Collector, however, needs to recognize
   the precise Observation Point whether Flow Records go through an
   IPFIX Mediator or not.






















Kobayashi, et al.       Expires November 1, 2008               [Page 12]


Internet-Draft         Mediation Problem Statement            April 2008


   In the following figure, a Collector could identify 2 Exporters with
   IP addresses of 10.1.1.3 and 10.1.1.2, respectively.  The Collector,
   however, needs to somehow recognize Router#1 and Router#2, which are
   the Original Exporters.  Defined notification methods that can be
   interpreted by Collectors and Mediators are thus necessary.

   .--------.          .--------.
   |IPFIX   |          |IPFIX   |
   |Router#1|--------->|Mediator|---+
   |        |          |        |   |
   '--------'          '--------'   |      .---------.
   IP:10.1.1.1         IP:10.1.1.3  '----->|         |
   ODID:10             ODID:0              |Collector|
                                    +----->|         |
   .--------.                       |      '---------'
   |IPFIX   |                       |
   |Router#2|-----------------------'
   |        |
   '--------'
   IP:10.1.1.2
   ODID:20

     Figure C: Loss of Observation Point Information.

5.2.  Loss of Base Time Information

   The Export Time field included in the IPFIX header indicates the base
   time for Flow Records.  In IPFIX Information Elements, described in
   [RFC5102], there are delta time fields that indicate the time
   difference from the value of the Export Time field.  If the Flow
   Records include any delta time fields and the IPFIX Mediator
   overwrites the Export Time field when sending IPFIX messages, the
   delta time fields become meaningless and, because Collectors can not
   recognize this situation, wrong time values are propagated.

5.3.  Loss of Option Template Information

   In some cases, depending on the implementation of the IPFIX
   Mediators, the information that is reported by the Option Templates
   could also be lost.  If, for example, the sampling rate is not
   communicated to the Collectors, a Collector would miscalculate the
   traffic volume.  This might bring crucial problems.  Even if an IPFIX
   Mediator were to simply relay received Option Template Information,
   the value of its scope fields would become meaningless in the context
   of a different session.  It should be noted that the minimal
   information to be communicated by an IPFIX Mediator needs to be
   defined.




Kobayashi, et al.       Expires November 1, 2008               [Page 13]


Internet-Draft         Mediation Problem Statement            April 2008


5.4.  Observation Domain ID and Template ID Management

   The Observation Domain ID is locally unique to the Exporting Process
   in an IPFIX Mediator, just like the Template ID is unique on the
   basis of the Observation Domain ID.  These renewed identifiers should
   be managed using the Transport Session Information of the Collecting
   Process.  If IPFIX Mediators could not manage the relations among
   these identifiers and the received Transport Session Information, the
   Mediators would, for example, relay wrong values for the scope fields
   of the Option Template and for a "Template Withdraw Message".  In
   most cases, a Collector would not be able to interpret the Template
   ID of a "Template Withdraw Message" and the scope fields of an Option
   Template.  The Collector would then shut down the IPFIX Session.

5.5.  Transport Sessions Management

   How an IPFIX Mediator maintains relationships between the Transport
   Sessions of Collecting Processes and of Exporting Processes depends
   on its implementation.  If multiple Transport Sessions of the
   Collecting Process are relayed to single Transport Session of the
   Exporting Process and the IPFIX Mediators shuts down the Transport
   Session of the Exporting Process, Flow Records on other Transport
   Sessions of the Collecting Processes would not be relayed at all.  In
   the case of resetting a session of the Collecting Process, the
   behavior of the IPFIX Mediator needs to be defined.


   .--------.
   |IPFIX   |
   |Router#1|----+
   |        |    |
   '--------'    X
   .--------.    |     .--------.          .---------.
   |IPFIX   |    '---->|IPFIX   |          |         |
   |Router#2|--------->|Mediator|----X---->|Collector|
   |        |    +---->|        |          |         |
   '--------'    |     '--------'          '---------'
   .--------.    |
   |IPFIX   |    |
   |Router#3|----'
   |        |
   '--------'

   Figure D: Relaying from Multiple Transport Sessions
             to Single Transport Session.






Kobayashi, et al.       Expires November 1, 2008               [Page 14]


Internet-Draft         Mediation Problem Statement            April 2008


6.  Conclusion

   This document has covered a multitude of problems related to the
   flow-based measurement system in IPFIX Mediation and described the
   applicability of IPFIX Mediators.  In particular, section 4 listed
   several solutions to cope with huge traffic volumes.  These problems
   can not be solved by simply adjusting the sampling rate and/or
   granularity of the Flow Records.  The use of IPFIX Mediators, on the
   other hand, seems to be a means for constructing large-scale
   collection systems to achieve scalability.  In addition, network
   operators can explore solutions by utilizing the advanced features of
   Exporters and Collectors.  To assist the ability of the Exporters and
   Collectors, it should be noted that there are various IPFIX Mediators
   for the network providers to select from.  Examples of the
   applicability of IPFIX Mediators are as follows.

   o  Regarding Inter-domain IPFIX Exporting, IPFIX Mediators help
      network operators to anonymize or filter Flows, preventing privacy
      violations.

   o  Regarding data retention, IPFIX Mediators enhance the storage of
      the measurement system.

   o  Regarding interoperability, IPFIX Mediators provide
      interoperability between legacy protocols and IPFIX, even during
      the migration period to IPFIX.

   o  Regarding the flow-based collector selection function, in
      integrated networks, which mix MPLS VPN and IPv4/IPv6, this could
      be utilized more frequently.  More sophisticated implementation
      methods would enhance the effectiveness.

   o  Regarding scalability in large-scale networks, IPFIX Mediators
      help to achieve high sample rates and fine-grained Flow analysis
      even as networks grow.  As intermediate functions, Flow selection
      sampling or aggregation are beneficial.

   As a result, the benefits of IPFIX Mediation become apparent.
   However, there are still some open issues.

   o  With the use of IPFIX Mediators, both Observation Point and IPFIX
      header information, such as the Exporter IP address, Observation
      Domain ID, and Export Time field, might be lost.  This data should
      therefore be communicated between the Original Exporter and
      Collector via the IPFIX Mediator.

   o  With the use of IPFIX Mediators, data advertised by Option
      Templates from the Original Exporter, such as the sampling rate



Kobayashi, et al.       Expires November 1, 2008               [Page 15]


Internet-Draft         Mediation Problem Statement            April 2008


      and sampling algorithm used, might be lost.  If a Collector is not
      informed of current sampling rates, traffic information might
      become worthless.

   o  IPFIX Mediators are required to manage Transport Sessions,
      Template IDs, and Observation Domain IDs.  Otherwise, anomalous
      IPFIX messages could be created.

   These problems stem from the fact that no standards regarding IPFIX
   Mediation have been set.  In particular, the minimum set of
   information which should be communicated between the Original
   Exporter and Collector, interworking between different IPFIX
   Transport Sessions, and the internal components of IPFIX Mediators
   should be standardized.





































Kobayashi, et al.       Expires November 1, 2008               [Page 16]


Internet-Draft         Mediation Problem Statement            April 2008


7.  Security Considerations

   A flow-based measurement system might lead to privacy violations,
   such as the export of Flow Records to an outside address, if the
   system is not confined to the large-scale network under observation.
   General security issues of the IPFIX protocol are covered by the
   security considerations section in [RFC5101].  Security MUST be
   considered if different networks exchange Flow information.  As the
   security of the exchange relies mostly on the protocol used, UDP does
   not seem appropriate for the exchange of information between
   networks.








































Kobayashi, et al.       Expires November 1, 2008               [Page 17]


Internet-Draft         Mediation Problem Statement            April 2008


8.  IANA Considerations

   This document has no actions for IANA.
















































Kobayashi, et al.       Expires November 1, 2008               [Page 18]


Internet-Draft         Mediation Problem Statement            April 2008


9.  References

9.1.  Normative References

   [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
              "Requirements for IP Flow Information Export(IPFIX)",
              October 2004.

   [RFC3954]  Claise, B., "Cisco Systems NetFlow Services Export Version
              9", October 2004.

   [RFC5101]  Claise, B., "Specification of the IP Flow Information
              Export (IPFIX) Protocol for the Exchange of IP Traffic
              Flow Information", January 2008.

   [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
              Meyer, "Information Model for IP Flow Information Export",
              January 2008.

9.2.  Informative References

   [I-D.dressler-ipfix-aggregation]
              Dressler, F., Sommer, C., Munz, G., and A. Kobayashi,
              "IPFIX Aggregation",
              draft-dressler-ipfix-aggregation-04.txt (work in
              progress) , November 2007.

   [I-D.peluso-flowselection]
              Peluso, L., Zseby, T., D'Antonio, S., and M. Molina, "Flow
              selection Techniques",
              draft-peluso-flowselection-tech-01.txt (work in
              progress) , November 2007.

   [TRAFGRW]  Cho, K., Fukuda, K., Esaki, H., and A. Kato, "The Impact
              and Implications of the Growth in Residential User-to-User
              Traffic", SIGCOMM2006, pp. 207-218, Pisa, Italy, September
              2006. , October 2006.














Kobayashi, et al.       Expires November 1, 2008               [Page 19]


Internet-Draft         Mediation Problem Statement            April 2008


Authors' Addresses

   Atsushi Kobayashi
   NTT Information Sharing Platform Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo  180-8585
   Japan

   Phone: +81-422-59-3978
   Email: akoba@nttv6.net


   Haruhiko Nishida
   NTT Information Sharing Platform Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo  180-8585
   Japan

   Phone: +81-422-59-3978
   Email: nishida.haruhiko@lab.ntt.co.jp


   Christoph Sommer
   University of Erlangen-Nuremberg
   Department of Computer Science 7
   Martensstr. 3
   Erlangen  91058
   Germany

   Phone: +49 9131 85-27993
   Email: christoph.sommer@informatik.uni-erlangen.de
   URI:   http://www7.informatik.uni-erlangen.de/~sommer/


   Falko Dressler
   University of Erlangen-Nuremberg
   Department of Computer Science 7
   Martensstr. 3
   Erlangen  91058
   Germany

   Phone: +49 9131 85-27914
   Email: dressler@informatik.uni-erlangen.de
   URI:   http://www7.informatik.uni-erlangen.de/~dressler/







Kobayashi, et al.       Expires November 1, 2008               [Page 20]


Internet-Draft         Mediation Problem Statement            April 2008


   Emile Stephan
   France Telecom
   2 avenue Pierre Marzin
   Lannion  F-22307
   France

   Phone: +33 2 96 05 18 52
   Email: emile.stephan@orange-ftgroup.com


   Benoit Claise
   Cisco Systems
   De Kleetlaan 6a b1
   Diegem  1831
   Belgium

   Phone: +32 2 704 5622
   Email: bclaise@cisco.com

































Kobayashi, et al.       Expires November 1, 2008               [Page 21]


Internet-Draft         Mediation Problem Statement            April 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Kobayashi, et al.       Expires November 1, 2008               [Page 22]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/