From akoba@nttv6.net Mon Jul 6 09:08:33 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053A928C297 for ; Mon, 6 Jul 2009 09:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=2.040, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKNTsfLrGMN5 for ; Mon, 6 Jul 2009 09:08:31 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 5113828C2AB for ; Mon, 6 Jul 2009 09:08:30 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:ec2e:dba6:56ea:92db]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n66G8n9V019765; Tue, 7 Jul 2009 01:08:49 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 07 Jul 2009 01:04:35 +0900 From: Atsushi Kobayashi To: Benoit Claise In-Reply-To: <4A44F660.1090300@cisco.com> References: <4A44F660.1090300@cisco.com> Message-Id: <20090707010123.827D.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 07 Jul 2009 01:08:49 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 16:08:33 -0000 Dear Brian, Gerhard, Benoit and all, While writing next version IPFIX problem statement and framework draft, I found the following discrepancy between IPFIX Mediation and IPFIX Mediator. the term IPFIX Mediation implies that IPFIX Mediator hosts one or more Intermediate Processes. IPFIX Mediation IPFIX Mediation describes the manipulation and conversion of records for subsequent export using IPFIX, by applying mediation functions within one or more Intermediate Processes to a stream of ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ records in an IPFIX Mediator. IPFIX Mediator An IPFIX Mediator is an IPFIX Device that provides mediation capabilities by receiving records from some data source, hosting zero or more Intermediate Processes to transform those records, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ and exporting those records in IPFIX Messages via an Exporting Process. In the common case, a Mediator receives records from a Collecting Process, but could also receive records from data sources not encoded using IPFIX, e.g., in the case of NetFlow V9 protocol translation. I'd like to propose the new term IPFIX Mediation as follows. IPFIX Mediation IPFIX Mediation describes the manipulation and conversion of records or IPFIX Messages for subsequent export using IPFIX, by applying mediation functions within one or more Intermediate Processes to a stream of records, or applying transport based mediation functions to IPFIX Messages. Does it make sense? Regards, Atsushi On Fri, 26 Jun 2009 18:25:04 +0200 Benoit Claise wrote: > Dear all, > > I'm trying to summarize the long email thread. Not easy, there are some > diverging opinions. I hope I haven't forgotten anything > Below is the terminology proposal, based on Brian's proposal, improved > by Gerhard, and everybody. > > 2. Terminology and Definitions > > The terms in this section are in line with those in the IPFIX > Protocol specifications [RFC5101] and the PSAMP specification > document [RFC5476]. The terms Observation Point, Observation Domain, > Flow Key, Flow Record, Data Record, Exporting Process, Exporter, > IPFIX Device, Collecting Process, Collector, IPFIX Message, Metering > Process, Transport Session, Information Element, and Template > Withdrawal Message, are defined in the IPFIX protocol specifications > [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP > Device, and Configured Selection Fraction are defined in the PSAMP > specification document [RFC5476]. Furthermore, new terminology to be > used in the context of IPFIX Mediation is defined in this section. > All these terms have an initial capital letter in this document. > > In this document, we use the generic term "Data Records" for IPFIX > Flow Records, PSAMP Packet Reports, Data Records defined by Options > Templates, unless an explicit distinction is required. > > Original Exporter > > Original Exporter is an IPFIX Device that hosts the Observation > Points where the metered IP packets are observed. > > IPFIX Mediation > > IPFIX Mediation describes the manipulation and conversion of records > for subsequent export using IPFIX, by applying mediation functions > within one or more Intermediate Processes to a stream of records in > an IPFIX Mediator. > > The following terms are used in this document to describe the > architectural entities used by IPFIX Mediation. > > Intermediate Process > > An Intermediate Process takes a sequence of records from a Collecting > Process, Metering Process, IPFIX File Reader, or another Intermediate > Process within a Mediator; performs some transformation on these > records > based upon the content of the records themselves, state kept across > multiple records, configuration parameters, or other data; and passes > a sequence of transformed records on to an Exporting Process, > IPFIX File > Writer, or another Intermediate Process within a Mediator. This > document > describes specific Intermediate Processes below used in the > elaboration > of the problem statement; however, this is not an exhaustive list. > > Intermediate Aggregation Process > > An Intermediate Aggregation Process is an Intermediate Process that > aggregates records based upon a set of Flow Keys, or functions > applied to fields from the record (e.g. binning, subnet aggregation). > > Intermediate Correlation Process > > An Intermediate Correlation Process is an Intermediate Process > which adds information to records noting correlations among them, > or generates new records with correlated data from multiple > records (e.g. the production of bidirectional flow records from > unidirectional flow records). > > Intermediate Selection Process > > An Intermediate Selection Process is an Intermediate Process that > selects records from a sequence based upon criteria evaluated > record values, and passes only those records that match the > criteria (e.g. filtering only records from a given network to a > given Collector). > > Intermediate Anonymisation Process > > An Intermediate Anonymisation Process is an Intermediate Process > that transforms records in order to anonymise them, to protect the > identity of the entities described by the records (e.g. by > applying prefix-preserving pseudonymisation of IP addresses). > > IPFIX Mediator > > An IPFIX Mediator is an IPFIX Device that provides mediation > capabilities by receiving records from some data source, hosting > zero or more Intermediate Processes to transform those records, > and exporting those records in IPFIX Messages via an Exporting > Process. In the common case, a Mediator receives records from a > Collecting Process, but could also receive records from data > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > protocol translation. Specific types of Mediators are defined > below; some of these reference original mediation capabilities > defined in earlier IPFIX documens before the elaboration of the > Mediator problem statement. > > Original Exporter > > Original Exporter is an IPFIX Device that hosts the Observation > Points where the metered IP packets are observed. > > IPFIX Proxy > > An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX > Messages or messages in other protocols to one or more Collectors. > It can provide transport protocol mediation and re-encoding. > > IPFIX Concentrator > > An IPFIX Concentrator is an IPFIX Mediator that recieves data from > one or more Exporters and sends them to a single Collector, > optionally transforming the records using zero or more > Intermediate Processes on the way. > > IPFIX Distributor > > An IPFIX Distributor is an IPFIX Mediator that recieves data from > one or more Exporters and sends them to one or more Collectors, > deciding which Collector(s) to send each record to based upon the > decision of an Intermediate Selection Process. > > IPFIX Masquerading Proxy > > An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves > data from one or more Exporters and sends them to a single > Collector, using one or more Intermediate Aggregation Functions > and Intermediate Anonymisation Functions to screen out parts of > records according to configured policies, in order to protect the > privacy of the network's end users or senstive data of the > exporting organization. > > > I think that we agree that the same terminology sections in both the > problem statement and framework. > Personally, I'm not sure (yet) if we need the Intermediate > Aggregation/Correlation/Selection/Anonynisation Process. > However, if we do, my proposal is to omit this list from the problem > statement, and to simply put them in the framework. > > Please let us know, so that we can move forward with the drafts, both > the problem statements and the framework. > > Regards, Benoit. > > > > > > > > > > > > > > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From trammell@tik.ee.ethz.ch Mon Jul 6 09:46:59 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB793A6ADB for ; Mon, 6 Jul 2009 09:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.849 X-Spam-Level: X-Spam-Status: No, score=-7.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+Nn1hUg-6F5 for ; Mon, 6 Jul 2009 09:46:57 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 8CCBD3A67CF for ; Mon, 6 Jul 2009 09:46:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5397AD937F; Mon, 6 Jul 2009 18:40:23 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Iqdo818LkMzb; Mon, 6 Jul 2009 18:40:23 +0200 (MEST) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 126BDD9345; Mon, 6 Jul 2009 18:40:23 +0200 (MEST) Message-Id: From: Brian Trammell To: Atsushi Kobayashi In-Reply-To: <20090707010123.827D.17391CF2@nttv6.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 6 Jul 2009 18:40:22 +0200 References: <4A44F660.1090300@cisco.com> <20090707010123.827D.17391CF2@nttv6.net> X-Mailer: Apple Mail (2.935.3) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 16:46:59 -0000 hi Kobayashi-san, see inline, as per the protocol. ;) On Jul 6, 2009, at 6:04 PM, Atsushi Kobayashi wrote: > > Dear Brian, Gerhard, Benoit and all, > > While writing next version IPFIX problem statement and framework > draft, > I found the following discrepancy between IPFIX Mediation and IPFIX > Mediator. the term IPFIX Mediation implies that IPFIX Mediator hosts > one or > more Intermediate Processes. > > IPFIX Mediation > > IPFIX Mediation describes the manipulation and conversion of > records for subsequent export using IPFIX, by applying mediation > functions within one or more Intermediate Processes to a stream > of > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > records in an IPFIX Mediator. > > IPFIX Mediator > > An IPFIX Mediator is an IPFIX Device that provides mediation > capabilities by receiving records from some data source, hosting > zero or more Intermediate Processes to transform those records, > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > and exporting those records in IPFIX Messages via an Exporting > Process. In the common case, a Mediator receives records from a > Collecting Process, but could also receive records from data > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > protocol translation. > > I'd like to propose the new term IPFIX Mediation as follows. > > IPFIX Mediation > > IPFIX Mediation describes the manipulation and conversion of > records or IPFIX Messages for subsequent export using IPFIX, by > applying mediation functions within one or more Intermediate > Processes to a stream of records, or applying transport based > mediation functions to IPFIX Messages. > > Does it make sense? Almost. Mediation may actually consist of transport mediation only, so, zero intermediate processes. "Mediation" as a defined term (if we even need it) probably doesn't need to talk about processes anyway, so how about: IPFIX Mediation is the manipulation and conversion of records or IPFIX Messages for subsequent export using IPFIX, by applying mediation functions to a stream of records, and/or applying transport based mediation functions to IPFIX Messages. Regards, Brian > Regards, > Atsushi > > On Fri, 26 Jun 2009 18:25:04 +0200 > Benoit Claise wrote: > >> Dear all, >> >> I'm trying to summarize the long email thread. Not easy, there are >> some >> diverging opinions. I hope I haven't forgotten anything >> Below is the terminology proposal, based on Brian's proposal, >> improved >> by Gerhard, and everybody. >> >> 2. Terminology and Definitions >> >> The terms in this section are in line with those in the IPFIX >> Protocol specifications [RFC5101] and the PSAMP specification >> document [RFC5476]. The terms Observation Point, Observation >> Domain, >> Flow Key, Flow Record, Data Record, Exporting Process, Exporter, >> IPFIX Device, Collecting Process, Collector, IPFIX Message, >> Metering >> Process, Transport Session, Information Element, and Template >> Withdrawal Message, are defined in the IPFIX protocol >> specifications >> [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP >> Device, and Configured Selection Fraction are defined in the PSAMP >> specification document [RFC5476]. Furthermore, new terminology >> to be >> used in the context of IPFIX Mediation is defined in this section. >> All these terms have an initial capital letter in this document. >> >> In this document, we use the generic term "Data Records" for IPFIX >> Flow Records, PSAMP Packet Reports, Data Records defined by Options >> Templates, unless an explicit distinction is required. >> >> Original Exporter >> >> Original Exporter is an IPFIX Device that hosts the Observation >> Points where the metered IP packets are observed. >> >> IPFIX Mediation >> >> IPFIX Mediation describes the manipulation and conversion of >> records >> for subsequent export using IPFIX, by applying mediation >> functions >> within one or more Intermediate Processes to a stream of >> records in >> an IPFIX Mediator. >> >> The following terms are used in this document to describe the >> architectural entities used by IPFIX Mediation. >> >> Intermediate Process >> >> An Intermediate Process takes a sequence of records from a >> Collecting >> Process, Metering Process, IPFIX File Reader, or another >> Intermediate >> Process within a Mediator; performs some transformation on these >> records >> based upon the content of the records themselves, state kept >> across >> multiple records, configuration parameters, or other data; and >> passes >> a sequence of transformed records on to an Exporting Process, >> IPFIX File >> Writer, or another Intermediate Process within a Mediator. This >> document >> describes specific Intermediate Processes below used in the >> elaboration >> of the problem statement; however, this is not an exhaustive >> list. >> >> Intermediate Aggregation Process >> >> An Intermediate Aggregation Process is an Intermediate Process >> that >> aggregates records based upon a set of Flow Keys, or functions >> applied to fields from the record (e.g. binning, subnet >> aggregation). >> >> Intermediate Correlation Process >> >> An Intermediate Correlation Process is an Intermediate Process >> which adds information to records noting correlations among >> them, >> or generates new records with correlated data from multiple >> records (e.g. the production of bidirectional flow records from >> unidirectional flow records). >> >> Intermediate Selection Process >> >> An Intermediate Selection Process is an Intermediate Process >> that >> selects records from a sequence based upon criteria evaluated >> record values, and passes only those records that match the >> criteria (e.g. filtering only records from a given network to a >> given Collector). >> >> Intermediate Anonymisation Process >> >> An Intermediate Anonymisation Process is an Intermediate Process >> that transforms records in order to anonymise them, to protect >> the >> identity of the entities described by the records (e.g. by >> applying prefix-preserving pseudonymisation of IP addresses). >> >> IPFIX Mediator >> >> An IPFIX Mediator is an IPFIX Device that provides mediation >> capabilities by receiving records from some data source, hosting >> zero or more Intermediate Processes to transform those records, >> and exporting those records in IPFIX Messages via an Exporting >> Process. In the common case, a Mediator receives records from a >> Collecting Process, but could also receive records from data >> sources not encoded using IPFIX, e.g., in the case of NetFlow V9 >> protocol translation. Specific types of Mediators are defined >> below; some of these reference original mediation capabilities >> defined in earlier IPFIX documens before the elaboration of the >> Mediator problem statement. >> >> Original Exporter >> >> Original Exporter is an IPFIX Device that hosts the Observation >> Points where the metered IP packets are observed. >> >> IPFIX Proxy >> >> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX >> Messages or messages in other protocols to one or more >> Collectors. >> It can provide transport protocol mediation and re-encoding. >> >> IPFIX Concentrator >> >> An IPFIX Concentrator is an IPFIX Mediator that recieves data >> from >> one or more Exporters and sends them to a single Collector, >> optionally transforming the records using zero or more >> Intermediate Processes on the way. >> >> IPFIX Distributor >> >> An IPFIX Distributor is an IPFIX Mediator that recieves data >> from >> one or more Exporters and sends them to one or more Collectors, >> deciding which Collector(s) to send each record to based upon >> the >> decision of an Intermediate Selection Process. >> >> IPFIX Masquerading Proxy >> >> An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves >> data from one or more Exporters and sends them to a single >> Collector, using one or more Intermediate Aggregation Functions >> and Intermediate Anonymisation Functions to screen out parts of >> records according to configured policies, in order to protect >> the >> privacy of the network's end users or senstive data of the >> exporting organization. >> >> >> I think that we agree that the same terminology sections in both the >> problem statement and framework. >> Personally, I'm not sure (yet) if we need the Intermediate >> Aggregation/Correlation/Selection/Anonynisation Process. >> However, if we do, my proposal is to omit this list from the problem >> statement, and to simply put them in the framework. >> >> Please let us know, so that we can move forward with the drafts, both >> the problem statements and the framework. >> >> Regards, Benoit. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Mon Jul 6 12:06:27 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6312F28C45B for ; Mon, 6 Jul 2009 12:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ur1RkcQPZOQ for ; Mon, 6 Jul 2009 12:06:25 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) by core3.amsl.com (Postfix) with ESMTP id 581BF28C436 for ; Mon, 6 Jul 2009 12:05:45 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 01A9C483B0; Mon, 6 Jul 2009 21:05:49 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id E92AC50BD; Mon, 6 Jul 2009 21:05:48 +0200 (CEST) Message-ID: <4A524B74.40301@net.in.tum.de> Date: Mon, 06 Jul 2009 21:07:32 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Atsushi Kobayashi References: <4A44F660.1090300@cisco.com> <20090707010123.827D.17391CF2@nttv6.net> In-Reply-To: <20090707010123.827D.17391CF2@nttv6.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020002040306040608060605" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:06:27 -0000 This is a cryptographically signed message in MIME format. --------------ms020002040306040608060605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Atsushi, What is the motivation for this change? Is it the use case of translating NetFlow into IPFIX? I assume that in most of the cases this translation cannot be done by just copying Records from a NetFlow Packet into an IPFIX Message. Typically, some small changes to the Template and Data Records are required (e.g., conversion of IE IDs), which would be done by an Intermediate Process. You can call it Intermediate Conversion Process. Having an Intermediate Process, it fits into the current definition of IPFIX Mediation :) Regards, Gerhard Atsushi Kobayashi wrote: > Dear Brian, Gerhard, Benoit and all, >=20 > While writing next version IPFIX problem statement and framework draft,= > I found the following discrepancy between IPFIX Mediation and IPFIX > Mediator. the term IPFIX Mediation implies that IPFIX Mediator hosts on= e or > more Intermediate Processes. >=20 > IPFIX Mediation >=20 > IPFIX Mediation describes the manipulation and conversion of > records for subsequent export using IPFIX, by applying mediation > functions within one or more Intermediate Processes to a stream o= f > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > records in an IPFIX Mediator. >=20 > IPFIX Mediator >=20 > An IPFIX Mediator is an IPFIX Device that provides mediation > capabilities by receiving records from some data source, hosting > zero or more Intermediate Processes to transform those records, > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > and exporting those records in IPFIX Messages via an Exporting > Process. In the common case, a Mediator receives records from a > Collecting Process, but could also receive records from data > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > protocol translation. >=20 > I'd like to propose the new term IPFIX Mediation as follows. >=20 > IPFIX Mediation >=20 > IPFIX Mediation describes the manipulation and conversion of > records or IPFIX Messages for subsequent export using IPFIX, by > applying mediation functions within one or more Intermediate > Processes to a stream of records, or applying transport based=20 > mediation functions to IPFIX Messages. >=20 > Does it make sense? >=20 > Regards, > Atsushi >=20 > On Fri, 26 Jun 2009 18:25:04 +0200 > Benoit Claise wrote: >=20 >> Dear all, >> >> I'm trying to summarize the long email thread. Not easy, there are som= e=20 >> diverging opinions. I hope I haven't forgotten anything >> Below is the terminology proposal, based on Brian's proposal, improved= =20 >> by Gerhard, and everybody. >> >> 2. Terminology and Definitions >> >> The terms in this section are in line with those in the IPFIX >> Protocol specifications [RFC5101] and the PSAMP specification >> document [RFC5476]. The terms Observation Point, Observation Domai= n, >> Flow Key, Flow Record, Data Record, Exporting Process, Exporter, >> IPFIX Device, Collecting Process, Collector, IPFIX Message, Meterin= g >> Process, Transport Session, Information Element, and Template >> Withdrawal Message, are defined in the IPFIX protocol specification= s >> [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP >> Device, and Configured Selection Fraction are defined in the PSAMP >> specification document [RFC5476]. Furthermore, new terminology to = be >> used in the context of IPFIX Mediation is defined in this section. >> All these terms have an initial capital letter in this document. >> >> In this document, we use the generic term "Data Records" for IPFIX >> Flow Records, PSAMP Packet Reports, Data Records defined by Options= >> Templates, unless an explicit distinction is required. >> >> Original Exporter >> >> Original Exporter is an IPFIX Device that hosts the Observation >> Points where the metered IP packets are observed. >> >> IPFIX Mediation =20 >> >> IPFIX Mediation describes the manipulation and conversion of rec= ords >> for subsequent export using IPFIX, by applying mediation functio= ns >> within one or more Intermediate Processes to a stream of records= in >> an IPFIX Mediator. >> =20 >> The following terms are used in this document to describe the >> architectural entities used by IPFIX Mediation. >> >> Intermediate Process >> >> An Intermediate Process takes a sequence of records from a Colle= cting >> Process, Metering Process, IPFIX File Reader, or another Interme= diate >> Process within a Mediator; performs some transformation on these= =20 >> records >> based upon the content of the records themselves, state kept acr= oss >> multiple records, configuration parameters, or other data; and p= asses >> a sequence of transformed records on to an Exporting Process,=20 >> IPFIX File >> Writer, or another Intermediate Process within a Mediator. This = >> document >> describes specific Intermediate Processes below used in the=20 >> elaboration >> of the problem statement; however, this is not an exhaustive lis= t. >> >> Intermediate Aggregation Process >> >> An Intermediate Aggregation Process is an Intermediate Process th= at >> aggregates records based upon a set of Flow Keys, or functions >> applied to fields from the record (e.g. binning, subnet aggregati= on). >> >> Intermediate Correlation Process >> >> An Intermediate Correlation Process is an Intermediate Process >> which adds information to records noting correlations among them= , >> or generates new records with correlated data from multiple >> records (e.g. the production of bidirectional flow records from >> unidirectional flow records). >> >> Intermediate Selection Process >> >> An Intermediate Selection Process is an Intermediate Process tha= t >> selects records from a sequence based upon criteria evaluated >> record values, and passes only those records that match the >> criteria (e.g. filtering only records from a given network to a >> given Collector). >> >> Intermediate Anonymisation Process >> >> An Intermediate Anonymisation Process is an Intermediate Process= >> that transforms records in order to anonymise them, to protect t= he >> identity of the entities described by the records (e.g. by >> applying prefix-preserving pseudonymisation of IP addresses). >> >> IPFIX Mediator >> >> An IPFIX Mediator is an IPFIX Device that provides mediation >> capabilities by receiving records from some data source, hosting= >> zero or more Intermediate Processes to transform those records, >> and exporting those records in IPFIX Messages via an Exporting >> Process. In the common case, a Mediator receives records from a= >> Collecting Process, but could also receive records from data >> sources not encoded using IPFIX, e.g., in the case of NetFlow V9= >> protocol translation. Specific types of Mediators are defined >> below; some of these reference original mediation capabilities >> defined in earlier IPFIX documens before the elaboration of the >> Mediator problem statement. >> >> Original Exporter >> >> Original Exporter is an IPFIX Device that hosts the Observation >> Points where the metered IP packets are observed. >> >> IPFIX Proxy >> >> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX >> Messages or messages in other protocols to one or more Collector= s. >> It can provide transport protocol mediation and re-encoding. >> >> IPFIX Concentrator >> >> An IPFIX Concentrator is an IPFIX Mediator that recieves data fr= om >> one or more Exporters and sends them to a single Collector, >> optionally transforming the records using zero or more >> Intermediate Processes on the way. >> >> IPFIX Distributor >> >> An IPFIX Distributor is an IPFIX Mediator that recieves data fro= m >> one or more Exporters and sends them to one or more Collectors, >> deciding which Collector(s) to send each record to based upon th= e >> decision of an Intermediate Selection Process. >> >> IPFIX Masquerading Proxy >> >> An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves >> data from one or more Exporters and sends them to a single >> Collector, using one or more Intermediate Aggregation Functions >> and Intermediate Anonymisation Functions to screen out parts of >> records according to configured policies, in order to protect th= e >> privacy of the network's end users or senstive data of the >> exporting organization. >> >> >> I think that we agree that the same terminology sections in both the=20 >> problem statement and framework. >> Personally, I'm not sure (yet) if we need the Intermediate=20 >> Aggregation/Correlation/Selection/Anonynisation Process. >> However, if we do, my proposal is to omit this list from the problem=20 >> statement, and to simply put them in the framework. >> >> Please let us know, so that we can move forward with the drafts, both = >> the problem statements and the framework. >> >> Regards, Benoit. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 > ---=20 > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms020002040306040608060605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzA2MTkwNzMyWjAjBgkqhkiG9w0BCQQxFgQU 6pwZL5fAXX0t0zIhWilHFDYjIUAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBACtkMQE6zJQpR4yW1KH9FwyWx0faxjKyBku9moFT3OTsi56i sPY7SrBcNnfm3bI8f29xnfC4HPZGt961t1b/yjM6iayUX8wurCnN0mOgPB+4Jx9v264JqwmW aPTqHegPVoHj/H/D69qRfjFO49PmYHmt8GQJLR+y/N+NDvFdNwFzLfuDb0rcddq+BspCNlfz sI6QYBuSPqJSpzXlLpo2AcHM0OyFgfPhZdi2/5KMA665lmGB9asFD9rgbvyf5H6YpWOkvay5 etv2MPVROW6njU9AEC4qWGob5sJQ5XmvP9XtjXOyqhnoUCE+qB/Ldo959ASYlkVD6CDnaiut GnHlzWEAAAAAAAA= --------------ms020002040306040608060605-- From akoba@nttv6.net Mon Jul 6 15:50:12 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25333A6E05 for ; Mon, 6 Jul 2009 15:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.288 X-Spam-Level: X-Spam-Status: No, score=-0.288 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAzg-ylnqlbR for ; Mon, 6 Jul 2009 15:50:11 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 3FA4C3A6D11 for ; Mon, 6 Jul 2009 15:48:44 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:ec2e:dba6:56ea:92db]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n66Mn4Lk041502; Tue, 7 Jul 2009 07:49:07 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 07 Jul 2009 07:44:52 +0900 From: Atsushi Kobayashi To: Brian Trammell In-Reply-To: References: <20090707010123.827D.17391CF2@nttv6.net> Message-Id: <20090707074235.8283.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 07 Jul 2009 07:49:07 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 22:50:12 -0000 Hi Brian, On Mon, 6 Jul 2009 18:40:22 +0200 Brian Trammell wrote: > > IPFIX Mediation is the manipulation and conversion of > records or IPFIX Messages for subsequent export using IPFIX, > by applying mediation functions to a stream of records, and/or > applying transport based mediation functions to IPFIX Messages. Fine. I agree. Regards, Atsushi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From akoba@nttv6.net Mon Jul 6 15:50:28 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2D03A6DBE for ; Mon, 6 Jul 2009 15:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV9EB19ZtEsI for ; Mon, 6 Jul 2009 15:50:26 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 2A62A3A6CB4 for ; Mon, 6 Jul 2009 15:49:44 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:ec2e:dba6:56ea:92db]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n66Mnxg0041510; Tue, 7 Jul 2009 07:50:02 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 07 Jul 2009 07:45:47 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4A524B74.40301@net.in.tum.de> References: <20090707010123.827D.17391CF2@nttv6.net> <4A524B74.40301@net.in.tum.de> Message-Id: <20090707065723.8280.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 07 Jul 2009 07:50:02 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 22:50:28 -0000 Hi Gerhard, > Having an Intermediate Process, it fits into the current definition of > IPFIX Mediation :) I would like to discuss your points. We can choose the two ways: 1) Transport mediation does not need Intermediate Process, content mediation needs one or more Intermediate Process. We can consider the following IPFIX-related Devices in RFC3917 as IPFIX Mediation. +---+ +---+ +---+ | E-+-> | E-+-> | E-+------------->---+ | | | | | | | | | +---+ +-+-----+ +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> | | | | | | | | | | +---+ +-+-----+ +-+-+ +-+-+ | O | | M | | E-+->---+ | | | | +---+ | | | | | | | M | +-+-+ | O | | M | | | | | | | +---+ | | | +-----+ | O | | O | | O | ->-+-C-E-+-> +---+ +---+ +---+ +-----+ Protocol Remote Concentrator Proxy Converter Observation Figure 2: IPFIX-related Devices In case of conversion NetFlow to IPFIX, the protocol converter hosts a Exporting process only. 2) All of IPFIX Mediation has one or more Intermediate Process whether transport mediation or content mediation. In case of protocol converter, IPFIX Mediation has Intermediate Conversion Process as you suggested. And in case of IPFIX Proxy, we have to consider some Intermediate Foo Process. Although the definition is not consistent with RFC3917, it is not important in it. Gerhard, which one do you prefer? Actually, I thought same thing that the protocol converter needs Intermediate Process converting IE and/or creating subsidiary information (e.g. Flow Key map and sampling parameter) in form of Data Records. But, it can done in Exporting Process forming IPFIX Message, too. While reading twice in mailing list, I assumed that we will adopt case 1 through long discussion. But, I don't adhere case 1, I would like to get the consensus to progress to next stage. Regards, Atsushi On Mon, 06 Jul 2009 21:07:32 +0200 Gerhard Muenz wrote: > > Atsushi, > > What is the motivation for this change? > Is it the use case of translating NetFlow into IPFIX? > > I assume that in most of the cases this translation cannot be done by > just copying Records from a NetFlow Packet into an IPFIX Message. > Typically, some small changes to the Template and Data Records are > required (e.g., conversion of IE IDs), which would be done by an > Intermediate Process. You can call it Intermediate Conversion Process. > > Having an Intermediate Process, it fits into the current definition of > IPFIX Mediation :) > > Regards, > Gerhard > > > Atsushi Kobayashi wrote: > > Dear Brian, Gerhard, Benoit and all, > > > > While writing next version IPFIX problem statement and framework draft, > > I found the following discrepancy between IPFIX Mediation and IPFIX > > Mediator. the term IPFIX Mediation implies that IPFIX Mediator hosts one or > > more Intermediate Processes. > > > > IPFIX Mediation > > > > IPFIX Mediation describes the manipulation and conversion of > > records for subsequent export using IPFIX, by applying mediation > > functions within one or more Intermediate Processes to a stream of > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > records in an IPFIX Mediator. > > > > IPFIX Mediator > > > > An IPFIX Mediator is an IPFIX Device that provides mediation > > capabilities by receiving records from some data source, hosting > > zero or more Intermediate Processes to transform those records, > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > and exporting those records in IPFIX Messages via an Exporting > > Process. In the common case, a Mediator receives records from a > > Collecting Process, but could also receive records from data > > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > > protocol translation. > > > > I'd like to propose the new term IPFIX Mediation as follows. > > > > IPFIX Mediation > > > > IPFIX Mediation describes the manipulation and conversion of > > records or IPFIX Messages for subsequent export using IPFIX, by > > applying mediation functions within one or more Intermediate > > Processes to a stream of records, or applying transport based > > mediation functions to IPFIX Messages. > > > > Does it make sense? > > > > Regards, > > Atsushi > > > > On Fri, 26 Jun 2009 18:25:04 +0200 > > Benoit Claise wrote: > > > >> Dear all, > >> > >> I'm trying to summarize the long email thread. Not easy, there are some > >> diverging opinions. I hope I haven't forgotten anything > >> Below is the terminology proposal, based on Brian's proposal, improved > >> by Gerhard, and everybody. > >> > >> 2. Terminology and Definitions > >> > >> The terms in this section are in line with those in the IPFIX > >> Protocol specifications [RFC5101] and the PSAMP specification > >> document [RFC5476]. The terms Observation Point, Observation Domain, > >> Flow Key, Flow Record, Data Record, Exporting Process, Exporter, > >> IPFIX Device, Collecting Process, Collector, IPFIX Message, Metering > >> Process, Transport Session, Information Element, and Template > >> Withdrawal Message, are defined in the IPFIX protocol specifications > >> [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP > >> Device, and Configured Selection Fraction are defined in the PSAMP > >> specification document [RFC5476]. Furthermore, new terminology to be > >> used in the context of IPFIX Mediation is defined in this section. > >> All these terms have an initial capital letter in this document. > >> > >> In this document, we use the generic term "Data Records" for IPFIX > >> Flow Records, PSAMP Packet Reports, Data Records defined by Options > >> Templates, unless an explicit distinction is required. > >> > >> Original Exporter > >> > >> Original Exporter is an IPFIX Device that hosts the Observation > >> Points where the metered IP packets are observed. > >> > >> IPFIX Mediation > >> > >> IPFIX Mediation describes the manipulation and conversion of records > >> for subsequent export using IPFIX, by applying mediation functions > >> within one or more Intermediate Processes to a stream of records in > >> an IPFIX Mediator. > >> > >> The following terms are used in this document to describe the > >> architectural entities used by IPFIX Mediation. > >> > >> Intermediate Process > >> > >> An Intermediate Process takes a sequence of records from a Collecting > >> Process, Metering Process, IPFIX File Reader, or another Intermediate > >> Process within a Mediator; performs some transformation on these > >> records > >> based upon the content of the records themselves, state kept across > >> multiple records, configuration parameters, or other data; and passes > >> a sequence of transformed records on to an Exporting Process, > >> IPFIX File > >> Writer, or another Intermediate Process within a Mediator. This > >> document > >> describes specific Intermediate Processes below used in the > >> elaboration > >> of the problem statement; however, this is not an exhaustive list. > >> > >> Intermediate Aggregation Process > >> > >> An Intermediate Aggregation Process is an Intermediate Process that > >> aggregates records based upon a set of Flow Keys, or functions > >> applied to fields from the record (e.g. binning, subnet aggregation). > >> > >> Intermediate Correlation Process > >> > >> An Intermediate Correlation Process is an Intermediate Process > >> which adds information to records noting correlations among them, > >> or generates new records with correlated data from multiple > >> records (e.g. the production of bidirectional flow records from > >> unidirectional flow records). > >> > >> Intermediate Selection Process > >> > >> An Intermediate Selection Process is an Intermediate Process that > >> selects records from a sequence based upon criteria evaluated > >> record values, and passes only those records that match the > >> criteria (e.g. filtering only records from a given network to a > >> given Collector). > >> > >> Intermediate Anonymisation Process > >> > >> An Intermediate Anonymisation Process is an Intermediate Process > >> that transforms records in order to anonymise them, to protect the > >> identity of the entities described by the records (e.g. by > >> applying prefix-preserving pseudonymisation of IP addresses). > >> > >> IPFIX Mediator > >> > >> An IPFIX Mediator is an IPFIX Device that provides mediation > >> capabilities by receiving records from some data source, hosting > >> zero or more Intermediate Processes to transform those records, > >> and exporting those records in IPFIX Messages via an Exporting > >> Process. In the common case, a Mediator receives records from a > >> Collecting Process, but could also receive records from data > >> sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > >> protocol translation. Specific types of Mediators are defined > >> below; some of these reference original mediation capabilities > >> defined in earlier IPFIX documens before the elaboration of the > >> Mediator problem statement. > >> > >> Original Exporter > >> > >> Original Exporter is an IPFIX Device that hosts the Observation > >> Points where the metered IP packets are observed. > >> > >> IPFIX Proxy > >> > >> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX > >> Messages or messages in other protocols to one or more Collectors. > >> It can provide transport protocol mediation and re-encoding. > >> > >> IPFIX Concentrator > >> > >> An IPFIX Concentrator is an IPFIX Mediator that recieves data from > >> one or more Exporters and sends them to a single Collector, > >> optionally transforming the records using zero or more > >> Intermediate Processes on the way. > >> > >> IPFIX Distributor > >> > >> An IPFIX Distributor is an IPFIX Mediator that recieves data from > >> one or more Exporters and sends them to one or more Collectors, > >> deciding which Collector(s) to send each record to based upon the > >> decision of an Intermediate Selection Process. > >> > >> IPFIX Masquerading Proxy > >> > >> An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves > >> data from one or more Exporters and sends them to a single > >> Collector, using one or more Intermediate Aggregation Functions > >> and Intermediate Anonymisation Functions to screen out parts of > >> records according to configured policies, in order to protect the > >> privacy of the network's end users or senstive data of the > >> exporting organization. > >> > >> > >> I think that we agree that the same terminology sections in both the > >> problem statement and framework. > >> Personally, I'm not sure (yet) if we need the Intermediate > >> Aggregation/Correlation/Selection/Anonynisation Process. > >> However, if we do, my proposal is to omit this list from the problem > >> statement, and to simply put them in the framework. > >> > >> Please let us know, so that we can move forward with the drafts, both > >> the problem statements and the framework. > >> > >> Regards, Benoit. > >> From muenz@net.in.tum.de Tue Jul 7 03:20:56 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4833A6810 for ; Tue, 7 Jul 2009 03:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXNRdgpQ0ZFg for ; Tue, 7 Jul 2009 03:20:55 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id A6C233A6E31 for ; Tue, 7 Jul 2009 03:20:54 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 6FAC2481D8; Tue, 7 Jul 2009 12:20:36 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 548943F04; Tue, 7 Jul 2009 12:20:36 +0200 (CEST) Message-ID: <4A5321DD.8030902@net.in.tum.de> Date: Tue, 07 Jul 2009 12:22:21 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20090707010123.827D.17391CF2@nttv6.net> <4A524B74.40301@net.in.tum.de> <20090707065723.8280.17391CF2@nttv6.net> In-Reply-To: <20090707065723.8280.17391CF2@nttv6.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060400090804030002040105" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 10:20:56 -0000 This is a cryptographically signed message in MIME format. --------------ms060400090804030002040105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Atsushi, Current consensus is: IPFIX Mediation IPFIX Mediation describes the manipulation and conversion of records for subsequent export using IPFIX, by applying mediation functions within one or more Intermediate Processes to a stream of records in an IPFIX Mediator. IPFIX Mediator An IPFIX Mediator is an IPFIX Device that provides mediation capabilities by receiving records from some data source, hosting zero or more Intermediate Processes to transform those records, and exporting those records in IPFIX Messages via an Exporting Process. In the common case, a Mediator receives records from a Collecting Process, but could also receive records from data sources not encoded using IPFIX, e.g., in the case of NetFlow V9 protocol translation. You and me agree that this fits for conversion of NetFlow to IPFIX. So, where is the problem? You can forget about the details in the figure of RFC3917. If you believe in them, there would not be any Intermediate Process at all, just Metering Processes! > Actually, I thought same thing that the protocol converter needs Interm= ediate > Process converting IE and/or creating subsidiary information (e.g. Flow= > Key map and sampling parameter) in form of Data Records. But, it can > done in Exporting Process forming IPFIX Message, too. The Exporting Process forms IPFIX Messages, but would not convert any Templates or Records. > While reading twice in mailing list, I assumed that we will adopt case > 1 through long discussion. But, I don't adhere case 1, I would like to > get the consensus to progress to next stage. As far as I see, current consensus are the definitions above. If you propose a change, I do not see that we have already reached consensus. BTW, I assume that an IP implementing a conversion function is needed anyway. For example, if you want to aggregate records from different NetFlow Versions, I assume that you first convert all of them to IPFIX Data Records, such that the Intermediate Aggregation Process only has to process IPFIX records. At least, this is how we will implement it. Regards, Gerhard Atsushi Kobayashi wrote: > Hi Gerhard, >=20 >> Having an Intermediate Process, it fits into the current definition of= >> IPFIX Mediation :) >=20 > I would like to discuss your points. > We can choose the two ways: >=20 > 1) Transport mediation does not need Intermediate Process, content > mediation needs one or more Intermediate Process. >=20 > We can consider the following IPFIX-related Devices in RFC3917 as IPFIX= > Mediation. >=20 > +---+ +---+ +---+ > | E-+-> | E-+-> | E-+------------->---+ > | | | | | | | | | +---+ +-+-----+ > +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> > | | | | | | | | | | +---+ +-+-----+ > +-+-+ +-+-+ | O | | M | | E-+->---+ > | | | | +---+ | | | | | | > | M | +-+-+ | O | | M | > | | | | | | +---+ | | | +-----+ > | O | | O | | O | ->-+-C-E-+-> > +---+ +---+ +---+ +-----+ >=20 > Protocol Remote Concentrator Proxy > Converter Observation >=20 > Figure 2: IPFIX-related Devices >=20 > In case of conversion NetFlow to IPFIX, the protocol converter hosts a > Exporting process only. >=20 > 2) All of IPFIX Mediation has one or more Intermediate Process whether > transport mediation or content mediation. >=20 > In case of protocol converter, IPFIX Mediation has Intermediate > Conversion Process as you suggested. And in case of IPFIX Proxy, we hav= e > to consider some Intermediate Foo Process. Although the definition is > not consistent with RFC3917, it is not important in it. >=20 > Gerhard, which one do you prefer?=20 >=20 > Actually, I thought same thing that the protocol converter needs Interm= ediate > Process converting IE and/or creating subsidiary information (e.g. Flow= > Key map and sampling parameter) in form of Data Records. But, it can > done in Exporting Process forming IPFIX Message, too. >=20 > While reading twice in mailing list, I assumed that we will adopt case > 1 through long discussion. But, I don't adhere case 1, I would like to > get the consensus to progress to next stage. >=20 > Regards, > Atsushi >=20 > On Mon, 06 Jul 2009 21:07:32 +0200 > Gerhard Muenz wrote: >=20 >> Atsushi, >> >> What is the motivation for this change? >> Is it the use case of translating NetFlow into IPFIX? >> >> I assume that in most of the cases this translation cannot be done by >> just copying Records from a NetFlow Packet into an IPFIX Message. >> Typically, some small changes to the Template and Data Records are >> required (e.g., conversion of IE IDs), which would be done by an >> Intermediate Process. You can call it Intermediate Conversion Process.= >> >> Having an Intermediate Process, it fits into the current definition of= >> IPFIX Mediation :) >> >> Regards, >> Gerhard >> >> >> Atsushi Kobayashi wrote: >>> Dear Brian, Gerhard, Benoit and all, >>> >>> While writing next version IPFIX problem statement and framework draf= t, >>> I found the following discrepancy between IPFIX Mediation and IPFIX >>> Mediator. the term IPFIX Mediation implies that IPFIX Mediator hosts = one or >>> more Intermediate Processes. >>> >>> IPFIX Mediation >>> >>> IPFIX Mediation describes the manipulation and conversion of >>> records for subsequent export using IPFIX, by applying mediatio= n >>> functions within one or more Intermediate Processes to a stream= of >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> records in an IPFIX Mediator. >>> >>> IPFIX Mediator >>> >>> An IPFIX Mediator is an IPFIX Device that provides mediation >>> capabilities by receiving records from some data source, hostin= g >>> zero or more Intermediate Processes to transform those records,= >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> and exporting those records in IPFIX Messages via an Exporting >>> Process. In the common case, a Mediator receives records from = a >>> Collecting Process, but could also receive records from data >>> sources not encoded using IPFIX, e.g., in the case of NetFlow V= 9 >>> protocol translation. >>> >>> I'd like to propose the new term IPFIX Mediation as follows. >>> >>> IPFIX Mediation >>> >>> IPFIX Mediation describes the manipulation and conversion of >>> records or IPFIX Messages for subsequent export using IPFIX, by= >>> applying mediation functions within one or more Intermediate >>> Processes to a stream of records, or applying transport based=20 >>> mediation functions to IPFIX Messages. >>> >>> Does it make sense? >>> >>> Regards, >>> Atsushi >>> >>> On Fri, 26 Jun 2009 18:25:04 +0200 >>> Benoit Claise wrote: >>> >>>> Dear all, >>>> >>>> I'm trying to summarize the long email thread. Not easy, there are s= ome=20 >>>> diverging opinions. I hope I haven't forgotten anything >>>> Below is the terminology proposal, based on Brian's proposal, improv= ed=20 >>>> by Gerhard, and everybody. >>>> >>>> 2. Terminology and Definitions >>>> >>>> The terms in this section are in line with those in the IPFIX >>>> Protocol specifications [RFC5101] and the PSAMP specification >>>> document [RFC5476]. The terms Observation Point, Observation Dom= ain, >>>> Flow Key, Flow Record, Data Record, Exporting Process, Exporter, >>>> IPFIX Device, Collecting Process, Collector, IPFIX Message, Meter= ing >>>> Process, Transport Session, Information Element, and Template >>>> Withdrawal Message, are defined in the IPFIX protocol specificati= ons >>>> [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP >>>> Device, and Configured Selection Fraction are defined in the PSAM= P >>>> specification document [RFC5476]. Furthermore, new terminology t= o be >>>> used in the context of IPFIX Mediation is defined in this section= =2E >>>> All these terms have an initial capital letter in this document. >>>> >>>> In this document, we use the generic term "Data Records" for IPFI= X >>>> Flow Records, PSAMP Packet Reports, Data Records defined by Optio= ns >>>> Templates, unless an explicit distinction is required. >>>> >>>> Original Exporter >>>> >>>> Original Exporter is an IPFIX Device that hosts the Observatio= n >>>> Points where the metered IP packets are observed. >>>> >>>> IPFIX Mediation =20 >>>> >>>> IPFIX Mediation describes the manipulation and conversion of r= ecords >>>> for subsequent export using IPFIX, by applying mediation funct= ions >>>> within one or more Intermediate Processes to a stream of recor= ds in >>>> an IPFIX Mediator. >>>> =20 >>>> The following terms are used in this document to describe the >>>> architectural entities used by IPFIX Mediation. >>>> >>>> Intermediate Process >>>> >>>> An Intermediate Process takes a sequence of records from a Col= lecting >>>> Process, Metering Process, IPFIX File Reader, or another Inter= mediate >>>> Process within a Mediator; performs some transformation on the= se=20 >>>> records >>>> based upon the content of the records themselves, state kept a= cross >>>> multiple records, configuration parameters, or other data; and= passes >>>> a sequence of transformed records on to an Exporting Process, = >>>> IPFIX File >>>> Writer, or another Intermediate Process within a Mediator. Thi= s=20 >>>> document >>>> describes specific Intermediate Processes below used in the=20 >>>> elaboration >>>> of the problem statement; however, this is not an exhaustive l= ist. >>>> >>>> Intermediate Aggregation Process >>>> >>>> An Intermediate Aggregation Process is an Intermediate Process = that >>>> aggregates records based upon a set of Flow Keys, or functions >>>> applied to fields from the record (e.g. binning, subnet aggrega= tion). >>>> >>>> Intermediate Correlation Process >>>> >>>> An Intermediate Correlation Process is an Intermediate Process= >>>> which adds information to records noting correlations among th= em, >>>> or generates new records with correlated data from multiple >>>> records (e.g. the production of bidirectional flow records fro= m >>>> unidirectional flow records). >>>> >>>> Intermediate Selection Process >>>> >>>> An Intermediate Selection Process is an Intermediate Process t= hat >>>> selects records from a sequence based upon criteria evaluated >>>> record values, and passes only those records that match the >>>> criteria (e.g. filtering only records from a given network to = a >>>> given Collector). >>>> >>>> Intermediate Anonymisation Process >>>> >>>> An Intermediate Anonymisation Process is an Intermediate Proce= ss >>>> that transforms records in order to anonymise them, to protect= the >>>> identity of the entities described by the records (e.g. by >>>> applying prefix-preserving pseudonymisation of IP addresses). >>>> >>>> IPFIX Mediator >>>> >>>> An IPFIX Mediator is an IPFIX Device that provides mediation >>>> capabilities by receiving records from some data source, hosti= ng >>>> zero or more Intermediate Processes to transform those records= , >>>> and exporting those records in IPFIX Messages via an Exporting= >>>> Process. In the common case, a Mediator receives records from= a >>>> Collecting Process, but could also receive records from data >>>> sources not encoded using IPFIX, e.g., in the case of NetFlow = V9 >>>> protocol translation. Specific types of Mediators are defined= >>>> below; some of these reference original mediation capabilities= >>>> defined in earlier IPFIX documens before the elaboration of th= e >>>> Mediator problem statement. >>>> >>>> Original Exporter >>>> >>>> Original Exporter is an IPFIX Device that hosts the Observatio= n >>>> Points where the metered IP packets are observed. >>>> >>>> IPFIX Proxy >>>> >>>> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX= >>>> Messages or messages in other protocols to one or more Collect= ors. >>>> It can provide transport protocol mediation and re-encoding. >>>> >>>> IPFIX Concentrator >>>> >>>> An IPFIX Concentrator is an IPFIX Mediator that recieves data = from >>>> one or more Exporters and sends them to a single Collector, >>>> optionally transforming the records using zero or more >>>> Intermediate Processes on the way. >>>> >>>> IPFIX Distributor >>>> >>>> An IPFIX Distributor is an IPFIX Mediator that recieves data f= rom >>>> one or more Exporters and sends them to one or more Collectors= , >>>> deciding which Collector(s) to send each record to based upon = the >>>> decision of an Intermediate Selection Process. >>>> >>>> IPFIX Masquerading Proxy >>>> >>>> An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves= >>>> data from one or more Exporters and sends them to a single >>>> Collector, using one or more Intermediate Aggregation Function= s >>>> and Intermediate Anonymisation Functions to screen out parts o= f >>>> records according to configured policies, in order to protect = the >>>> privacy of the network's end users or senstive data of the >>>> exporting organization. >>>> >>>> >>>> I think that we agree that the same terminology sections in both the= =20 >>>> problem statement and framework. >>>> Personally, I'm not sure (yet) if we need the Intermediate=20 >>>> Aggregation/Correlation/Selection/Anonynisation Process. >>>> However, if we do, my proposal is to omit this list from the problem= =20 >>>> statement, and to simply put them in the framework. >>>> >>>> Please let us know, so that we can move forward with the drafts, bot= h=20 >>>> the problem statements and the framework. >>>> >>>> Regards, Benoit. >>>> >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms060400090804030002040105 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzA3MTAyMjIxWjAjBgkqhkiG9w0BCQQxFgQU f9Pzn1XX95EOTgggjV4ULVgV9dcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAIkgj+Dinh7CY0p4vFO1eaIYToqWaY9FcWQ3gXhOQfuckKpL U2hiS468OmwS2M/83u1CfkfnG5o30ytu6dUBH7s7pQLXz8C7LfM5MemwWqIFNO5rQTq1qgF4 cy9JqPH6/0Dt1WIRsxjxDv2JmRTPcmAokmwWTTCqDBrJpQgcghqzHYTWd35JOKgonQMLvMg0 0UgyVjLXvpI911M6HQJxEnbTqYgh57jjPfWSMoqUVWYIPHSQgoLqy28uagPqhnH9GrjYbG5D ak8LkZ5/V0Gy5R7X19qtjZGh7uYJCMoppg1xhZGn9Sz5U1f7pSeb9wfIAclwHtqX+qT0H3rB 6e6n9VIAAAAAAAA= --------------ms060400090804030002040105-- From root@core3.amsl.com Tue Jul 7 14:00:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EF37F3A6A18; Tue, 7 Jul 2009 14:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090707210001.EF37F3A6A18@core3.amsl.com> Date: Tue, 7 Jul 2009 14:00:01 -0700 (PDT) Cc: n.brownlee@auckland.ac.nz, ipfix@ietf.org, quittek@netlab.nec.de Subject: [IPFIX] WG Action: RECHARTER: IP Flow Information Export (ipfix) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 21:00:02 -0000 The IP Flow Information Export (ipfix) working group in the Operations and Management Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. IP Flow Information Export (ipfix) ------------------------------- Last Modified: 2009-06-18 Additional information is available at tools.ietf.org/wg/ipfix Chair(s): Nevil Brownlee Juergen Quittek Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: ipfix@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix Archive: http://www.ietf.org/mail-archive/web/ipfix Description of Working Group: The IPFIX working group has specified the Information Model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). Several implementers have already built applications using the IPFIX protocol. As a result of a series of IPFIX interoperability testing events the WG has produced guidelines for IPFIX implementation and testing as well as recommendations for handling special cases such as bidirectional flow reporting and reducing redundancy in flow records. Practical experiences with IPFIX implementations exposed new requirements for the IPFIX protocol that so far have not been addressed by the WG. The major current goal of the WG is developing solutions that meet the new requirements without modifying the core IPFIX protocol specifications. 1. The IPFIX WG has developed a MIB module for monitoring IPFIX implementations. Means for configuring these devices have not been standardized yet. The WG will develop an XML-based configuration data model that can be used for configuring IPFIX devices and for storing, modifying and managing IPFIX configurations parameter sets. This work will be performed in close collaboration with the NETCONF WG. 2. There is a need for storing measured flow information and for exchanging this information between different systems and organizations. The WG will develop a common IPFIX file format for storing flow data in order to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. It will be a flat-file format using binary encodings that are based on the IPFIX message format. 3. When dealing with enterprise-specific information elements in IPFIX flow records, it often occurs that the receiver of the record does not know the definition of the information element. For processing such information elements it would be desirable for the receiver to know at least the data types of the enterprise-specific information elements. The WG will develop an extension to IPFIX that provides means for the encoding of IPFIX data type information within an IPFIX Message stream. 4. Another requirement resulting from practical use of IPFIX is reporting IPFIX template records and corresponding data records within the same SCTP stream. The IPFIX WG will develop guidelines for this use case. 5. First applications of IPFIX at large operator networks showed the need for mediation of flow information, for example, for aggregating huge amounts of flow data and for anomymization of flow information. The IPFIX WG will investigate this issue and produce a problem statement and a framework for IPFIX flow mediation. 6. The PSAMP WG has developed a protocol for reporting observed packets. The PSAMP protocol is an extension of the IPFIX protocol. The IPFIX WG will develop a MIB module for monitoring PSAMP implementations. The new MIB module will be an extension of the IPFIX MIB module. Goals and Milestones: Done Submit Revised Internet-Draft on IP Flow Export Requirements Done Submit Internet-Draft on IP Flow Export Architecture Done Submit Internet-Draft on IP Flow Export Data Model Done Submit Internet-Draft on IPFIX Protocol Evaluation Report Done Submit Internet-Draft on IP Flow Export Applicability Statement Done Select IPFIX protocol, revise Architecture and Data Model drafts Done Submit IPFX-REQUIREMENTS to IESG for publication as Informational RFC Done Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC Done Submit IPFX-ARCHITECTURE to IESG for publication as Proposed Standard RFC Done Submit IPFX-INFO_MODEL to IESG for publication as Informational RFC Done Submit IPFX-APPLICABILITY to IESG for publication as Informational RFC Done Submit IPFX-PROTOCOL to IESG for publication as Proposed Standard RFC Done Publish Internet Draft on IPFIX Implementation Guidelines Done Publish Internet Draft on Reducing Redundancy in IPFIX data transfer Done Publish Internet Draft on Handling IPFIX Bidirectional Flows Done Publish Internet Draft on IPFIX Testing Done Publish Internet Draft on IPFIX MIB Done Submit IPFIX Implementation Guidelines draft to IESG for publication as Informational RFC Done Submit IPFIX Reducing Redundancy draft to IESG for publication as Informational RFC Done Submit IPFIX Testing draft to IESG for publication as Informational RFC Done Submit IPFIX Biflows draft to IESG for publication as Standards Track RFC Done Publish Internet draft on IPFIX Type Information Export Done Publish Internet draft on IPFIX File Format Done Publish Internet draft on IPFIX Configuration Data Model Done Publish Internet draft on Single SCTP Stream Reporting Done Submit File Format draft to IESG for publication as Standards track RFC Done Publish Internet draft on IPFIX Mediation Problem Statement Done Submit IPFIX MIB draft to IESG for publication as Standards track RFC Done Submit Type Export draft to IESG for publication as Standards track RFC Done Submit Single SCTP Stream draft to IESG for publication as Informational RFC Sep 2009 Submit Configuration Data Model draft to IESG for publication as Standards track RFC Jul 2009 Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC Sep 2009 Submit Mediation Framework I-D to IESG for publication as Informational RFC Jan 2010 Submit final version of PSAMP MIB module From akoba@nttv6.net Tue Jul 7 16:18:32 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF4E3A67E7 for ; Tue, 7 Jul 2009 16:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaOf45k0ks+i for ; Tue, 7 Jul 2009 16:18:30 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id B79B93A6A66 for ; Tue, 7 Jul 2009 16:18:29 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:10b6:53c9:1312:c4da]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n67NInNh068206; Wed, 8 Jul 2009 08:18:52 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 08 Jul 2009 08:14:34 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4A5321DD.8030902@net.in.tum.de> References: <20090707065723.8280.17391CF2@nttv6.net> <4A5321DD.8030902@net.in.tum.de> Message-Id: <20090708072133.829F.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Wed, 08 Jul 2009 08:18:52 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 23:18:32 -0000 Hi Gerhard, On Tue, 07 Jul 2009 12:22:21 +0200 Gerhard Muenz wrote: > > Hi Atsushi, > > Current consensus is: > > IPFIX Mediation > > IPFIX Mediation describes the manipulation and conversion of > records for subsequent export using IPFIX, by applying mediation > functions within one or more Intermediate Processes to a stream of > records in an IPFIX Mediator. > > IPFIX Mediator > > An IPFIX Mediator is an IPFIX Device that provides mediation > capabilities by receiving records from some data source, hosting > zero or more Intermediate Processes to transform those records, > and exporting those records in IPFIX Messages via an Exporting > Process. In the common case, a Mediator receives records from a > Collecting Process, but could also receive records from data > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > protocol translation. > > You and me agree that this fits for conversion of NetFlow to IPFIX. > So, where is the problem? IPFIX Mediation covers the manipulation of records, and needs at least single Intermediate Process. On the other hand, IPFIX Mediator doesnot need Intermediate Process while manipulation of IPFIX Messages. In the definition, the protocol conversion from NetFlow to IPFIX can be executed in IPFIX Mediator, but it does not seem IPFIX Mediation, and also changing transport protocol carrying IPFIX Messages (e.g. from UDP to SCTP) can be executed in IPFIX Mediator, but it does not seem IPFIX Mediation. Because RFC3917 already described that the above functions can be done by Exporting Process and/or Collecting Process only, such as protocol converter, and proxy. These functions do not seem to need Intermediate Process. Or do you mean that the above functions need another Intermediate Process? One is Intermediate Conversion Process? Which Intermediate Process do change transport protocol? Could you please elaborate your idea? BTW, Brian proposed the term IPFIX Mediation, as follows. Where is the problem in your idea? IPFIX Mediation IPFIX Mediation is the manipulation and conversion of records or IPFIX Messages for subsequent export using IPFIX, by applying mediation functions to a stream of records, and/or applying transport based mediation functions to IPFIX Messages. I think the current discussion is the level of framework rather than problem statement. The above term is fine for us regardless of the result of the discussion. Regards, Atsushi > > You can forget about the details in the figure of RFC3917. If you > believe in them, there would not be any Intermediate Process at all, > just Metering Processes! > > > Actually, I thought same thing that the protocol converter needs Intermediate > > Process converting IE and/or creating subsidiary information (e.g. Flow > > Key map and sampling parameter) in form of Data Records. But, it can > > done in Exporting Process forming IPFIX Message, too. > > The Exporting Process forms IPFIX Messages, but would not convert any > Templates or Records. > > > While reading twice in mailing list, I assumed that we will adopt case > > 1 through long discussion. But, I don't adhere case 1, I would like to > > get the consensus to progress to next stage. > > As far as I see, current consensus are the definitions above. If you > propose a change, I do not see that we have already reached consensus. > > BTW, I assume that an IP implementing a conversion function is needed > anyway. For example, if you want to aggregate records from different > NetFlow Versions, I assume that you first convert all of them to IPFIX > Data Records, such that the Intermediate Aggregation Process only has to > process IPFIX records. At least, this is how we will implement it. > > Regards, > Gerhard > > > Atsushi Kobayashi wrote: > > Hi Gerhard, > > > >> Having an Intermediate Process, it fits into the current definition of > >> IPFIX Mediation :) > > > > I would like to discuss your points. > > We can choose the two ways: > > > > 1) Transport mediation does not need Intermediate Process, content > > mediation needs one or more Intermediate Process. > > > > We can consider the following IPFIX-related Devices in RFC3917 as IPFIX > > Mediation. > > > > +---+ +---+ +---+ > > | E-+-> | E-+-> | E-+------------->---+ > > | | | | | | | | | +---+ +-+-----+ > > +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> > > | | | | | | | | | | +---+ +-+-----+ > > +-+-+ +-+-+ | O | | M | | E-+->---+ > > | | | | +---+ | | | | | | > > | M | +-+-+ | O | | M | > > | | | | | | +---+ | | | +-----+ > > | O | | O | | O | ->-+-C-E-+-> > > +---+ +---+ +---+ +-----+ > > > > Protocol Remote Concentrator Proxy > > Converter Observation > > > > Figure 2: IPFIX-related Devices > > > > In case of conversion NetFlow to IPFIX, the protocol converter hosts a > > Exporting process only. > > > > 2) All of IPFIX Mediation has one or more Intermediate Process whether > > transport mediation or content mediation. > > > > In case of protocol converter, IPFIX Mediation has Intermediate > > Conversion Process as you suggested. And in case of IPFIX Proxy, we have > > to consider some Intermediate Foo Process. Although the definition is > > not consistent with RFC3917, it is not important in it. > > > > Gerhard, which one do you prefer? > > > > Actually, I thought same thing that the protocol converter needs Intermediate > > Process converting IE and/or creating subsidiary information (e.g. Flow > > Key map and sampling parameter) in form of Data Records. But, it can > > done in Exporting Process forming IPFIX Message, too. > > > > While reading twice in mailing list, I assumed that we will adopt case > > 1 through long discussion. But, I don't adhere case 1, I would like to > > get the consensus to progress to next stage. > > > > Regards, > > Atsushi > > > > On Mon, 06 Jul 2009 21:07:32 +0200 > > Gerhard Muenz wrote: > > > >> Atsushi, > >> > >> What is the motivation for this change? > >> Is it the use case of translating NetFlow into IPFIX? > >> > >> I assume that in most of the cases this translation cannot be done by > >> just copying Records from a NetFlow Packet into an IPFIX Message. > >> Typically, some small changes to the Template and Data Records are > >> required (e.g., conversion of IE IDs), which would be done by an > >> Intermediate Process. You can call it Intermediate Conversion Process. > >> > >> Having an Intermediate Process, it fits into the current definition of > >> IPFIX Mediation :) > >> > >> Regards, > >> Gerhard > >> > >> > >> Atsushi Kobayashi wrote: > >>> Dear Brian, Gerhard, Benoit and all, > >>> > >>> While writing next version IPFIX problem statement and framework draft, > >>> I found the following discrepancy between IPFIX Mediation and IPFIX > >>> Mediator. the term IPFIX Mediation implies that IPFIX Mediator hosts one or > >>> more Intermediate Processes. > >>> > >>> IPFIX Mediation > >>> > >>> IPFIX Mediation describes the manipulation and conversion of > >>> records for subsequent export using IPFIX, by applying mediation > >>> functions within one or more Intermediate Processes to a stream of > >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> records in an IPFIX Mediator. > >>> > >>> IPFIX Mediator > >>> > >>> An IPFIX Mediator is an IPFIX Device that provides mediation > >>> capabilities by receiving records from some data source, hosting > >>> zero or more Intermediate Processes to transform those records, > >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> and exporting those records in IPFIX Messages via an Exporting > >>> Process. In the common case, a Mediator receives records from a > >>> Collecting Process, but could also receive records from data > >>> sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > >>> protocol translation. > >>> > >>> I'd like to propose the new term IPFIX Mediation as follows. > >>> > >>> IPFIX Mediation > >>> > >>> IPFIX Mediation describes the manipulation and conversion of > >>> records or IPFIX Messages for subsequent export using IPFIX, by > >>> applying mediation functions within one or more Intermediate > >>> Processes to a stream of records, or applying transport based > >>> mediation functions to IPFIX Messages. > >>> > >>> Does it make sense? > >>> > >>> Regards, > >>> Atsushi > >>> > >>> On Fri, 26 Jun 2009 18:25:04 +0200 > >>> Benoit Claise wrote: > >>> > >>>> Dear all, > >>>> > >>>> I'm trying to summarize the long email thread. Not easy, there are some > >>>> diverging opinions. I hope I haven't forgotten anything > >>>> Below is the terminology proposal, based on Brian's proposal, improved > >>>> by Gerhard, and everybody. > >>>> > >>>> 2. Terminology and Definitions > >>>> > >>>> The terms in this section are in line with those in the IPFIX > >>>> Protocol specifications [RFC5101] and the PSAMP specification > >>>> document [RFC5476]. The terms Observation Point, Observation Domain, > >>>> Flow Key, Flow Record, Data Record, Exporting Process, Exporter, > >>>> IPFIX Device, Collecting Process, Collector, IPFIX Message, Metering > >>>> Process, Transport Session, Information Element, and Template > >>>> Withdrawal Message, are defined in the IPFIX protocol specifications > >>>> [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP > >>>> Device, and Configured Selection Fraction are defined in the PSAMP > >>>> specification document [RFC5476]. Furthermore, new terminology to be > >>>> used in the context of IPFIX Mediation is defined in this section. > >>>> All these terms have an initial capital letter in this document. > >>>> > >>>> In this document, we use the generic term "Data Records" for IPFIX > >>>> Flow Records, PSAMP Packet Reports, Data Records defined by Options > >>>> Templates, unless an explicit distinction is required. > >>>> > >>>> Original Exporter > >>>> > >>>> Original Exporter is an IPFIX Device that hosts the Observation > >>>> Points where the metered IP packets are observed. > >>>> > >>>> IPFIX Mediation > >>>> > >>>> IPFIX Mediation describes the manipulation and conversion of records > >>>> for subsequent export using IPFIX, by applying mediation functions > >>>> within one or more Intermediate Processes to a stream of records in > >>>> an IPFIX Mediator. > >>>> > >>>> The following terms are used in this document to describe the > >>>> architectural entities used by IPFIX Mediation. > >>>> > >>>> Intermediate Process > >>>> > >>>> An Intermediate Process takes a sequence of records from a Collecting > >>>> Process, Metering Process, IPFIX File Reader, or another Intermediate > >>>> Process within a Mediator; performs some transformation on these > >>>> records > >>>> based upon the content of the records themselves, state kept across > >>>> multiple records, configuration parameters, or other data; and passes > >>>> a sequence of transformed records on to an Exporting Process, > >>>> IPFIX File > >>>> Writer, or another Intermediate Process within a Mediator. This > >>>> document > >>>> describes specific Intermediate Processes below used in the > >>>> elaboration > >>>> of the problem statement; however, this is not an exhaustive list. > >>>> > >>>> Intermediate Aggregation Process > >>>> > >>>> An Intermediate Aggregation Process is an Intermediate Process that > >>>> aggregates records based upon a set of Flow Keys, or functions > >>>> applied to fields from the record (e.g. binning, subnet aggregation). > >>>> > >>>> Intermediate Correlation Process > >>>> > >>>> An Intermediate Correlation Process is an Intermediate Process > >>>> which adds information to records noting correlations among them, > >>>> or generates new records with correlated data from multiple > >>>> records (e.g. the production of bidirectional flow records from > >>>> unidirectional flow records). > >>>> > >>>> Intermediate Selection Process > >>>> > >>>> An Intermediate Selection Process is an Intermediate Process that > >>>> selects records from a sequence based upon criteria evaluated > >>>> record values, and passes only those records that match the > >>>> criteria (e.g. filtering only records from a given network to a > >>>> given Collector). > >>>> > >>>> Intermediate Anonymisation Process > >>>> > >>>> An Intermediate Anonymisation Process is an Intermediate Process > >>>> that transforms records in order to anonymise them, to protect the > >>>> identity of the entities described by the records (e.g. by > >>>> applying prefix-preserving pseudonymisation of IP addresses). > >>>> > >>>> IPFIX Mediator > >>>> > >>>> An IPFIX Mediator is an IPFIX Device that provides mediation > >>>> capabilities by receiving records from some data source, hosting > >>>> zero or more Intermediate Processes to transform those records, > >>>> and exporting those records in IPFIX Messages via an Exporting > >>>> Process. In the common case, a Mediator receives records from a > >>>> Collecting Process, but could also receive records from data > >>>> sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > >>>> protocol translation. Specific types of Mediators are defined > >>>> below; some of these reference original mediation capabilities > >>>> defined in earlier IPFIX documens before the elaboration of the > >>>> Mediator problem statement. > >>>> > >>>> Original Exporter > >>>> > >>>> Original Exporter is an IPFIX Device that hosts the Observation > >>>> Points where the metered IP packets are observed. > >>>> > >>>> IPFIX Proxy > >>>> > >>>> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX > >>>> Messages or messages in other protocols to one or more Collectors. > >>>> It can provide transport protocol mediation and re-encoding. > >>>> > >>>> IPFIX Concentrator > >>>> > >>>> An IPFIX Concentrator is an IPFIX Mediator that recieves data from > >>>> one or more Exporters and sends them to a single Collector, > >>>> optionally transforming the records using zero or more > >>>> Intermediate Processes on the way. > >>>> > >>>> IPFIX Distributor > >>>> > >>>> An IPFIX Distributor is an IPFIX Mediator that recieves data from > >>>> one or more Exporters and sends them to one or more Collectors, > >>>> deciding which Collector(s) to send each record to based upon the > >>>> decision of an Intermediate Selection Process. > >>>> > >>>> IPFIX Masquerading Proxy > >>>> > >>>> An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves > >>>> data from one or more Exporters and sends them to a single > >>>> Collector, using one or more Intermediate Aggregation Functions > >>>> and Intermediate Anonymisation Functions to screen out parts of > >>>> records according to configured policies, in order to protect the > >>>> privacy of the network's end users or senstive data of the > >>>> exporting organization. > >>>> > >>>> > >>>> I think that we agree that the same terminology sections in both the > >>>> problem statement and framework. > >>>> Personally, I'm not sure (yet) if we need the Intermediate > >>>> Aggregation/Correlation/Selection/Anonynisation Process. > >>>> However, if we do, my proposal is to omit this list from the problem > >>>> statement, and to simply put them in the framework. > >>>> > >>>> Please let us know, so that we can move forward with the drafts, both > >>>> the problem statements and the framework. > >>>> > >>>> Regards, Benoit. > >>>> > > From muenz@net.in.tum.de Wed Jul 8 05:12:03 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B743A6F35 for ; Wed, 8 Jul 2009 05:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlDJvuqKplib for ; Wed, 8 Jul 2009 05:12:01 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id D30453A6894 for ; Wed, 8 Jul 2009 05:12:00 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id F146347D26; Wed, 8 Jul 2009 14:10:58 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id CE44BA24; Wed, 8 Jul 2009 14:10:58 +0200 (CEST) Message-ID: <4A548D3C.7030801@net.in.tum.de> Date: Wed, 08 Jul 2009 14:12:44 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20090707065723.8280.17391CF2@nttv6.net> <4A5321DD.8030902@net.in.tum.de> <20090708072133.829F.17391CF2@nttv6.net> In-Reply-To: <20090708072133.829F.17391CF2@nttv6.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090604010703050408030602" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 12:12:03 -0000 This is a cryptographically signed message in MIME format. --------------ms090604010703050408030602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Atsushi, Atsushi Kobayashi wrote: > Hi Gerhard, >=20 > On Tue, 07 Jul 2009 12:22:21 +0200 > Gerhard Muenz wrote: >=20 >> Hi Atsushi, >> >> Current consensus is: >> >> IPFIX Mediation >> >> IPFIX Mediation describes the manipulation and conversion of >> records for subsequent export using IPFIX, by applying mediation= >> functions within one or more Intermediate Processes to a stream = of >> records in an IPFIX Mediator. >> >> IPFIX Mediator >> >> An IPFIX Mediator is an IPFIX Device that provides mediation >> capabilities by receiving records from some data source, hosting= >> zero or more Intermediate Processes to transform those records, >> and exporting those records in IPFIX Messages via an Exporting >> Process. In the common case, a Mediator receives records from a= >> Collecting Process, but could also receive records from data >> sources not encoded using IPFIX, e.g., in the case of NetFlow V9= >> protocol translation. >> >> You and me agree that this fits for conversion of NetFlow to IPFIX. >> So, where is the problem? >=20 > IPFIX Mediation covers the manipulation of records, and needs at least > single Intermediate Process. On the other hand, IPFIX Mediator doesnot > need Intermediate Process while manipulation of IPFIX Messages. > > In the definition, the protocol conversion from NetFlow to IPFIX can > be executed in IPFIX Mediator, but it does not seem IPFIX Mediation,=20 IMO, this is IPFIX Mediation because an Intermediate Process converts NetFlow records into IPFIX records. > and > also changing transport protocol carrying IPFIX Messages (e.g. from UDP= > to SCTP) can be executed in IPFIX Mediator, but it does not seem IPFIX > Mediation. Yes, in this corner case, you do not really need an Intermediate Process. However, you could also say that you have a transparent Intermediate Process which does not do anything to the stream of records.= > Because RFC3917 already described that the above functions can be done = by > Exporting Process and/or Collecting Process only, such as protocol > converter, and proxy. These functions do not seem to need Intermediate > Process. >=20 > Or do you mean that the above functions need another Intermediate > Process? One is Intermediate Conversion Process? Which Intermediate > Process do change transport protocol? >=20 > Could you please elaborate your idea? Current terminology is: IPFIX Mediation: ...one or more Intermediate Processes... IPFIX Mediator: ...zero or more Intermediate Processes... Benoit chose the different numbers because IPFIX Proxy without Intermediate Process should be covered by IPFIX Mediator. That's ok with = me. If you want to equalize the specified numbers of IPs, you can either change the definition of IPFIX Mediation (as you propose): IPFIX Mediation: ... *zero* or more Intermediate Processes... (or omit mentioning IPs) IPFIX Mediator: ...zero or more Intermediate Processes... Or you change the definition of IPFIX Mediator: IPFIX Mediation: ...one or more Intermediate Processes... IPFIX Mediator: ... *one* or more Intermediate Processes... If you want to change the definitions, I prefer the second option over the first one. However, I would not object to the first one if you think that this makes more sense. > BTW, Brian proposed the term IPFIX Mediation, as follows. Where is > the problem in your idea? >=20 > IPFIX Mediation >=20 > IPFIX Mediation is the manipulation and conversion of > records or IPFIX Messages for subsequent export using IPFIX, > by applying mediation functions to a stream of records, and/or > applying transport based mediation functions to IPFIX Messages. The old definition was simple and clear. The new definition causes confusion because it introduces two types of mediation functions: - "mediation functions" - "transport based mediation functions" You would have to explain the difference and probably introduce two more terms like "Record Mediation Function" and "Transport Based Mediation Function". Regards, Gerhard > I think the current discussion is the level of framework rather than > problem statement. The above term is fine for us regardless of the > result of the discussion. >=20 > Regards, > Atsushi >=20 >> You can forget about the details in the figure of RFC3917. If you >> believe in them, there would not be any Intermediate Process at all, >> just Metering Processes! >> >>> Actually, I thought same thing that the protocol converter needs Inte= rmediate >>> Process converting IE and/or creating subsidiary information (e.g. Fl= ow >>> Key map and sampling parameter) in form of Data Records. But, it can >>> done in Exporting Process forming IPFIX Message, too. >> The Exporting Process forms IPFIX Messages, but would not convert any >> Templates or Records. >> >>> While reading twice in mailing list, I assumed that we will adopt cas= e >>> 1 through long discussion. But, I don't adhere case 1, I would like t= o >>> get the consensus to progress to next stage. >> As far as I see, current consensus are the definitions above. If you >> propose a change, I do not see that we have already reached consensus.= >> >> BTW, I assume that an IP implementing a conversion function is needed >> anyway. For example, if you want to aggregate records from different >> NetFlow Versions, I assume that you first convert all of them to IPFIX= >> Data Records, such that the Intermediate Aggregation Process only has = to >> process IPFIX records. At least, this is how we will implement it. >> >> Regards, >> Gerhard >> >> >> Atsushi Kobayashi wrote: >>> Hi Gerhard, >>> >>>> Having an Intermediate Process, it fits into the current definition = of >>>> IPFIX Mediation :) >>> I would like to discuss your points. >>> We can choose the two ways: >>> >>> 1) Transport mediation does not need Intermediate Process, content >>> mediation needs one or more Intermediate Process. >>> >>> We can consider the following IPFIX-related Devices in RFC3917 as IPF= IX >>> Mediation. >>> >>> +---+ +---+ +---+ >>> | E-+-> | E-+-> | E-+------------->---+ >>> | | | | | | | | | +---+ +-+-----+ >>> +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> >>> | | | | | | | | | | +---+ +-+-----+ >>> +-+-+ +-+-+ | O | | M | | E-+->---+ >>> | | | | +---+ | | | | | | >>> | M | +-+-+ | O | | M | >>> | | | | | | +---+ | | | +-----+ >>> | O | | O | | O | ->-+-C-E-+-> >>> +---+ +---+ +---+ +-----+ >>> >>> Protocol Remote Concentrator Proxy >>> Converter Observation >>> >>> Figure 2: IPFIX-related Devices >>> >>> In case of conversion NetFlow to IPFIX, the protocol converter hosts = a >>> Exporting process only. >>> >>> 2) All of IPFIX Mediation has one or more Intermediate Process whethe= r >>> transport mediation or content mediation. >>> >>> In case of protocol converter, IPFIX Mediation has Intermediate >>> Conversion Process as you suggested. And in case of IPFIX Proxy, we h= ave >>> to consider some Intermediate Foo Process. Although the definition is= >>> not consistent with RFC3917, it is not important in it. >>> >>> Gerhard, which one do you prefer?=20 >>> >>> Actually, I thought same thing that the protocol converter needs Inte= rmediate >>> Process converting IE and/or creating subsidiary information (e.g. Fl= ow >>> Key map and sampling parameter) in form of Data Records. But, it can >>> done in Exporting Process forming IPFIX Message, too. >>> >>> While reading twice in mailing list, I assumed that we will adopt cas= e >>> 1 through long discussion. But, I don't adhere case 1, I would like t= o >>> get the consensus to progress to next stage. >>> >>> Regards, >>> Atsushi >>> >>> On Mon, 06 Jul 2009 21:07:32 +0200 >>> Gerhard Muenz wrote: >>> >>>> Atsushi, >>>> >>>> What is the motivation for this change? >>>> Is it the use case of translating NetFlow into IPFIX? >>>> >>>> I assume that in most of the cases this translation cannot be done b= y >>>> just copying Records from a NetFlow Packet into an IPFIX Message. >>>> Typically, some small changes to the Template and Data Records are >>>> required (e.g., conversion of IE IDs), which would be done by an >>>> Intermediate Process. You can call it Intermediate Conversion Proces= s. >>>> >>>> Having an Intermediate Process, it fits into the current definition = of >>>> IPFIX Mediation :) >>>> >>>> Regards, >>>> Gerhard >>>> >>>> >>>> Atsushi Kobayashi wrote: >>>>> Dear Brian, Gerhard, Benoit and all, >>>>> >>>>> While writing next version IPFIX problem statement and framework dr= aft, >>>>> I found the following discrepancy between IPFIX Mediation and IPFIX= >>>>> Mediator. the term IPFIX Mediation implies that IPFIX Mediator host= s one or >>>>> more Intermediate Processes. >>>>> >>>>> IPFIX Mediation >>>>> >>>>> IPFIX Mediation describes the manipulation and conversion of >>>>> records for subsequent export using IPFIX, by applying mediat= ion >>>>> functions within one or more Intermediate Processes to a stre= am of >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> records in an IPFIX Mediator. >>>>> >>>>> IPFIX Mediator >>>>> >>>>> An IPFIX Mediator is an IPFIX Device that provides mediation >>>>> capabilities by receiving records from some data source, host= ing >>>>> zero or more Intermediate Processes to transform those record= s, >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> and exporting those records in IPFIX Messages via an Exportin= g >>>>> Process. In the common case, a Mediator receives records fro= m a >>>>> Collecting Process, but could also receive records from data >>>>> sources not encoded using IPFIX, e.g., in the case of NetFlow= V9 >>>>> protocol translation. >>>>> >>>>> I'd like to propose the new term IPFIX Mediation as follows. >>>>> >>>>> IPFIX Mediation >>>>> >>>>> IPFIX Mediation describes the manipulation and conversion of >>>>> records or IPFIX Messages for subsequent export using IPFIX, = by >>>>> applying mediation functions within one or more Intermediate >>>>> Processes to a stream of records, or applying transport based= =20 >>>>> mediation functions to IPFIX Messages. >>>>> >>>>> Does it make sense? >>>>> >>>>> Regards, >>>>> Atsushi >>>>> >>>>> On Fri, 26 Jun 2009 18:25:04 +0200 >>>>> Benoit Claise wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> I'm trying to summarize the long email thread. Not easy, there are= some=20 >>>>>> diverging opinions. I hope I haven't forgotten anything >>>>>> Below is the terminology proposal, based on Brian's proposal, impr= oved=20 >>>>>> by Gerhard, and everybody. >>>>>> >>>>>> 2. Terminology and Definitions >>>>>> >>>>>> The terms in this section are in line with those in the IPFIX >>>>>> Protocol specifications [RFC5101] and the PSAMP specification >>>>>> document [RFC5476]. The terms Observation Point, Observation D= omain, >>>>>> Flow Key, Flow Record, Data Record, Exporting Process, Exporter= , >>>>>> IPFIX Device, Collecting Process, Collector, IPFIX Message, Met= ering >>>>>> Process, Transport Session, Information Element, and Template >>>>>> Withdrawal Message, are defined in the IPFIX protocol specifica= tions >>>>>> [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP= >>>>>> Device, and Configured Selection Fraction are defined in the PS= AMP >>>>>> specification document [RFC5476]. Furthermore, new terminology= to be >>>>>> used in the context of IPFIX Mediation is defined in this secti= on. >>>>>> All these terms have an initial capital letter in this document= =2E >>>>>> >>>>>> In this document, we use the generic term "Data Records" for IP= FIX >>>>>> Flow Records, PSAMP Packet Reports, Data Records defined by Opt= ions >>>>>> Templates, unless an explicit distinction is required. >>>>>> >>>>>> Original Exporter >>>>>> >>>>>> Original Exporter is an IPFIX Device that hosts the Observat= ion >>>>>> Points where the metered IP packets are observed. >>>>>> >>>>>> IPFIX Mediation =20 >>>>>> >>>>>> IPFIX Mediation describes the manipulation and conversion of= records >>>>>> for subsequent export using IPFIX, by applying mediation fun= ctions >>>>>> within one or more Intermediate Processes to a stream of rec= ords in >>>>>> an IPFIX Mediator. >>>>>> =20 >>>>>> The following terms are used in this document to describe the >>>>>> architectural entities used by IPFIX Mediation. >>>>>> >>>>>> Intermediate Process >>>>>> >>>>>> An Intermediate Process takes a sequence of records from a C= ollecting >>>>>> Process, Metering Process, IPFIX File Reader, or another Int= ermediate >>>>>> Process within a Mediator; performs some transformation on t= hese=20 >>>>>> records >>>>>> based upon the content of the records themselves, state kept= across >>>>>> multiple records, configuration parameters, or other data; a= nd passes >>>>>> a sequence of transformed records on to an Exporting Process= ,=20 >>>>>> IPFIX File >>>>>> Writer, or another Intermediate Process within a Mediator. T= his=20 >>>>>> document >>>>>> describes specific Intermediate Processes below used in the = >>>>>> elaboration >>>>>> of the problem statement; however, this is not an exhaustive= list. >>>>>> >>>>>> Intermediate Aggregation Process >>>>>> >>>>>> An Intermediate Aggregation Process is an Intermediate Proces= s that >>>>>> aggregates records based upon a set of Flow Keys, or function= s >>>>>> applied to fields from the record (e.g. binning, subnet aggre= gation). >>>>>> >>>>>> Intermediate Correlation Process >>>>>> >>>>>> An Intermediate Correlation Process is an Intermediate Proce= ss >>>>>> which adds information to records noting correlations among = them, >>>>>> or generates new records with correlated data from multiple >>>>>> records (e.g. the production of bidirectional flow records f= rom >>>>>> unidirectional flow records). >>>>>> >>>>>> Intermediate Selection Process >>>>>> >>>>>> An Intermediate Selection Process is an Intermediate Process= that >>>>>> selects records from a sequence based upon criteria evaluate= d >>>>>> record values, and passes only those records that match the >>>>>> criteria (e.g. filtering only records from a given network t= o a >>>>>> given Collector). >>>>>> >>>>>> Intermediate Anonymisation Process >>>>>> >>>>>> An Intermediate Anonymisation Process is an Intermediate Pro= cess >>>>>> that transforms records in order to anonymise them, to prote= ct the >>>>>> identity of the entities described by the records (e.g. by >>>>>> applying prefix-preserving pseudonymisation of IP addresses)= =2E >>>>>> >>>>>> IPFIX Mediator >>>>>> >>>>>> An IPFIX Mediator is an IPFIX Device that provides mediation= >>>>>> capabilities by receiving records from some data source, hos= ting >>>>>> zero or more Intermediate Processes to transform those recor= ds, >>>>>> and exporting those records in IPFIX Messages via an Exporti= ng >>>>>> Process. In the common case, a Mediator receives records fr= om a >>>>>> Collecting Process, but could also receive records from data= >>>>>> sources not encoded using IPFIX, e.g., in the case of NetFlo= w V9 >>>>>> protocol translation. Specific types of Mediators are defin= ed >>>>>> below; some of these reference original mediation capabiliti= es >>>>>> defined in earlier IPFIX documens before the elaboration of = the >>>>>> Mediator problem statement. >>>>>> >>>>>> Original Exporter >>>>>> >>>>>> Original Exporter is an IPFIX Device that hosts the Observat= ion >>>>>> Points where the metered IP packets are observed. >>>>>> >>>>>> IPFIX Proxy >>>>>> >>>>>> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPF= IX >>>>>> Messages or messages in other protocols to one or more Colle= ctors. >>>>>> It can provide transport protocol mediation and re-encoding.= >>>>>> >>>>>> IPFIX Concentrator >>>>>> >>>>>> An IPFIX Concentrator is an IPFIX Mediator that recieves dat= a from >>>>>> one or more Exporters and sends them to a single Collector, >>>>>> optionally transforming the records using zero or more >>>>>> Intermediate Processes on the way. >>>>>> >>>>>> IPFIX Distributor >>>>>> >>>>>> An IPFIX Distributor is an IPFIX Mediator that recieves data= from >>>>>> one or more Exporters and sends them to one or more Collecto= rs, >>>>>> deciding which Collector(s) to send each record to based upo= n the >>>>>> decision of an Intermediate Selection Process. >>>>>> >>>>>> IPFIX Masquerading Proxy >>>>>> >>>>>> An IPFIX Masquerading Proxy is an IPFIX Mediator that reciev= es >>>>>> data from one or more Exporters and sends them to a single >>>>>> Collector, using one or more Intermediate Aggregation Functi= ons >>>>>> and Intermediate Anonymisation Functions to screen out parts= of >>>>>> records according to configured policies, in order to protec= t the >>>>>> privacy of the network's end users or senstive data of the >>>>>> exporting organization. >>>>>> >>>>>> >>>>>> I think that we agree that the same terminology sections in both t= he=20 >>>>>> problem statement and framework. >>>>>> Personally, I'm not sure (yet) if we need the Intermediate=20 >>>>>> Aggregation/Correlation/Selection/Anonynisation Process. >>>>>> However, if we do, my proposal is to omit this list from the probl= em=20 >>>>>> statement, and to simply put them in the framework. >>>>>> >>>>>> Please let us know, so that we can move forward with the drafts, b= oth=20 >>>>>> the problem statements and the framework. >>>>>> >>>>>> Regards, Benoit. >>>>>> >=20 >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms090604010703050408030602 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzA4MTIxMjQ0WjAjBgkqhkiG9w0BCQQxFgQU wyEHffnddG1AxHsuIEHx/dYAOIIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAMIg4174bR5AoLsBobvACGRaGzF/uEBcMXIsPXCD0JMKZl4H SCNaFQnXxM7vNAJVa52F5KtuBRej17xAS2jXT34JdV2Z6C5SHHLrn4EdZaGPhXVMuL0m90k8 YM4+Ydl6mySZDrM3OD7y6cXcBACKU8KeEFgxb+jQXoIK4KWDeZbGzo3NWtyLTQpOKRxb1wYe LXa9WD5p7+XhbGpj9+2Ftoj6UyvY8RSl+AE3gtPYBdy2dgV8jP+fbmkV2RLg7vPXeOYXZBeT hMCnzFnSZDSetZvkAM/+dMtXqLc650P1mEAbFruNZmLWuSdoJZPKJVYKpH62FqSloGCLAyCD Y9c2bKIAAAAAAAA= --------------ms090604010703050408030602-- From muenz@net.in.tum.de Wed Jul 8 07:27:47 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7E03A6EF9 for ; Wed, 8 Jul 2009 07:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9ChB1lds72n for ; Wed, 8 Jul 2009 07:27:46 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 01EEA3A696B for ; Wed, 8 Jul 2009 07:27:45 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id D75C947D26 for ; Wed, 8 Jul 2009 16:00:21 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id C0C53A24; Wed, 8 Jul 2009 16:00:21 +0200 (CEST) Message-ID: <4A54A6DF.6070102@net.in.tum.de> Date: Wed, 08 Jul 2009 16:02:07 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030908050800040703080800" X-Virus-Scanned: ClamAV using ClamSMTP Cc: Daniel Mentz Subject: [IPFIX] New Version Notification for draft-mentz-ipfix-dtls-recommendations-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:27:47 -0000 This is a cryptographically signed message in MIME format. --------------ms030908050800040703080800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Nevil, all, After experiencing that implementing IPFIX over DTLS is not as straight forward as we expected, we decided to post a draft on the issues and possible solutions we have found. If there is time, I would like to present and discuss these issues in a short time slot in Stockholm. Best regards, Gerhard -------- Original Message -------- Subject: New Version Notification for draft-mentz-ipfix-dtls-recommendations-00 Date: Mon, 6 Jul 2009 13:23:10 -0700 (PDT) From: IETF I-D Submission Tool To: mentz@in.tum.de CC: muenz@net.in.tum.de, braun@net.in.tum.de A new version of I-D, draft-mentz-ipfix-dtls-recommendations-00.txt has been successfuly submitted by Daniel Mentz and posted to the IETF repository. Filename: draft-mentz-ipfix-dtls-recommendations Revision: 00 Title: Recommendations for Implementing IPFIX over DTLS Creation_date: 2009-07-06 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document discusses problems and solutions regarding the implementation of the IPFIX protocol over SCTP and DTLS. The IETF Secretariat. --------------ms030908050800040703080800 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzA4MTQwMjA3WjAjBgkqhkiG9w0BCQQxFgQU Rj7uKr5LRyfFB+LGUE0Q+RQrNIowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAEyQT++B4gweJZUmolDXrqCnWvLPWl4eAmmpBsqeFr6aK6iE k+ibl7XmniqwhJ92YABclViLS2Bg6YjtDC0iuTFrxS5ozLIe6aMZ8zjWGI7pON/FbBPpwUzI tL4j2L5nGuBcGV+tjCQcDv+OIER+DZm1jFVibUUkdSvGvOOyQ2i1en43DfTrmH728RIvAyhZ jFIpzGnRe8AXoRqnf9yc2HSniJt8iGYGwOHDK6WZnqHSah8xTxH8GprnNkXj/GuHKKijXu9d T1784jWWSmQDuXgclAaJAQHPODnCJINUCIJsCn9NTR7HPPVe4qbZtCYJvjgYYjQ9FnVvIyzJ 8huP8dEAAAAAAAA= --------------ms030908050800040703080800-- From Thomas.Dietz@nw.neclab.eu Thu Jul 9 05:50:25 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C18E3A6963 for ; Thu, 9 Jul 2009 05:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yYVt0t0NQXq for ; Thu, 9 Jul 2009 05:50:23 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id DBEED3A6813 for ; Thu, 9 Jul 2009 05:50:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3EB0D2C0203FF; Thu, 9 Jul 2009 14:50:50 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YR3Iz6ddytFF; Thu, 9 Jul 2009 14:50:50 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 08F272C017B31; Thu, 9 Jul 2009 14:50:30 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Jul 2009 14:50:28 +0200 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0328_01CA00A4.9940D580" Message-ID: <547F018265F92642B577B986577D671CA6F69C@VENUS.office> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: IPFIX-MIB Selection Process changes Thread-Index: AcoAk9WZ+M3Jyp3ATUWhXP2jEr+XXA== From: "Thomas Dietz" To: Subject: [IPFIX] IPFIX-MIB Selection Process changes X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 12:50:25 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0328_01CA00A4.9940D580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, we are in the course to really finish the IPFIX MIB now. Gerhard identified a last issue while aligning the IPFIX MIB with the Configuration Model. The Configuration Model has the following premises: 1) The Metering Process processes only packets from a single Observation Domain 2) A Selection Process (SP) can be composed of a sequence of multiple Selectors building a Composite Selector/Selection Sequence And allows to do the following selections from a observed packet stream: 3) +- SP1 -+ Stream -+ +- Cache +- SP2 -+ 4) +- Cache1 Stream - SP -+ +- Cache2 Premises 1 and 2 were fulfilled with the current version of the MIB but 3 and for 4 were not. To fulfill premise 3 was easy: To align terminology and fulfill premise 3 we renamed the ipfixSelectorTable to ipfixSelectionProcessTable and added another index the ipfixSelectionProcessIndex. So we get the following structure: +--ipfixSelectionProcessTable(8) | +--ipfixSelectionProcessEntry(1) [ipfixMeteringProcessCacheId,ipfixSelectionProcessIndex,ipfixSelectionProces sSelectorIndex] | +-- --- Unsigned32 ipfixSelectionProcessIndex(1) +-- --- Unsigned32 ipfixSelectionProcessSelectorIndex(2) +-- r-n ObjectIdentifier ipfixSelectionProcessSelectorFunction(3) This allows us to build more than one Selection Process per Metering Process Cache. The remaining issue is premise 4. To fulfill this premise we would need to introduce another table that allows binding Selection Process and Metering Process Cache but define the Selection Process without actually binding it to the Metering Process Cache. I am not sure which relevance this case has in practice. So if you have a strong opinion have an opinion on the issue please comment. On the other hand we may live with a workaround as follows: +- SP1 - Cache1 Stream -+ +- SP2 - Cache2 Where SP1 and SP2 are defined the same, i.e. pointing to the same Selector Functions. This implies a little loss of information because this description does not imply that the outputs of SP1 and SP2 are exactly the same. I'll publish a new version of the draft on Monday and would appreciate your feedback until then. Best Regards, Thomas -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL ------=_NextPart_000_0328_01CA00A4.9940D580 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNzCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFODCCBCCgAwIBAgIEDTI0WzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0wODExMDYwOTIwMTFaFw0xMTExMDYwOTIwMTFaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCniLuqlMflMs7ag3idESVRwfZ9nrdIyUmq5Tget4k9APGSPo2GZ1f1hr8y MuJIGowc/HzS1laVSICclOXju1xW93Tm+Vco5gwkRqHXY3Rmda0r2jlb8niVie4qXQgXPzunFRqk yNmbwYep3oD5Kq0GfB6EuZ7X6cYH5A7erAMeeQPhoDQDIfR79lRHlcMtanJZyORYNQONPEa+L4AF v5f3nAsmY7ZLJ72wX7X8BtcF6Vdkr0T2b1YrPl8Qir7e0TKY9Rf0q5DKu3QdLnXk0Rb+63V/4vLS PZ3XQVdwHzLiOhIZJVVMJE7TmJI0DFeDFn99O/F/Le/sJOJjNO4n6KMLAgMBAAGjggHHMIIBwzAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFLkbmpJJpIXhIR9JFttGC+KHW5g5MB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCQGA1UdEQQdMBuBGVRob21hcy5EaWV0ekBudy5uZWNsYWIuZXUwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9j YWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwv Y2FjcmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNh LmRmbi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQEFBQADggEBAEbKwRBhNxAzsH6kAYRBoIziyI2IY2QnZGeiGitOfkLKcFNIBH3ZfQXH4j20 4BP34Vzzob17EgsbLbNkMlxh2M7tenXH9vA4MiN5yPPBKoR7SfI6mIaIr+7kewOizJ8D5dvpdfP5 HbAUTZVSYHqixgBWJyNp7sXWVQtOo+eOv8qKUeiodClanKuCnGD42Bl6EQR486dlXvOronEikRYX Xg6gFrhO+DonUYluMZpNdabnybKozchSdHcceOKd0JFMmyiSNG944ystXbR7QZqfNSh/Pbyc5QRp Z1vdFZLFh907iS3KxueDYKDPWmlsPt/QnmXmF4A9/5OrmVS1C45k5rcxggQ4MIIENAIBATCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzAJBgUrDgMCGgUAoIICczAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA3MDkxMjUwMjdaMCMGCSqG SIb3DQEJBDEWBBRpobqYZEMNRiv6iAJdfych4D3I6jCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQsw CQYDVQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3Jh dG9yaWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZp emllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQNMjRbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzCBtwYJKoZIhvcNAQkPMYGpMIGm MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkq hkiG9w0BAQEFAASCAQAZi5DvUCLj5B2kT+Qvp/ZLxOXjK8knfb9ACETtnKxbXgTCwtobynELOk5W TBTdK2IHu1Xulz8PWExglv9lfsO+GfNkUsvpX6slqOsnPmvy3cn0uL6phofIOeiFUd97qlZrLNgF dHW1GDZuZuFitbI8W+v/kpBhvebHuByrnPIUMg/XBDiVyulUD01HUHxK05Iw0C3mwZ9s04qvIoAz j5YZ9JE9g26XDq2Qrk/ojOutQyVeB0UR2QuFo1Taiez85bJ+wk3kbNgwcgboDDKB6BqdDNqOQLye XWDRJuxysNVPqPN2QzY/kw05wJcLLRVqCsdzldYOAVk6Mkb3LBxzUOiAAAAAAAAA ------=_NextPart_000_0328_01CA00A4.9940D580-- From muenz@net.in.tum.de Thu Jul 9 06:02:49 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0B43A69F1 for ; Thu, 9 Jul 2009 06:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jTM1JnKDskQ for ; Thu, 9 Jul 2009 06:02:48 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 2E7463A6C7A for ; Thu, 9 Jul 2009 06:02:48 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 193E048456; Thu, 9 Jul 2009 15:03:14 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id EF3873F04; Thu, 9 Jul 2009 15:03:13 +0200 (CEST) Message-ID: <4A55EAFC.9030703@net.in.tum.de> Date: Thu, 09 Jul 2009 15:05:00 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Thomas Dietz References: <547F018265F92642B577B986577D671CA6F69C@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671CA6F69C@VENUS.office> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090404020403060307080603" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-MIB Selection Process changes X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 13:02:49 -0000 This is a cryptographically signed message in MIME format. --------------ms090404020403060307080603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you, Thomas. I support the proposed changes. Regards, Gerhard Thomas Dietz wrote: > Dear all, >=20 > we are in the course to really finish the IPFIX MIB now. Gerhard identi= fied > a last issue while aligning the IPFIX MIB with the Configuration Model.= The > Configuration Model has the following premises: >=20 > 1) The Metering Process processes only packets from a single Observatio= n > Domain >=20 > 2) A Selection Process (SP) can be composed of a sequence of multiple > Selectors building a Composite Selector/Selection Sequence >=20 > And allows to do the following selections from a observed packet stream= : >=20 > 3)=20 > +- SP1 -+ > Stream -+ +- Cache > +- SP2 -+ >=20 > 4) > +- Cache1 > Stream - SP -+ > +- Cache2 >=20 > Premises 1 and 2 were fulfilled with the current version of the MIB but= 3 > and for 4 were not. To fulfill premise 3 was easy: >=20 > To align terminology and fulfill premise 3 we renamed the ipfixSelector= Table > to ipfixSelectionProcessTable and added another index the > ipfixSelectionProcessIndex. So we get the following structure: >=20 > +--ipfixSelectionProcessTable(8) > | > +--ipfixSelectionProcessEntry(1) > [ipfixMeteringProcessCacheId,ipfixSelectionProcessIndex,ipfixSelectionP= roces > sSelectorIndex] > | > +-- --- Unsigned32 ipfixSelectionProcessIndex(1) > +-- --- Unsigned32 ipfixSelectionProcessSelectorIndex(2) > +-- r-n ObjectIdentifier ipfixSelectionProcessSelectorFunction(3)= >=20 > This allows us to build more than one Selection Process per Metering Pr= ocess > Cache. >=20 > The remaining issue is premise 4. To fulfill this premise we would need= to > introduce another table that allows binding Selection Process and Meter= ing > Process Cache but define the Selection Process without actually binding= it > to the Metering Process Cache. >=20 > I am not sure which relevance this case has in practice. So if you have= a > strong opinion have an opinion on the issue please comment. >=20 > On the other hand we may live with a workaround as follows: >=20 > +- SP1 - Cache1 > Stream -+ > +- SP2 - Cache2 >=20 > Where SP1 and SP2 are defined the same, i.e. pointing to the same Selec= tor > Functions. This implies a little loss of information because this > description does not imply that the outputs of SP1 and SP2 are exactly = the > same. >=20 > I'll publish a new version of the draft on Monday and would appreciate = your > feedback until then. >=20 > Best Regards, >=20 > Thomas >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms090404020403060307080603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzA5MTMwNTAwWjAjBgkqhkiG9w0BCQQxFgQU UNzGWl/1GRuOrRo6T6k/b5PaKUkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBACXCfB6o9ngqmIM9haTl126u/ruLOvOmLZVzWBnmk3HT1GNH 1Yaa76WLbB/1BBCKlQBxYX1+kPHOfUZYtzd98+HMgSrXopYqcX5y2q0Q980uugg6kkAyGkGo M8DsNJHswwikiUUcdkHpGpci54OsYEyWYtgRkCSYrBtLYXsOZLOHa2koEKDKBwm4EtCtKZmC HKhaFjfk0QTWtAxAVuhCJ41IfxANZhjAD+qdUshFNQt8VVltcgMT49fUe10xdWx+sNAkX03T 4BCSLx2AZzXo9vZGY2qOGHZJq/9r0AzXysrLPsxZv7AYImP/FQ6zaSWIRxSfzfiMS5rO7sHa F4yZKQkAAAAAAAA= --------------ms090404020403060307080603-- From n.brownlee@auckland.ac.nz Thu Jul 9 15:03:29 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4873A6A8F for ; Thu, 9 Jul 2009 15:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzP712L97H0Q for ; Thu, 9 Jul 2009 15:03:28 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 2911228C292 for ; Thu, 9 Jul 2009 15:03:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 72FF1670CA5; Fri, 10 Jul 2009 10:03:46 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi+vS2N1UcO5; Fri, 10 Jul 2009 10:03:46 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 410AE670CFF; Fri, 10 Jul 2009 10:03:42 +1200 (NZST) Message-ID: <4A56693E.3010704@auckland.ac.nz> Date: Fri, 10 Jul 2009 10:03:42 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Brian Trammell References: <83715AFF-B6BD-4FE0-8C62-EC7860F12D90@tik.ee.ethz.ch> In-Reply-To: <83715AFF-B6BD-4FE0-8C62-EC7860F12D90@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group , Juergen Quittek Subject: Re: [IPFIX] draft-ietf-ipfix-file-04, final reviews X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 22:03:29 -0000 Hi Brian: I'd say submit it now. If further changes do turn out to be needed, we can always publish another. Also, my colleague Russell Fulton agreed to review it for me, but he's been away all this week at a family funeral. However, his immediate reaction to the question of "what about SSL-encrypted IPFIX data?" was 'store it in clear, and use whatever file security procedures are necessary in your environment." Cheers, Nevil Brian Trammell wrote: > Hi, Dan, > > Attached is the current -04 rev of the file draft. I'll be in Stockholm > the whole week for IETF 75, and would like to use the opportunity, if > necessary, to clear the remaining discusses on the draft. Is the right > way to do this to submit now, before the deadline, and prepare an -05 > with any additional IESG comments, or to circulate the document > "privately", without submission, and incorporate any additional comments > into -04? > > Thanks, and best regards, > > Brian > This body part will be downloaded on demand. -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trammell@tik.ee.ethz.ch Thu Jul 9 15:37:51 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C80028C2DB for ; Thu, 9 Jul 2009 15:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXT3v5Qcj0k2 for ; Thu, 9 Jul 2009 15:37:50 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 36DFB28C2C7 for ; Thu, 9 Jul 2009 15:37:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6F1CCD9394; Fri, 10 Jul 2009 00:38:16 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YiKHPUd9Laqo; Fri, 10 Jul 2009 00:38:16 +0200 (MEST) Received: from [10.0.1.11] (84-75-161-38.dclient.hispeed.ch [84.75.161.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 153A7D9381; Fri, 10 Jul 2009 00:38:16 +0200 (MEST) Message-Id: From: Brian Trammell To: Nevil Brownlee In-Reply-To: <4A56693E.3010704@auckland.ac.nz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 10 Jul 2009 00:38:15 +0200 References: <83715AFF-B6BD-4FE0-8C62-EC7860F12D90@tik.ee.ethz.ch> <4A56693E.3010704@auckland.ac.nz> X-Mailer: Apple Mail (2.935.3) Cc: IPFIX Working Group , Juergen Quittek Subject: Re: [IPFIX] draft-ietf-ipfix-file-04, final reviews X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 22:37:51 -0000 Hi, Nevil, Cool, thanks (and my condolences to Russell); will submit in the CET morning/early afternoon tomorrow. FWIW, Russell's comments echo very much the draft's original stance (encryption is external, out of scope, and must be chosen on a per-deployment basis to meet each environment's own standards) but have the downside (as discussed by the security ADs) that there is no provision for inter-organizational or inter-vendor exchange of encrypted files. (Of course, IPFIX files are files, and you can store them however you like, ignoring CMS if you have no use for it; the only penalty is you'll have to decrypt the file yourself "outside" a compliant File Reader... which for organizations that have such procedures in place, is probably no penalty at all...) Cheers, Brian On Jul 10, 2009, at 12:03 AM, Nevil Brownlee wrote: > Hi Brian: > > I'd say submit it now. If further changes do turn out to be needed, > we can always publish another. > > Also, my colleague Russell Fulton agreed to review it for me, but > he's been away all this week at a family funeral. However, his > immediate reaction to the question of "what about SSL-encrypted > IPFIX data?" was 'store it in clear, and use whatever file security > procedures are necessary in your environment." > > Cheers, Nevil > > > Brian Trammell wrote: >> Hi, Dan, >> Attached is the current -04 rev of the file draft. I'll be in >> Stockholm the whole week for IETF 75, and would like to use the >> opportunity, if necessary, to clear the remaining discusses on the >> draft. Is the right way to do this to submit now, before the >> deadline, and prepare an -05 with any additional IESG comments, or >> to circulate the document "privately", without submission, and >> incorporate any additional comments into -04? >> Thanks, and best regards, >> Brian >> This body part will be downloaded on demand. > > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From n.brownlee@auckland.ac.nz Thu Jul 9 22:06:24 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 419FB3A6D50 for ; Thu, 9 Jul 2009 22:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.91 X-Spam-Level: X-Spam-Status: No, score=-4.91 tagged_above=-999 required=5 tests=[AWL=0.819, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIIPHpK-EOEx for ; Thu, 9 Jul 2009 22:06:23 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id B3E053A6D4F for ; Thu, 9 Jul 2009 22:06:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4A808669904 for ; Fri, 10 Jul 2009 17:06:34 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AygCOHAQQy50 for ; Fri, 10 Jul 2009 17:06:34 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 22B716698D6 for ; Fri, 10 Jul 2009 17:06:31 +1200 (NZST) Message-ID: <4A56CC57.3000004@auckland.ac.nz> Date: Fri, 10 Jul 2009 17:06:31 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] ***First Draft*** Agenda for Stockholm meeting X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 05:06:24 -0000 Hi all: Here's my first attempt at an agenda for the IPFIX meeting at IETF 75 in Stockholm. Please send me any changes, suggestions for improvements, etc. Thanks, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand ====================================================== Ip Flow Information Export WG (ipfix) IETF #75, Stockholm Monday, 27 July 09 at 1520-1720 ====================================================== Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review WG Status = 5 min 2. Update from last meeting = 3 min a) Exporting Type Information for IPFIX IEs (Elisa Boschi) - draft-ietf-ipfix-exporting-type-02.txt Approved as PS, to RFC Editor 10 Jun 09 b) Information Element Registry status - Nevil is (slowly) working with IANA on getting the changes made as per the current errata 4. Drafts submitted to IESG = 17 min a) IPFIX File Format (Brian Trammell) ( 3 min) - draft-ietf-ipfix-file-03.txt 24 Oct 08 - draft-ietf-ipfix-file-04.txt b) IPFIX Per-Stream SCTP reporting (Benoit CLaise) ( 5 min) - draft-ietf-ipfix-export-per-sctp-stream-02.txt 26 Jan 09 - draft-ietf-ipfix-export-per-sctp-stream-03.txt c) IPFIX MIB (Thomas Dietz) ( 9 min) - draft-ietf-ipfix-mib-06.txt 9 Mar 09 - draft-ietf-ipfix-mib-07.txt 5. Current WG drafts = 50 min b) Configuration Data Model ( 5 min) - draft-ietf-ipfix-configuration-model-02.txt, 6 Mar 09 c) IPFIX Mediation: (Kobayashi Atsushi) (15 min) - draft-ietf-ipfix-mediators-problem-statement-03.txt 30 Apr 09 - draft-ietf-ipfix-mediators-framework-02.txt (25 min) 11 Feb 09 6. Other drafts = 30 min a) Handling Structured Data (Benoit Claise) - draft-claise-structured-data-in-ipfix-01.txt (15 min) b) VoIP Monitoring and Exporting (Sven Anderson) - draft-huici-ipfix-sipfix-00.txt 22 Jun 09 (15 min) 7. Any Other Drafts ??? = 15 min [from last meeting: a) Flow Selection (Lorenzo Peluso, Tanja Zseby) - draft-peluso-flowselection-tech-02 b) IP Flow Anonymization Support (Elisa Bschi, Brian Trammel) - draft-boschi-ipfix-anon-02 12 Jan 09 ] Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=75 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org ------------------ From akoba@nttv6.net Thu Jul 9 22:57:38 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27FFD3A6D79 for ; Thu, 9 Jul 2009 22:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.884, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx7bDxsm2+Qn for ; Thu, 9 Jul 2009 22:57:37 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id A6C0F3A6A57 for ; Thu, 9 Jul 2009 22:57:36 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:7954:114a:dc65:fce4]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n6A5w33w025495 for ; Fri, 10 Jul 2009 14:58:03 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 10 Jul 2009 14:53:39 +0900 From: Atsushi Kobayashi To: "ipfix@ietf.org" Message-Id: <20090710144529.8329.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Fri, 10 Jul 2009 14:58:03 +0900 (JST) Subject: [IPFIX] transport mediation in IPFIX Mediation? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 05:57:38 -0000 Dear all, I change the thread. I would like to ask IPFIX members. I and Gerhald are discussing terms IPFIX Mediation/IPFIX Mediaor. These current terms are: IPFIX Mediation IPFIX Mediation describes the manipulation and conversion of records for subsequent export using IPFIX, by applying mediation functions within one or more Intermediate Processes to a stream of records in an IPFIX Mediator. IPFIX Mediator An IPFIX Mediator is an IPFIX Device that provides mediation capabilities by receiving records from some data source, hosting zero or more Intermediate Processes to transform those records, and exporting those records in IPFIX Messages via an Exporting Process. In the common case, a Mediator receives records from a Collecting Process, but could also receive records from data sources not encoded using IPFIX, e.g., in the case of NetFlow V9 protocol translation. Question: Does IPFIX Mediation or an IPFIX Mediator cover the transport mediation, e.g. from IPFIX-over-UDP to IPFIX-over-SCTP ? According to above terms, we can choose in two ways: a) An IPFIX Mediator covers the transport mediation, and IPFIX Mediation does not, if an Intermediate Process does not cover the transport mediation. b) Both of an IPFIX Mediator and IPFIX Mediation cover the transport mediation, if an Intermediate Process covers the transport mediation. First of all, I believe the IPFIX Mediation covering transport mediation is already consensus regardless of whether an Intermediate Process covers transport mediation or not, because I presented the following slide in IETF73rd and there is no objection so far. https://www.ietf.org/proceedings/08nov/slides/ipfix-1.pdf Thus, I agree the following new term. IPFIX Mediation IPFIX Mediation is the manipulation and conversion of records or IPFIX Messages for subsequent export using IPFIX, by applying mediation functions to a stream of records, and/or applying transport based mediation functions to IPFIX Messages. Let me know your opinions. I will write down this feedback in new version drafts according to consensus as far as possible. Its deadline next monday is approaching. BTW, I think that whether an Intermediate Process covers transport mediation or not is the framework issue. Simply, even when relaying IPFIX Messages, I think that we needs some function that handles incoming session status and IPFIX Withdrawal Messages. Thus, it may need Intermediate Process. Regards, Atsushi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From akoba@nttv6.net Thu Jul 9 22:59:18 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87C23A6D82 for ; Thu, 9 Jul 2009 22:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8p3j4pT-gDx for ; Thu, 9 Jul 2009 22:59:17 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id C62213A6D79 for ; Thu, 9 Jul 2009 22:58:54 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:7954:114a:dc65:fce4]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n6A5xIHH025504; Fri, 10 Jul 2009 14:59:19 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 10 Jul 2009 14:54:55 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4A548D3C.7030801@net.in.tum.de> References: <20090708072133.829F.17391CF2@nttv6.net> <4A548D3C.7030801@net.in.tum.de> Message-Id: <20090710144349.8327.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Fri, 10 Jul 2009 14:59:20 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 05:59:18 -0000 Hi Gerhard, I will change thread. It is consensus issue. I will ask IPFIX members. Regards, Atsushi On Wed, 08 Jul 2009 14:12:44 +0200 Gerhard Muenz wrote: > > Hi Atsushi, > > Atsushi Kobayashi wrote: > > Hi Gerhard, > > > > On Tue, 07 Jul 2009 12:22:21 +0200 > > Gerhard Muenz wrote: > > > >> Hi Atsushi, > >> > >> Current consensus is: > >> > >> IPFIX Mediation > >> > >> IPFIX Mediation describes the manipulation and conversion of > >> records for subsequent export using IPFIX, by applying mediation > >> functions within one or more Intermediate Processes to a stream of > >> records in an IPFIX Mediator. > >> > >> IPFIX Mediator > >> > >> An IPFIX Mediator is an IPFIX Device that provides mediation > >> capabilities by receiving records from some data source, hosting > >> zero or more Intermediate Processes to transform those records, > >> and exporting those records in IPFIX Messages via an Exporting > >> Process. In the common case, a Mediator receives records from a > >> Collecting Process, but could also receive records from data > >> sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > >> protocol translation. > >> > >> You and me agree that this fits for conversion of NetFlow to IPFIX. > >> So, where is the problem? > > > > IPFIX Mediation covers the manipulation of records, and needs at least > > single Intermediate Process. On the other hand, IPFIX Mediator doesnot > > need Intermediate Process while manipulation of IPFIX Messages. > > > > In the definition, the protocol conversion from NetFlow to IPFIX can > > be executed in IPFIX Mediator, but it does not seem IPFIX Mediation, > > IMO, this is IPFIX Mediation because an Intermediate Process converts > NetFlow records into IPFIX records. > > > and > > also changing transport protocol carrying IPFIX Messages (e.g. from UDP > > to SCTP) can be executed in IPFIX Mediator, but it does not seem IPFIX > > Mediation. > > Yes, in this corner case, you do not really need an Intermediate > Process. However, you could also say that you have a transparent > Intermediate Process which does not do anything to the stream of records. > > > Because RFC3917 already described that the above functions can be done by > > Exporting Process and/or Collecting Process only, such as protocol > > converter, and proxy. These functions do not seem to need Intermediate > > Process. > > > > Or do you mean that the above functions need another Intermediate > > Process? One is Intermediate Conversion Process? Which Intermediate > > Process do change transport protocol? > > > > Could you please elaborate your idea? > > Current terminology is: > > IPFIX Mediation: > ...one or more Intermediate Processes... > IPFIX Mediator: > ...zero or more Intermediate Processes... > > Benoit chose the different numbers because IPFIX Proxy without > Intermediate Process should be covered by IPFIX Mediator. That's ok with me. > > If you want to equalize the specified numbers of IPs, you can either > change the definition of IPFIX Mediation (as you propose): > > IPFIX Mediation: > ... *zero* or more Intermediate Processes... > (or omit mentioning IPs) > IPFIX Mediator: > ...zero or more Intermediate Processes... > > Or you change the definition of IPFIX Mediator: > > IPFIX Mediation: > ...one or more Intermediate Processes... > IPFIX Mediator: > ... *one* or more Intermediate Processes... > > If you want to change the definitions, I prefer the second option over > the first one. However, I would not object to the first one if you think > that this makes more sense. > > > BTW, Brian proposed the term IPFIX Mediation, as follows. Where is > > the problem in your idea? > > > > IPFIX Mediation > > > > IPFIX Mediation is the manipulation and conversion of > > records or IPFIX Messages for subsequent export using IPFIX, > > by applying mediation functions to a stream of records, and/or > > applying transport based mediation functions to IPFIX Messages. > > The old definition was simple and clear. The new definition causes > confusion because it introduces two types of mediation functions: > - "mediation functions" > - "transport based mediation functions" > You would have to explain the difference and probably introduce two more > terms like "Record Mediation Function" and "Transport Based Mediation > Function". > > Regards, > Gerhard > > > I think the current discussion is the level of framework rather than > > problem statement. The above term is fine for us regardless of the > > result of the discussion. > > > > Regards, > > Atsushi > > > >> You can forget about the details in the figure of RFC3917. If you > >> believe in them, there would not be any Intermediate Process at all, > >> just Metering Processes! > >> > >>> Actually, I thought same thing that the protocol converter needs Intermediate > >>> Process converting IE and/or creating subsidiary information (e.g. Flow > >>> Key map and sampling parameter) in form of Data Records. But, it can > >>> done in Exporting Process forming IPFIX Message, too. > >> The Exporting Process forms IPFIX Messages, but would not convert any > >> Templates or Records. > >> > >>> While reading twice in mailing list, I assumed that we will adopt case > >>> 1 through long discussion. But, I don't adhere case 1, I would like to > >>> get the consensus to progress to next stage. > >> As far as I see, current consensus are the definitions above. If you > >> propose a change, I do not see that we have already reached consensus. > >> > >> BTW, I assume that an IP implementing a conversion function is needed > >> anyway. For example, if you want to aggregate records from different > >> NetFlow Versions, I assume that you first convert all of them to IPFIX > >> Data Records, such that the Intermediate Aggregation Process only has to > >> process IPFIX records. At least, this is how we will implement it. > >> > >> Regards, > >> Gerhard > >> > >> > >> Atsushi Kobayashi wrote: > >>> Hi Gerhard, > >>> > >>>> Having an Intermediate Process, it fits into the current definition of > >>>> IPFIX Mediation :) > >>> I would like to discuss your points. > >>> We can choose the two ways: > >>> > >>> 1) Transport mediation does not need Intermediate Process, content > >>> mediation needs one or more Intermediate Process. > >>> > >>> We can consider the following IPFIX-related Devices in RFC3917 as IPFIX > >>> Mediation. > >>> > >>> +---+ +---+ +---+ > >>> | E-+-> | E-+-> | E-+------------->---+ > >>> | | | | | | | | | +---+ +-+-----+ > >>> +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> > >>> | | | | | | | | | | +---+ +-+-----+ > >>> +-+-+ +-+-+ | O | | M | | E-+->---+ > >>> | | | | +---+ | | | | | | > >>> | M | +-+-+ | O | | M | > >>> | | | | | | +---+ | | | +-----+ > >>> | O | | O | | O | ->-+-C-E-+-> > >>> +---+ +---+ +---+ +-----+ > >>> > >>> Protocol Remote Concentrator Proxy > >>> Converter Observation > >>> > >>> Figure 2: IPFIX-related Devices > >>> > >>> In case of conversion NetFlow to IPFIX, the protocol converter hosts a > >>> Exporting process only. > >>> > >>> 2) All of IPFIX Mediation has one or more Intermediate Process whether > >>> transport mediation or content mediation. > >>> > >>> In case of protocol converter, IPFIX Mediation has Intermediate > >>> Conversion Process as you suggested. And in case of IPFIX Proxy, we have > >>> to consider some Intermediate Foo Process. Although the definition is > >>> not consistent with RFC3917, it is not important in it. > >>> > >>> Gerhard, which one do you prefer? > >>> > >>> Actually, I thought same thing that the protocol converter needs Intermediate > >>> Process converting IE and/or creating subsidiary information (e.g. Flow > >>> Key map and sampling parameter) in form of Data Records. But, it can > >>> done in Exporting Process forming IPFIX Message, too. > >>> > >>> While reading twice in mailing list, I assumed that we will adopt case > >>> 1 through long discussion. But, I don't adhere case 1, I would like to > >>> get the consensus to progress to next stage. > >>> > >>> Regards, > >>> Atsushi > >>> > >>> On Mon, 06 Jul 2009 21:07:32 +0200 > >>> Gerhard Muenz wrote: > >>> > >>>> Atsushi, > >>>> > >>>> What is the motivation for this change? > >>>> Is it the use case of translating NetFlow into IPFIX? > >>>> > >>>> I assume that in most of the cases this translation cannot be done by > >>>> just copying Records from a NetFlow Packet into an IPFIX Message. > >>>> Typically, some small changes to the Template and Data Records are > >>>> required (e.g., conversion of IE IDs), which would be done by an > >>>> Intermediate Process. You can call it Intermediate Conversion Process. > >>>> > >>>> Having an Intermediate Process, it fits into the current definition of > >>>> IPFIX Mediation :) > >>>> > >>>> Regards, > >>>> Gerhard > >>>> > >>>> > >>>> Atsushi Kobayashi wrote: > >>>>> Dear Brian, Gerhard, Benoit and all, > >>>>> > >>>>> While writing next version IPFIX problem statement and framework draft, > >>>>> I found the following discrepancy between IPFIX Mediation and IPFIX > >>>>> Mediator. the term IPFIX Mediation implies that IPFIX Mediator hosts one or > >>>>> more Intermediate Processes. > >>>>> > >>>>> IPFIX Mediation > >>>>> > >>>>> IPFIX Mediation describes the manipulation and conversion of > >>>>> records for subsequent export using IPFIX, by applying mediation > >>>>> functions within one or more Intermediate Processes to a stream of > >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>>>> records in an IPFIX Mediator. > >>>>> > >>>>> IPFIX Mediator > >>>>> > >>>>> An IPFIX Mediator is an IPFIX Device that provides mediation > >>>>> capabilities by receiving records from some data source, hosting > >>>>> zero or more Intermediate Processes to transform those records, > >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>>>> and exporting those records in IPFIX Messages via an Exporting > >>>>> Process. In the common case, a Mediator receives records from a > >>>>> Collecting Process, but could also receive records from data > >>>>> sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > >>>>> protocol translation. > >>>>> > >>>>> I'd like to propose the new term IPFIX Mediation as follows. > >>>>> > >>>>> IPFIX Mediation > >>>>> > >>>>> IPFIX Mediation describes the manipulation and conversion of > >>>>> records or IPFIX Messages for subsequent export using IPFIX, by > >>>>> applying mediation functions within one or more Intermediate > >>>>> Processes to a stream of records, or applying transport based > >>>>> mediation functions to IPFIX Messages. > >>>>> > >>>>> Does it make sense? > >>>>> > >>>>> Regards, > >>>>> Atsushi > >>>>> > >>>>> On Fri, 26 Jun 2009 18:25:04 +0200 > >>>>> Benoit Claise wrote: > >>>>> > >>>>>> Dear all, > >>>>>> > >>>>>> I'm trying to summarize the long email thread. Not easy, there are some > >>>>>> diverging opinions. I hope I haven't forgotten anything > >>>>>> Below is the terminology proposal, based on Brian's proposal, improved > >>>>>> by Gerhard, and everybody. > >>>>>> > >>>>>> 2. Terminology and Definitions > >>>>>> > >>>>>> The terms in this section are in line with those in the IPFIX > >>>>>> Protocol specifications [RFC5101] and the PSAMP specification > >>>>>> document [RFC5476]. The terms Observation Point, Observation Domain, > >>>>>> Flow Key, Flow Record, Data Record, Exporting Process, Exporter, > >>>>>> IPFIX Device, Collecting Process, Collector, IPFIX Message, Metering > >>>>>> Process, Transport Session, Information Element, and Template > >>>>>> Withdrawal Message, are defined in the IPFIX protocol specifications > >>>>>> [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP > >>>>>> Device, and Configured Selection Fraction are defined in the PSAMP > >>>>>> specification document [RFC5476]. Furthermore, new terminology to be > >>>>>> used in the context of IPFIX Mediation is defined in this section. > >>>>>> All these terms have an initial capital letter in this document. > >>>>>> > >>>>>> In this document, we use the generic term "Data Records" for IPFIX > >>>>>> Flow Records, PSAMP Packet Reports, Data Records defined by Options > >>>>>> Templates, unless an explicit distinction is required. > >>>>>> > >>>>>> Original Exporter > >>>>>> > >>>>>> Original Exporter is an IPFIX Device that hosts the Observation > >>>>>> Points where the metered IP packets are observed. > >>>>>> > >>>>>> IPFIX Mediation > >>>>>> > >>>>>> IPFIX Mediation describes the manipulation and conversion of records > >>>>>> for subsequent export using IPFIX, by applying mediation functions > >>>>>> within one or more Intermediate Processes to a stream of records in > >>>>>> an IPFIX Mediator. > >>>>>> > >>>>>> The following terms are used in this document to describe the > >>>>>> architectural entities used by IPFIX Mediation. > >>>>>> > >>>>>> Intermediate Process > >>>>>> > >>>>>> An Intermediate Process takes a sequence of records from a Collecting > >>>>>> Process, Metering Process, IPFIX File Reader, or another Intermediate > >>>>>> Process within a Mediator; performs some transformation on these > >>>>>> records > >>>>>> based upon the content of the records themselves, state kept across > >>>>>> multiple records, configuration parameters, or other data; and passes > >>>>>> a sequence of transformed records on to an Exporting Process, > >>>>>> IPFIX File > >>>>>> Writer, or another Intermediate Process within a Mediator. This > >>>>>> document > >>>>>> describes specific Intermediate Processes below used in the > >>>>>> elaboration > >>>>>> of the problem statement; however, this is not an exhaustive list. > >>>>>> > >>>>>> Intermediate Aggregation Process > >>>>>> > >>>>>> An Intermediate Aggregation Process is an Intermediate Process that > >>>>>> aggregates records based upon a set of Flow Keys, or functions > >>>>>> applied to fields from the record (e.g. binning, subnet aggregation). > >>>>>> > >>>>>> Intermediate Correlation Process > >>>>>> > >>>>>> An Intermediate Correlation Process is an Intermediate Process > >>>>>> which adds information to records noting correlations among them, > >>>>>> or generates new records with correlated data from multiple > >>>>>> records (e.g. the production of bidirectional flow records from > >>>>>> unidirectional flow records). > >>>>>> > >>>>>> Intermediate Selection Process > >>>>>> > >>>>>> An Intermediate Selection Process is an Intermediate Process that > >>>>>> selects records from a sequence based upon criteria evaluated > >>>>>> record values, and passes only those records that match the > >>>>>> criteria (e.g. filtering only records from a given network to a > >>>>>> given Collector). > >>>>>> > >>>>>> Intermediate Anonymisation Process > >>>>>> > >>>>>> An Intermediate Anonymisation Process is an Intermediate Process > >>>>>> that transforms records in order to anonymise them, to protect the > >>>>>> identity of the entities described by the records (e.g. by > >>>>>> applying prefix-preserving pseudonymisation of IP addresses). > >>>>>> > >>>>>> IPFIX Mediator > >>>>>> > >>>>>> An IPFIX Mediator is an IPFIX Device that provides mediation > >>>>>> capabilities by receiving records from some data source, hosting > >>>>>> zero or more Intermediate Processes to transform those records, > >>>>>> and exporting those records in IPFIX Messages via an Exporting > >>>>>> Process. In the common case, a Mediator receives records from a > >>>>>> Collecting Process, but could also receive records from data > >>>>>> sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > >>>>>> protocol translation. Specific types of Mediators are defined > >>>>>> below; some of these reference original mediation capabilities > >>>>>> defined in earlier IPFIX documens before the elaboration of the > >>>>>> Mediator problem statement. > >>>>>> > >>>>>> Original Exporter > >>>>>> > >>>>>> Original Exporter is an IPFIX Device that hosts the Observation > >>>>>> Points where the metered IP packets are observed. > >>>>>> > >>>>>> IPFIX Proxy > >>>>>> > >>>>>> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX > >>>>>> Messages or messages in other protocols to one or more Collectors. > >>>>>> It can provide transport protocol mediation and re-encoding. > >>>>>> > >>>>>> IPFIX Concentrator > >>>>>> > >>>>>> An IPFIX Concentrator is an IPFIX Mediator that recieves data from > >>>>>> one or more Exporters and sends them to a single Collector, > >>>>>> optionally transforming the records using zero or more > >>>>>> Intermediate Processes on the way. > >>>>>> > >>>>>> IPFIX Distributor > >>>>>> > >>>>>> An IPFIX Distributor is an IPFIX Mediator that recieves data from > >>>>>> one or more Exporters and sends them to one or more Collectors, > >>>>>> deciding which Collector(s) to send each record to based upon the > >>>>>> decision of an Intermediate Selection Process. > >>>>>> > >>>>>> IPFIX Masquerading Proxy > >>>>>> > >>>>>> An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves > >>>>>> data from one or more Exporters and sends them to a single > >>>>>> Collector, using one or more Intermediate Aggregation Functions > >>>>>> and Intermediate Anonymisation Functions to screen out parts of > >>>>>> records according to configured policies, in order to protect the > >>>>>> privacy of the network's end users or senstive data of the > >>>>>> exporting organization. > >>>>>> > >>>>>> > >>>>>> I think that we agree that the same terminology sections in both the > >>>>>> problem statement and framework. > >>>>>> Personally, I'm not sure (yet) if we need the Intermediate > >>>>>> Aggregation/Correlation/Selection/Anonynisation Process. > >>>>>> However, if we do, my proposal is to omit this list from the problem > >>>>>> statement, and to simply put them in the framework. > >>>>>> > >>>>>> Please let us know, so that we can move forward with the drafts, both > >>>>>> the problem statements and the framework. > >>>>>> > >>>>>> Regards, Benoit. > >>>>>> --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From muenz@net.in.tum.de Fri Jul 10 04:06:24 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45443A6E02 for ; Fri, 10 Jul 2009 04:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR4x3b2YRnPe for ; Fri, 10 Jul 2009 04:06:23 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 41C5B3A69D5 for ; Fri, 10 Jul 2009 04:06:22 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 65AF548456; Fri, 10 Jul 2009 13:06:49 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 55F5F2DB3; Fri, 10 Jul 2009 13:06:49 +0200 (CEST) Message-ID: <4A572134.2030806@net.in.tum.de> Date: Fri, 10 Jul 2009 13:08:36 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20090710144529.8329.17391CF2@nttv6.net> In-Reply-To: <20090710144529.8329.17391CF2@nttv6.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070404060005070802000404" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] transport mediation in IPFIX Mediation? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 11:06:24 -0000 This is a cryptographically signed message in MIME format. --------------ms070404060005070802000404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Atsushi, Atsushi Kobayashi wrote: > Dear all, >=20 > I change the thread. I would like to ask IPFIX members. >=20 > I and Gerhald are discussing terms IPFIX Mediation/IPFIX Mediaor. > These current terms are: >=20 > IPFIX Mediation >=20 > IPFIX Mediation describes the manipulation and conversion of > records for subsequent export using IPFIX, by applying mediation > functions within one or more Intermediate Processes to a stream o= f > records in an IPFIX Mediator. >=20 > IPFIX Mediator >=20 > An IPFIX Mediator is an IPFIX Device that provides mediation > capabilities by receiving records from some data source, hosting > zero or more Intermediate Processes to transform those records, > and exporting those records in IPFIX Messages via an Exporting > Process. In the common case, a Mediator receives records from a > Collecting Process, but could also receive records from data > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > protocol translation. >=20 > Question: >=20 > Does IPFIX Mediation or an IPFIX Mediator cover the transport mediation= , > e.g. from IPFIX-over-UDP to IPFIX-over-SCTP ? >=20 > According to above terms, we can choose in two ways: >=20 > a) An IPFIX Mediator covers the transport mediation, and IPFIX Mediatio= n > does not, if an Intermediate Process does not cover the transport > mediation. >=20 > b) Both of an IPFIX Mediator and IPFIX Mediation cover the transport > mediation, if an Intermediate Process covers the transport mediation. >=20 > First of all, I believe the IPFIX Mediation covering transport mediatio= n > is already consensus regardless of whether an Intermediate Process > covers transport mediation or not, because I presented the following > slide in IETF73rd and there is no objection so far. > https://www.ietf.org/proceedings/08nov/slides/ipfix-1.pdf >=20 > Thus, I agree the following new term. >=20 > IPFIX Mediation >=20 > IPFIX Mediation is the manipulation and conversion of > records or IPFIX Messages for subsequent export using IPFIX, > by applying mediation functions to a stream of records, and/or > applying transport based mediation functions to IPFIX Messages. >=20 > Let me know your opinions. I will write down this feedback in new > version drafts according to consensus as far as possible. Its deadline > next monday is approaching. I still do not think that this is not a good definition. Especially, I would object to the formulation "transport based mediation functions". It is not clear what "transport based" is supposed to be. What about the following: IPFIX Mediation IPFIX Mediation is the manipulation and conversion of records or IPFIX Messages for subsequent export using IPFIX, by applying mediation functions to a stream of records, and/or applying transport protocol mediation. Note that this corresponds much better to what is written for IPFIX Proxy= : IPFIX Proxy An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX Messages or messages in other protocols to one or more Collectors. It can provide transport protocol mediation and re-encoding. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Regards, Gerhard > BTW, I think that whether an Intermediate Process covers transport > mediation or not is the framework issue. Simply, even when relaying > IPFIX Messages, I think that we needs some function that handles > incoming session status and IPFIX Withdrawal Messages. Thus, it may nee= d > Intermediate Process. >=20 > Regards, > Atsushi >=20 >=20 > ---=20 > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms070404060005070802000404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzEwMTEwODM2WjAjBgkqhkiG9w0BCQQxFgQU asdnVsP5fX2qzNpLKotow6WRP5swUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBABL9GheAaXOeEfRdodzBdyqaGFBiQWSmu+44HmOQuuSvbZ57 ZGlM+VUbpZPL+5vTG/+ERER6OZIxIbvKy9IICSKmpXix5EGwuzOaW6x2nfq1exTbphmZEQ8o LPhk1HS2U70b768nTzx7fCYVtpMUY++KDqZ+pZoHxcqWumI57pwIhPim32jQ4u/gIfIARjjX 8WErvAmRjsgcaHHgHrmxMN3k9HpCdwOE4iJuUN+AqTEfL2QwWceFwCKHsmlILi9mi5gO+IlF qgqVxWCI1t0yrAUCHlBE2P0mV7hb/u1SAeS1TnM8WmwTVnSQ1M6QcPBtYWqrmU7rM7uV+cnO AuS/Iu4AAAAAAAA= --------------ms070404060005070802000404-- From trammell@tik.ee.ethz.ch Fri Jul 10 04:14:54 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB333A6E3F for ; Fri, 10 Jul 2009 04:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbI6Hfeq-PR0 for ; Fri, 10 Jul 2009 04:14:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id A77FC3A698C for ; Fri, 10 Jul 2009 04:14:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5C926D93A3; Fri, 10 Jul 2009 13:15:19 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id idVN7IyW-WTG; Fri, 10 Jul 2009 13:15:19 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id EFDAFD934F; Fri, 10 Jul 2009 13:15:18 +0200 (MEST) In-Reply-To: <4A572134.2030806@net.in.tum.de> References: <20090710144529.8329.17391CF2@nttv6.net> <4A572134.2030806@net.in.tum.de> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <74D804F7-7425-47FC-80A1-4139F338D501@tik.ee.ethz.ch> Content-Transfer-Encoding: 7bit From: Brian Trammell Date: Fri, 10 Jul 2009 13:15:17 +0200 To: Gerhard Muenz X-Mailer: Apple Mail (2.753.1) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] transport mediation in IPFIX Mediation? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 11:14:54 -0000 hi Gerhard, Atsushi, everyone, We seem to be getting there... IPFIX Mediation is, in my view, an activity that takes traffic _data_ from somewhere (not traffic off the wire; that's an MP's job), _may_ change its content if necessary for the application, and sends it somewhere else _via IPFIX_. A Mediator is something that mediates. First we make sure the definitions express this; they seem to. Then we can get down to details. Which I will. Inline. :) On Jul 10, 2009, at 1:08 PM, Gerhard Muenz wrote: > > Dear Atsushi, > > Atsushi Kobayashi wrote: >> Dear all, >> >> I change the thread. I would like to ask IPFIX members. >> >> I and Gerhald are discussing terms IPFIX Mediation/IPFIX Mediaor. >> These current terms are: >> >> IPFIX Mediation >> >> IPFIX Mediation describes the manipulation and conversion of >> records for subsequent export using IPFIX, by applying >> mediation >> functions within one or more Intermediate Processes to a >> stream of >> records in an IPFIX Mediator. >> >> IPFIX Mediator >> >> An IPFIX Mediator is an IPFIX Device that provides mediation >> capabilities by receiving records from some data source, >> hosting >> zero or more Intermediate Processes to transform those records, >> and exporting those records in IPFIX Messages via an Exporting >> Process. In the common case, a Mediator receives records >> from a >> Collecting Process, but could also receive records from data >> sources not encoded using IPFIX, e.g., in the case of >> NetFlow V9 >> protocol translation. >> >> Question: >> >> Does IPFIX Mediation or an IPFIX Mediator cover the transport >> mediation, >> e.g. from IPFIX-over-UDP to IPFIX-over-SCTP ? >> >> According to above terms, we can choose in two ways: >> >> a) An IPFIX Mediator covers the transport mediation, and IPFIX >> Mediation >> does not, if an Intermediate Process does not cover the transport >> mediation. >> >> b) Both of an IPFIX Mediator and IPFIX Mediation cover the transport >> mediation, if an Intermediate Process covers the transport mediation. >> >> First of all, I believe the IPFIX Mediation covering transport >> mediation >> is already consensus regardless of whether an Intermediate Process >> covers transport mediation or not, because I presented the following >> slide in IETF73rd and there is no objection so far. >> https://www.ietf.org/proceedings/08nov/slides/ipfix-1.pdf >> >> Thus, I agree the following new term. >> >> IPFIX Mediation >> >> IPFIX Mediation is the manipulation and conversion of >> records or IPFIX Messages for subsequent export using IPFIX, >> by applying mediation functions to a stream of records, and/or >> applying transport based mediation functions to IPFIX Messages. >> >> Let me know your opinions. I will write down this feedback in new >> version drafts according to consensus as far as possible. Its >> deadline >> next monday is approaching. > > I still do not think that this is not a good definition. Especially, I > would object to the formulation "transport based mediation functions". > It is not clear what "transport based" is supposed to be. Agreed, and I'd prefer not to define them, because they're only used for this definition. > What about the following: > > IPFIX Mediation > > IPFIX Mediation is the manipulation and conversion of > records or IPFIX Messages for subsequent export using IPFIX, > by applying mediation functions to a stream of records, and/or > applying transport protocol mediation. > > Note that this corresponds much better to what is written for IPFIX > Proxy: > > IPFIX Proxy > > An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX > Messages or messages in other protocols to one or more > Collectors. > It can provide transport protocol mediation and re-encoding. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Agreed... "transport protocol mediation" is better here. Regards, Brian From root@core3.amsl.com Fri Jul 10 04:15:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CCBEC3A6DB1; Fri, 10 Jul 2009 04:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090710111501.CCBEC3A6DB1@core3.amsl.com> Date: Fri, 10 Jul 2009 04:15:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-file-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 11:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Specification of the IPFIX File Format Author(s) : B. Trammell, et al. Filename : draft-ietf-ipfix-file-04.txt Pages : 62 Date : 2009-07-10 This document describes a file format for the storage of flow data based upon the IPFIX Protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-file-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-file-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-10040415.I-D@ietf.org> --NextPart-- From Quittek@nw.neclab.eu Fri Jul 10 05:22:30 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E41F3A705B for ; Fri, 10 Jul 2009 05:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcWIsyKt7YBW for ; Fri, 10 Jul 2009 05:22:29 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A19013A6E4D for ; Fri, 10 Jul 2009 05:22:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 18F9B2C0204A6; Fri, 10 Jul 2009 13:55:08 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-iOJx+lSKHi; Fri, 10 Jul 2009 13:55:07 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id D52802C017B31; Fri, 10 Jul 2009 13:54:52 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.1.2.178 ([10.1.2.178]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Jul 2009 11:54:52 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="B_3330078903_3120780" Date: Fri, 10 Jul 2009 13:55:03 +0200 Message-ID: In-Reply-To: <74D804F7-7425-47FC-80A1-4139F338D501@tik.ee.ethz.ch> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] transport mediation in IPFIX Mediation? Thread-Index: AcoBVUJSmutYyqL6/0yHoMEWh1zGaA== From: "Juergen Quittek" To: "Brian Trammell" , "Gerhard Muenz" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] transport mediation in IPFIX Mediation? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 12:22:30 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3330078903_3120780 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, Writing as technical contributor, I am not too happy about including transport in the mediation definition. First, I think that mediation rather is a process that affects the IPFIX records and not the transport. But I know that there are many definitions for general mediation in use and not all are in line with this. However, if using different transport requires modification of IPFIX records, then we can talk about mediation, not because transport is changed, but because IPFIX records are changed. Second, using the word "transport" in the definition may be ambiguous. For example, if there is a UDP-based tunnel on the the path of an IPFIX export. Would then the tunnel endpoints be mediators? Probably, we could exclude such cases by a more complicated statement, but I would prefer to keep it simple: mediation is affecting the IPFIX records and not how records are transmitted. Third, how would we see an exporter offering different transport capabilities at the same time, for example, export to collector 1 over SNMP and to collector 2 over TCP. Would it then be correct to state that it contains a mediation function for putting its internal representation of flow records onto different transport protocols? Thanks, Juergen On 10.07.09 13:15 "Brian Trammell" wrote: > hi Gerhard, Atsushi, everyone, > > We seem to be getting there... > > IPFIX Mediation is, in my view, an activity that takes traffic _data_ > from somewhere (not traffic off the wire; that's an MP's job), _may_ > change its content if necessary for the application, and sends it > somewhere else _via IPFIX_. A Mediator is something that mediates. > First we make sure the definitions express this; they seem to. Then > we can get down to details. Which I will. Inline. :) > > On Jul 10, 2009, at 1:08 PM, Gerhard Muenz wrote: > >> >> Dear Atsushi, >> >> Atsushi Kobayashi wrote: >>> Dear all, >>> >>> I change the thread. I would like to ask IPFIX members. >>> >>> I and Gerhald are discussing terms IPFIX Mediation/IPFIX Mediaor. >>> These current terms are: >>> >>> IPFIX Mediation >>> >>> IPFIX Mediation describes the manipulation and conversion of >>> records for subsequent export using IPFIX, by applying >>> mediation >>> functions within one or more Intermediate Processes to a >>> stream of >>> records in an IPFIX Mediator. >>> >>> IPFIX Mediator >>> >>> An IPFIX Mediator is an IPFIX Device that provides mediation >>> capabilities by receiving records from some data source, >>> hosting >>> zero or more Intermediate Processes to transform those records, >>> and exporting those records in IPFIX Messages via an Exporting >>> Process. In the common case, a Mediator receives records >>> from a >>> Collecting Process, but could also receive records from data >>> sources not encoded using IPFIX, e.g., in the case of >>> NetFlow V9 >>> protocol translation. >>> >>> Question: >>> >>> Does IPFIX Mediation or an IPFIX Mediator cover the transport >>> mediation, >>> e.g. from IPFIX-over-UDP to IPFIX-over-SCTP ? >>> >>> According to above terms, we can choose in two ways: >>> >>> a) An IPFIX Mediator covers the transport mediation, and IPFIX >>> Mediation >>> does not, if an Intermediate Process does not cover the transport >>> mediation. >>> >>> b) Both of an IPFIX Mediator and IPFIX Mediation cover the transport >>> mediation, if an Intermediate Process covers the transport mediation. >>> >>> First of all, I believe the IPFIX Mediation covering transport >>> mediation >>> is already consensus regardless of whether an Intermediate Process >>> covers transport mediation or not, because I presented the following >>> slide in IETF73rd and there is no objection so far. >>> https://www.ietf.org/proceedings/08nov/slides/ipfix-1.pdf >>> >>> Thus, I agree the following new term. >>> >>> IPFIX Mediation >>> >>> IPFIX Mediation is the manipulation and conversion of >>> records or IPFIX Messages for subsequent export using IPFIX, >>> by applying mediation functions to a stream of records, and/or >>> applying transport based mediation functions to IPFIX Messages. >>> >>> Let me know your opinions. I will write down this feedback in new >>> version drafts according to consensus as far as possible. Its >>> deadline >>> next monday is approaching. >> >> I still do not think that this is not a good definition. Especially, I >> would object to the formulation "transport based mediation functions". >> It is not clear what "transport based" is supposed to be. > > Agreed, and I'd prefer not to define them, because they're only used > for this definition. > >> What about the following: >> >> IPFIX Mediation >> >> IPFIX Mediation is the manipulation and conversion of >> records or IPFIX Messages for subsequent export using IPFIX, >> by applying mediation functions to a stream of records, and/or >> applying transport protocol mediation. >> >> Note that this corresponds much better to what is written for IPFIX >> Proxy: >> >> IPFIX Proxy >> >> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX >> Messages or messages in other protocols to one or more >> Collectors. >> It can provide transport protocol mediation and re-encoding. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Agreed... "transport protocol mediation" is better here. > > Regards, > > Brian > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --B_3330078903_3120780 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename = "smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTRnE9TZtqAXIVbigV2 D17xvZgk7zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA3 MTAxMTU1MDNaMA0GCSqGSIb3DQEBAQUABIIBACp5erk74LlE5WAIo4DhkwuPU130uf4LB79U UeREerlUxuzZX85EWWJ3TJhhvKx5OmrKaWHBwFFIDwsazwAOcX58Fyw3Zn/3WSdWKsH/LFut ML6in5WBAWNmQ1IbdnFemXIyv2s7WnFwZdtKGahJ5LqFCWr/1QVPuzqWfqiIpXWbfro2bsDW OxfcldJKU50ia51q7qDOr8MAbnLs8gmUwdHiA6s5WA2+/V5l3Bx77JKri0m2YwwQOkUrKCEY BBVhjq042pg8RovoK5+q79mzkWR16RoLL4D4uO3XFWi6ivep22CalwM3oU3TAHlK17KFC8Oh X/fD1IRpw/l++Sf3rjc= --B_3330078903_3120780-- From simon.leinen@switch.ch Fri Jul 10 08:21:27 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6223A6A50 for ; Fri, 10 Jul 2009 08:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS6XVq9aOHaA for ; Fri, 10 Jul 2009 08:21:26 -0700 (PDT) Received: from diotima.switch.ch (diotima.switch.ch [IPv6:2001:620:0:4:203:baff:fe4c:d751]) by core3.amsl.com (Postfix) with ESMTP id ADBA33A6E65 for ; Fri, 10 Jul 2009 08:21:24 -0700 (PDT) Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.14.3+Sun/8.14.3) with ESMTP id n6AFLlNS020111; Fri, 10 Jul 2009 17:21:47 +0200 (CEST) Received: (from leinen@localhost) by diotima.switch.ch (8.14.3+Sun/8.14.3/Submit) id n6AFLlLr020110; Fri, 10 Jul 2009 17:21:47 +0200 (CEST) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f From: Simon Leinen To: Tobias Limmer In-Reply-To: <0441C576-8C01-4822-9670-D3A507340FF6@informatik.uni-erlangen.de> (Tobias Limmer's message of "Tue, 7 Apr 2009 14:18:54 +0200") References: <0441C576-8C01-4822-9670-D3A507340FF6@informatik.uni-erlangen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (usg-unix-v) X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Fri, 10 Jul 2009 17:21:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ipfix@ietf.org Subject: Re: [IPFIX] Vulnerabilities in Flow Meters X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 15:21:27 -0000 Sorry for responding so late. > flow meters usually employ hashtables for efficient flow > aggregation. We analyzed possible vulnerabilities of two > software-based Netflow/ IPFIX flow meters, nProbe and Vermont, from an > attacker's perspective and discovered some major problems. > We found out, that hash functions used in these hashtables are easily > exploitable. So attackers are able to decrease the meter's performance > drastically and cause packet drops on purpose. More detail is provided > in the technical report [1]. > Now my question to this list: Has anyone already investigated this > problem? What about hardware-based flow meters such as Cisco boxes? My > guess is that these are vulnerable, too. Probably, but not in exactly the way you describe in your paper. I can only talk about the hardware Netflow implementation that is used on devices such as today's Catalyst 6500 and Cisco 7600[*]. These devices have a fixed-size hash table for flows. The hash table is organized as 16384 or 32768 (depending on hardware type) rows of 8 entries each. So for each distinct hash value, up to eight flows can be stored. Flow entries are created and updated in hardware as packets are forwarded. (Flow expiry is done by a periodic process outside the forwarding path.) The hardware is designed in a way that for every packet, even at 30 Mpps, it is always possible to update the corresponding flow entry if it exists, or to create the flow entry if it doesn't exist AND IF THERE IS A FREE SLOT for the corresponding hash value. So accounting can never fail because "the flow meter is busy" (which seems to be what your paper is worried about). But it will fail if a new flow must be created, and the corresponding hash line is full. > Could you provide any information about that topic? The attack that I have been thinking about works as follows, with the particular type of flow meter implementation described above: * Alice wants to attack Bob's computer using some vulnerability. * Charlie from security has this particular type of flow meter in the path between Alice and Bob. The flow meter feeds an intrusion detection system. * Alice knows this, and wants to avoid being detected by Charlie. * Alice also knows the hash algorithm used by Charlie's flow meter. * So Alice first starts eight long-running, but low-bandwidth flows which hash to the same value as the attack flow. * Now Alice can start the real attack flow towards Bob, which will evade monitoring by Charlie's flow meter because the hash line is full. Now, the hash algorithm isn't published, so it might be difficult to construct these flows. But it should be possible with some experimentation, at least if Alice has a copy of Charlie's flow meter (same type of router) in her lab. Developing this experimental method is left as an exercise to the reader. I'm not sure whether using a cryptographic hash ALONE would be an effective countermeasure against this type of attack. If Alice has a copy of Charlie's device in her lab, and both devices use the same cryptographic hash function on the same inputs (the flow key), then Alice might still be the able to find the eight hash-busting flows experimentally using brute force. Using an unpredictable "salt" value as an additional input to the hash function would make this much more difficult. The flow meter could even change the salt from time to time, at the cost of artificially splitting some long-running flows. > [1] > X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9001228C2E0; Fri, 10 Jul 2009 12:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090710190001.9001228C2E0@core3.amsl.com> Date: Fri, 10 Jul 2009 12:00:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-export-per-sctp-stream-03.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 19:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Export per SCTP Stream Author(s) : B. Claise, et al. Filename : draft-ietf-ipfix-export-per-sctp-stream-03.txt Pages : 23 Date : 2009-07-10 This document specifies an improvement to the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol) export specified in the IP Flow Information Export (IPFIX) specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 10th, 2010. Copyright Notice Expires January 10, 2010 [page 1] Internet-Draft July 2009 Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license- info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-export-per-sctp-stream-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-10114936.I-D@ietf.org> --NextPart-- From akoba@nttv6.net Mon Jul 13 01:33:41 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20E028C1A3 for ; Mon, 13 Jul 2009 01:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncSuflfBo49L for ; Mon, 13 Jul 2009 01:33:40 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id BD1A23A6D25 for ; Mon, 13 Jul 2009 01:33:39 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:4d78:8fe0:a3c:babb]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n6D8XwM5012366; Mon, 13 Jul 2009 17:34:00 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 13 Jul 2009 17:29:35 +0900 From: Atsushi Kobayashi To: "Juergen Quittek" In-Reply-To: References: <74D804F7-7425-47FC-80A1-4139F338D501@tik.ee.ethz.ch> Message-Id: <20090713172652.8356.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 13 Jul 2009 17:34:08 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] transport mediation in IPFIX Mediation? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 08:33:41 -0000 Hi Gerhard, Brian, Juergen, and all, I recognize that you (Juergen, Brian, Gerhard) seem have a same opinion that IPFIX Mediation doesn't include transport mediation. I would like to clarify your point. Ok, I agree the document does not use ambiguous word "transport". Ok, I agree that IPFIX Mediation does not cover the transport mediation relaying IPFIX Messages directly with not changing whole of them. What about manipulating IPFIX Messages? In case of changing Observation Domain ID in IPFIX Messages, is it covered in IPFIX Mediation? I think Yes. Observation Domain ID and Export Time are subsidiary information of Data Record. Maybe they seem be included in general word "record". Thus, the manipulating IPFIX Messages is covered in IPFIX Mediator. Does it make sense? I think terms IPFIX Mediation/Mediator are as follows. IPFIX Mediation IPFIX Mediation describes the manipulation and conversion of records for subsequent export using IPFIX, by applying mediation functions to a stream of records. In my opinion, IPFIX Mediation is executed in Original Exporter as well. Thus, basically, IPFIX Mediation manipulates records. IPFIX Mediator An IPFIX Mediator is an IPFIX Device that provides mediation capabilities by receiving records from some data source, hosting zero or more Intermediate Processes to transform those records, and exporting those records in IPFIX Messages via an Exporting Process. In the common case, a Mediator receives records from a Collecting Process but could also receive records from data sources not encoded using IPFIX, e.g., in the case of NetFlow V9 protocol translation. The above term is kept in current one. In my opinion, IPFIX Mediator is separate box. Thus, IPFIX Mediator can manipulate records. and IPFIX Messages as well. It is reason for IPFIX Mediator hosting zero Intermediate Process. Regards, Atsushi On Fri, 10 Jul 2009 13:55:03 +0200 "Juergen Quittek" wrote: > Hi all, > > Writing as technical contributor, I am not too happy about including > transport in the mediation definition. > > First, I think that mediation rather is a process that affects the > IPFIX records and not the transport. But I know that there are many > definitions for general mediation in use and not all are in line > with this. However, if using different transport requires modification > of IPFIX records, then we can talk about mediation, not because > transport is changed, but because IPFIX records are changed. > > Second, using the word "transport" in the definition may be ambiguous. > For example, if there is a UDP-based tunnel on the the path of an IPFIX > export. Would then the tunnel endpoints be mediators? > Probably, we could exclude such cases by a more complicated statement, > but I would prefer to keep it simple: mediation is affecting the IPFIX > records and not how records are transmitted. > > Third, how would we see an exporter offering different transport > capabilities at the same time, for example, export to collector 1 > over SNMP and to collector 2 over TCP. Would it then be correct to > state that it contains a mediation function for putting its internal > representation of flow records onto different transport protocols? > > Thanks, > > Juergen > > > On 10.07.09 13:15 "Brian Trammell" wrote: > > > hi Gerhard, Atsushi, everyone, > > > > We seem to be getting there... > > > > IPFIX Mediation is, in my view, an activity that takes traffic _data_ > > from somewhere (not traffic off the wire; that's an MP's job), _may_ > > change its content if necessary for the application, and sends it > > somewhere else _via IPFIX_. A Mediator is something that mediates. > > First we make sure the definitions express this; they seem to. Then > > we can get down to details. Which I will. Inline. :) > > > > On Jul 10, 2009, at 1:08 PM, Gerhard Muenz wrote: > > > >> > >> Dear Atsushi, > >> > >> Atsushi Kobayashi wrote: > >>> Dear all, > >>> > >>> I change the thread. I would like to ask IPFIX members. > >>> > >>> I and Gerhald are discussing terms IPFIX Mediation/IPFIX Mediaor. > >>> These current terms are: > >>> > >>> IPFIX Mediation > >>> > >>> IPFIX Mediation describes the manipulation and conversion of > >>> records for subsequent export using IPFIX, by applying > >>> mediation > >>> functions within one or more Intermediate Processes to a > >>> stream of > >>> records in an IPFIX Mediator. > >>> > >>> IPFIX Mediator > >>> > >>> An IPFIX Mediator is an IPFIX Device that provides mediation > >>> capabilities by receiving records from some data source, > >>> hosting > >>> zero or more Intermediate Processes to transform those records, > >>> and exporting those records in IPFIX Messages via an Exporting > >>> Process. In the common case, a Mediator receives records > >>> from a > >>> Collecting Process, but could also receive records from data > >>> sources not encoded using IPFIX, e.g., in the case of > >>> NetFlow V9 > >>> protocol translation. > >>> > >>> Question: > >>> > >>> Does IPFIX Mediation or an IPFIX Mediator cover the transport > >>> mediation, > >>> e.g. from IPFIX-over-UDP to IPFIX-over-SCTP ? > >>> > >>> According to above terms, we can choose in two ways: > >>> > >>> a) An IPFIX Mediator covers the transport mediation, and IPFIX > >>> Mediation > >>> does not, if an Intermediate Process does not cover the transport > >>> mediation. > >>> > >>> b) Both of an IPFIX Mediator and IPFIX Mediation cover the transport > >>> mediation, if an Intermediate Process covers the transport mediation. > >>> > >>> First of all, I believe the IPFIX Mediation covering transport > >>> mediation > >>> is already consensus regardless of whether an Intermediate Process > >>> covers transport mediation or not, because I presented the following > >>> slide in IETF73rd and there is no objection so far. > >>> https://www.ietf.org/proceedings/08nov/slides/ipfix-1.pdf > >>> > >>> Thus, I agree the following new term. > >>> > >>> IPFIX Mediation > >>> > >>> IPFIX Mediation is the manipulation and conversion of > >>> records or IPFIX Messages for subsequent export using IPFIX, > >>> by applying mediation functions to a stream of records, and/or > >>> applying transport based mediation functions to IPFIX Messages. > >>> > >>> Let me know your opinions. I will write down this feedback in new > >>> version drafts according to consensus as far as possible. Its > >>> deadline > >>> next monday is approaching. > >> > >> I still do not think that this is not a good definition. Especially, I > >> would object to the formulation "transport based mediation functions". > >> It is not clear what "transport based" is supposed to be. > > > > Agreed, and I'd prefer not to define them, because they're only used > > for this definition. > > > >> What about the following: > >> > >> IPFIX Mediation > >> > >> IPFIX Mediation is the manipulation and conversion of > >> records or IPFIX Messages for subsequent export using IPFIX, > >> by applying mediation functions to a stream of records, and/or > >> applying transport protocol mediation. > >> > >> Note that this corresponds much better to what is written for IPFIX > >> Proxy: > >> > >> IPFIX Proxy > >> > >> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX > >> Messages or messages in other protocols to one or more > >> Collectors. > >> It can provide transport protocol mediation and re-encoding. > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Agreed... "transport protocol mediation" is better here. > > > > Regards, > > > > Brian > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From root@core3.amsl.com Mon Jul 13 05:15:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 874933A6CA4; Mon, 13 Jul 2009 05:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713121501.874933A6CA4@core3.amsl.com> Date: Mon, 13 Jul 2009 05:15:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 12:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Mediation: Problem Statement Author(s) : A. Kobayashi, et al. Filename : draft-ietf-ipfix-mediators-problem-statement-04.txt Pages : 31 Date : 2009-07-13 Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. IPFIX Mediation covers two classes of mediation: content mediation for traffic data and transport mediation for transport protocols. This document describes the IPFIX Mediation applicability examples, along with some problems that network administrators have been facing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mediators-problem-statement-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13050743.I-D@ietf.org> --NextPart-- From Quittek@nw.neclab.eu Mon Jul 13 05:28:25 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C97028C416 for ; Mon, 13 Jul 2009 05:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omVuZgEBYU88 for ; Mon, 13 Jul 2009 05:28:24 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 102E528C3DF for ; Mon, 13 Jul 2009 05:28:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 069D22C00C51C; Mon, 13 Jul 2009 14:28:09 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4op-WfdEA5UH; Mon, 13 Jul 2009 14:28:08 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id C1D622C0004E5; Mon, 13 Jul 2009 14:27:58 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.1.2.178 ([10.1.2.178]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Jul 2009 12:27:58 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="B_3330340074_2141540" Date: Mon, 13 Jul 2009 14:27:54 +0200 Message-ID: In-Reply-To: <20090713172652.8356.17391CF2@nttv6.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] transport mediation in IPFIX Mediation? Thread-Index: AcoDtVhe9nNROlvKREity9Lbp7c2qg== From: "Juergen Quittek" To: "Atsushi Kobayashi" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] transport mediation in IPFIX Mediation? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 12:28:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3330340074_2141540 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear Kobayashi-san, On 13.07.09 10:29 "Atsushi Kobayashi" wrote: > > Hi Gerhard, Brian, Juergen, and all, > > I recognize that you (Juergen, Brian, Gerhard) seem have a same opinion > that IPFIX Mediation doesn't include transport mediation. > I would like to clarify your point. > > Ok, I agree the document does not use ambiguous word "transport". > Ok, I agree that IPFIX Mediation does not cover the transport mediation > relaying IPFIX Messages directly with not changing whole of them. > > What about manipulating IPFIX Messages? > > In case of changing Observation Domain ID in IPFIX Messages, is it > covered in IPFIX Mediation? I think Yes. Agreed. Juergen --B_3330340074_2141540 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename = "smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRlfxw9Tq7LuoozJKyn AAyjizCXZzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA3 MTMxMjI3NTRaMA0GCSqGSIb3DQEBAQUABIIBAEvg1OfYPGTFc3bzh1TeBak0WAJsA4d0uahQ 8J07xF13XlsCJmm/B1vJtm/mMu6Z8hdrU4Jbi0UspY2/ey+3/lxgJsdome3VvI3EkETg0TyS ko+Don+iPcPiQ4815xWrS0XUixJlFyrHblJ1Wd7eNEkau9xwBABTUuMUCS3pYucJgWCS/ed8 VMmRuj+vfRVvAG3dPyHut6bc2b7wJ0kF41M7Jk6QpKdQAnR727tRIL/WGDjN6BDzBLbzeXIw Z97PMib6AX+H64b1XwEYBnjZu2lNZJaXzn8VkBxxyqnjYRZ7gPq2eTwQhxmJeRUkazmeELHx tDXLSBRFGMUP1MgK0vM= --B_3330340074_2141540-- From root@core3.amsl.com Mon Jul 13 06:15:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5C8A43A6DA5; Mon, 13 Jul 2009 06:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713131501.5C8A43A6DA5@core3.amsl.com> Date: Mon, 13 Jul 2009 06:15:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mib-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 13:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Definitions of Managed Objects for IP Flow Information Export Author(s) : T. Dietz, et al. Filename : draft-ietf-ipfix-mib-07.txt Pages : 67 Date : 2009-07-13 This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13061032.I-D@ietf.org> --NextPart-- From limmer@informatik.uni-erlangen.de Mon Jul 13 07:37:00 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDAA28C43D for ; Mon, 13 Jul 2009 07:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9llHv7ru3NEc for ; Mon, 13 Jul 2009 07:37:00 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 3462A28C198 for ; Mon, 13 Jul 2009 07:36:54 -0700 (PDT) Received: from faui7as (faui7as.informatik.uni-erlangen.de [131.188.37.230]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id EF45E46D6; Mon, 13 Jul 2009 16:37:15 +0200 (MEST) Received: from faui7ma3.informatik.uni-erlangen.de (faui7ma3.informatik.uni-erlangen.de [131.188.37.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by faui7as (Postfix) with ESMTPSA id C61364382CC; Mon, 13 Jul 2009 16:37:15 +0200 (CEST) From: Tobias Limmer To: Simon Leinen In-Reply-To: References: <0441C576-8C01-4822-9670-D3A507340FF6@informatik.uni-erlangen.de> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 13 Jul 2009 16:37:15 +0200 X-Mailer: Apple Mail (2.935.3) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Vulnerabilities in Flow Meters X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 14:37:00 -0000 Hi Simon, thanks for your answer, your explanations are really interesting! > So accounting can never fail because "the flow meter is busy" (which > seems to be what your paper is worried about). But it will fail if a > new flow must be created, and the corresponding hash line is full. Yes, an overload of a software-based flow meter was our main worry in =20= that paper. =10But hardware-based designs usually meet real-time =20 requirements, so often there are limitations in the system to fit the =20= requirements (as you've explained). > Now, the hash algorithm isn't published, so it might be difficult to > construct these flows. But it should be possible with some > experimentation, at least if Alice has a copy of Charlie's flow meter > (same type of router) in her lab. Developing this experimental method > is left as an exercise to the reader. Depends on the debugging interface of these routers. If we know which =20= entries in the table are used, a rather simple brute force attack may =20= deliver the desired results. Assuming that we know the hash distribution and the export time of =20 passive flows is set to 60s, only 8 packets/minute are needed to =20 conceal attacks. This value is rather good! > I'm not sure whether using a cryptographic hash ALONE would be an > effective countermeasure against this type of attack. If Alice has a > copy of Charlie's device in her lab, and both devices use the same > cryptographic hash function on the same inputs (the flow key), then > Alice might still be the able to find the eight hash-busting flows > experimentally using brute force. > Using an unpredictable "salt" value as an additional input to the hash > function would make this much more difficult. The flow meter could =20= > even > change the salt from time to time, at the cost of artificially =20 > splitting > some long-running flows. I agree. hash functions with a random salt that is regularly changed =20 (i.e. universal hash functions) would make a directed attack very =20 difficult when properly implemented and a large seed was used. But even if the hash generation function is not known (algorithm or =20 seed), a hash table size of 2^15 with 8 entries per hash index would =20 be quite small. Assuming a hash function with uniform distribution, we =20= would need only 500.000 flows (or packets) to exhaust 95% of all hash =20= indices. That translates to less than 9000 packets/s with a passive =20 timeout of 60s. Definitely noticeable for the admins of the network, =20 but the attacker's goal is achieved. Greetings, Tobi -- Dipl.-Inf. Tobias Limmer Computer Networks and Communication Systems University of Erlangen-Nuremberg, Germany WWW: http://www7.informatik.uni-erlangen.de/~limmer From root@core3.amsl.com Mon Jul 13 08:30:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4B60C3A6DC7; Mon, 13 Jul 2009 08:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713153001.4B60C3A6DC7@core3.amsl.com> Date: Mon, 13 Jul 2009 08:30:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-03.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 15:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Configuration Data Model for IPFIX and PSAMP Author(s) : G. Muenz, et al. Filename : draft-ietf-ipfix-configuration-model-03.txt Pages : 78 Date : 2009-07-13 This document specifies a data model for the configuration of selection processes, caches, exporting processes, and collecting processes of IPFIX and PSAMP compliant monitoring devices using UML (Unified Modeling Language) class diagrams. The configuration data is encoded in Extensible Markup Language (XML). The structure of the data model is specified in a YANG module to ensure compatibility with the NETCONF protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-configuration-model-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13082414.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 13 09:30:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B28083A6E21; Mon, 13 Jul 2009 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713163001.B28083A6E21@core3.amsl.com> Date: Mon, 13 Jul 2009 09:30:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-mediators-framework-03.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 16:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Mediation: Framework Author(s) : A. Kobayashi, H. Nishida, B. Claise Filename : draft-ietf-ipfix-mediators-framework-03.txt Pages : 32 Date : 2009-7-13 This document describes a framework for IPFIX Mediation. This framework details the IPFIX Mediation reference model and the components of an IPFIX Mediator. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mediators-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-7-13091545.I-D@ietf.org> --NextPart-- From nishida.haruhiko@lab.ntt.co.jp Mon Jul 13 18:48:25 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A4E3A6E89 for ; Mon, 13 Jul 2009 18:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNWYLhFo9NXe for ; Mon, 13 Jul 2009 18:48:24 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id 7B3673A6DA2 for ; Mon, 13 Jul 2009 18:48:23 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id n6E1msvu014721; Tue, 14 Jul 2009 10:48:54 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 6E8AC6AE9; Tue, 14 Jul 2009 10:48:54 +0900 (JST) Received: from iml.m.ecl.ntt.co.jp (iml0.m.ecl.ntt.co.jp [129.60.5.150]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 639706604; Tue, 14 Jul 2009 10:48:54 +0900 (JST) Received: from [129.60.149.196] ([129.60.149.196]) by iml.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id n6E1mrLM019356; Tue, 14 Jul 2009 10:48:54 +0900 (JST) Message-Id: From: Nishida Haruhiko To: Atsushi Kobayashi , IETF IPFIX Working Group In-Reply-To: <20090713172652.8356.17391CF2@nttv6.net> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 10:48:53 +0900 References: <74D804F7-7425-47FC-80A1-4139F338D501@tik.ee.ethz.ch> <20090713172652.8356.17391CF2@nttv6.net> X-Mailer: Apple Mail (2.935.3) Cc: Juergen Quittek Subject: Re: [IPFIX] transport mediation in IPFIX Mediation? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 01:48:25 -0000 all, I agree to exclude transport mediation from our scope. Juregen's comment on transport medation form UDP to TCP (or something else) is a good example. I have no intention to call it a "Mediator". One case I worried was a "Distributor", which receives (in the simplest case) one IPFIX stream and export it to a number of collectors, without any mediation on records. By definition, it is not a "Mediator" if we exclude "transport mediation". As Atsushi pointed out that if the device changes "observation domain ID" or filters some records, it is a "Mediator". And I could implement filtering function "configurable", means I can configure "just pass through" filter, then it is not a "Mediator"... I wonder whether there is a better solution, but I think I could survive. A device which could be configured as a "Mediator" should follow Mediator standards anyway. -- Haru Nishida On 2009/07/13, at 17:29, Atsushi Kobayashi wrote: > > Hi Gerhard, Brian, Juergen, and all, > > I recognize that you (Juergen, Brian, Gerhard) seem have a same opinion > that IPFIX Mediation doesn't include transport mediation. > I would like to clarify your point. > > Ok, I agree the document does not use ambiguous word "transport". > Ok, I agree that IPFIX Mediation does not cover the transport mediation > relaying IPFIX Messages directly with not changing whole of them. > > What about manipulating IPFIX Messages? > > In case of changing Observation Domain ID in IPFIX Messages, is it > covered in IPFIX Mediation? I think Yes. > > Observation Domain ID and Export Time are subsidiary information of Data > Record. Maybe they seem be included in general word "record". > Thus, the manipulating IPFIX Messages is covered in IPFIX Mediator. Does > it make sense? > > I think terms IPFIX Mediation/Mediator are as follows. > > IPFIX Mediation > > IPFIX Mediation describes the manipulation and conversion of > records for subsequent export using IPFIX, by applying mediation > functions to a stream of records. > > In my opinion, IPFIX Mediation is executed in Original Exporter as well. > Thus, basically, IPFIX Mediation manipulates records. > > IPFIX Mediator > > An IPFIX Mediator is an IPFIX Device that provides mediation > capabilities by receiving records from some data source, hosting > zero or more Intermediate Processes to transform those records, > and exporting those records in IPFIX Messages via an Exporting > Process. In the common case, a Mediator receives records from a > Collecting Process but could also receive records from data > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > protocol translation. > > The above term is kept in current one. > In my opinion, IPFIX Mediator is separate box. Thus, IPFIX Mediator can > manipulate records. and IPFIX Messages as well. It is reason for IPFIX > Mediator hosting zero Intermediate Process. > > Regards, > Atsushi > > On Fri, 10 Jul 2009 13:55:03 +0200 > "Juergen Quittek" wrote: > >> Hi all, >> >> Writing as technical contributor, I am not too happy about including >> transport in the mediation definition. >> >> First, I think that mediation rather is a process that affects the >> IPFIX records and not the transport. But I know that there are many >> definitions for general mediation in use and not all are in line >> with this. However, if using different transport requires modification >> of IPFIX records, then we can talk about mediation, not because >> transport is changed, but because IPFIX records are changed. >> >> Second, using the word "transport" in the definition may be ambiguous. >> For example, if there is a UDP-based tunnel on the the path of an IPFIX >> export. Would then the tunnel endpoints be mediators? >> Probably, we could exclude such cases by a more complicated statement, >> but I would prefer to keep it simple: mediation is affecting the IPFIX >> records and not how records are transmitted. >> >> Third, how would we see an exporter offering different transport >> capabilities at the same time, for example, export to collector 1 >> over SNMP and to collector 2 over TCP. Would it then be correct to >> state that it contains a mediation function for putting its internal >> representation of flow records onto different transport protocols? >> >> Thanks, >> >> Juergen >> >> >> On 10.07.09 13:15 "Brian Trammell" wrote: >> >>> hi Gerhard, Atsushi, everyone, >>> >>> We seem to be getting there... >>> >>> IPFIX Mediation is, in my view, an activity that takes traffic _data_ >>> from somewhere (not traffic off the wire; that's an MP's job), _may_ >>> change its content if necessary for the application, and sends it >>> somewhere else _via IPFIX_. A Mediator is something that mediates. >>> First we make sure the definitions express this; they seem to. Then >>> we can get down to details. Which I will. Inline. :) >>> >>> On Jul 10, 2009, at 1:08 PM, Gerhard Muenz wrote: >>> >>>> >>>> Dear Atsushi, >>>> >>>> Atsushi Kobayashi wrote: >>>>> Dear all, >>>>> >>>>> I change the thread. I would like to ask IPFIX members. >>>>> >>>>> I and Gerhald are discussing terms IPFIX Mediation/IPFIX Mediaor. >>>>> These current terms are: >>>>> >>>>> IPFIX Mediation >>>>> >>>>> IPFIX Mediation describes the manipulation and conversion of >>>>> records for subsequent export using IPFIX, by applying >>>>> mediation >>>>> functions within one or more Intermediate Processes to a >>>>> stream of >>>>> records in an IPFIX Mediator. >>>>> >>>>> IPFIX Mediator >>>>> >>>>> An IPFIX Mediator is an IPFIX Device that provides mediation >>>>> capabilities by receiving records from some data source, >>>>> hosting >>>>> zero or more Intermediate Processes to transform those records, >>>>> and exporting those records in IPFIX Messages via an Exporting >>>>> Process. In the common case, a Mediator receives records >>>>> from a >>>>> Collecting Process, but could also receive records from data >>>>> sources not encoded using IPFIX, e.g., in the case of >>>>> NetFlow V9 >>>>> protocol translation. >>>>> >>>>> Question: >>>>> >>>>> Does IPFIX Mediation or an IPFIX Mediator cover the transport >>>>> mediation, >>>>> e.g. from IPFIX-over-UDP to IPFIX-over-SCTP ? >>>>> >>>>> According to above terms, we can choose in two ways: >>>>> >>>>> a) An IPFIX Mediator covers the transport mediation, and IPFIX >>>>> Mediation >>>>> does not, if an Intermediate Process does not cover the transport >>>>> mediation. >>>>> >>>>> b) Both of an IPFIX Mediator and IPFIX Mediation cover the transport >>>>> mediation, if an Intermediate Process covers the transport mediation. >>>>> >>>>> First of all, I believe the IPFIX Mediation covering transport >>>>> mediation >>>>> is already consensus regardless of whether an Intermediate Process >>>>> covers transport mediation or not, because I presented the following >>>>> slide in IETF73rd and there is no objection so far. >>>>> https://www.ietf.org/proceedings/08nov/slides/ipfix-1.pdf >>>>> >>>>> Thus, I agree the following new term. >>>>> >>>>> IPFIX Mediation >>>>> >>>>> IPFIX Mediation is the manipulation and conversion of >>>>> records or IPFIX Messages for subsequent export using IPFIX, >>>>> by applying mediation functions to a stream of records, and/or >>>>> applying transport based mediation functions to IPFIX Messages. >>>>> >>>>> Let me know your opinions. I will write down this feedback in new >>>>> version drafts according to consensus as far as possible. Its >>>>> deadline >>>>> next monday is approaching. >>>> >>>> I still do not think that this is not a good definition. Especially, I >>>> would object to the formulation "transport based mediation functions". >>>> It is not clear what "transport based" is supposed to be. >>> >>> Agreed, and I'd prefer not to define them, because they're only used >>> for this definition. >>> >>>> What about the following: >>>> >>>> IPFIX Mediation >>>> >>>> IPFIX Mediation is the manipulation and conversion of >>>> records or IPFIX Messages for subsequent export using IPFIX, >>>> by applying mediation functions to a stream of records, and/or >>>> applying transport protocol mediation. >>>> >>>> Note that this corresponds much better to what is written for IPFIX >>>> Proxy: >>>> >>>> IPFIX Proxy >>>> >>>> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX >>>> Messages or messages in other protocols to one or more >>>> Collectors. >>>> It can provide transport protocol mediation and re-encoding. >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> Agreed... "transport protocol mediation" is better here. >>> >>> Regards, >>> >>> Brian >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix > > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Tue Jul 14 03:19:29 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350313A6B03 for ; Tue, 14 Jul 2009 03:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukycCw4LLI22 for ; Tue, 14 Jul 2009 03:19:23 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) by core3.amsl.com (Postfix) with ESMTP id D865828C11F for ; Tue, 14 Jul 2009 03:19:14 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id BF57F47EDE; Tue, 14 Jul 2009 12:13:08 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id A3E5150A1; Tue, 14 Jul 2009 12:13:08 +0200 (CEST) Message-ID: <4A5C5AA4.2040004@net.in.tum.de> Date: Tue, 14 Jul 2009 12:15:00 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Nishida Haruhiko References: <74D804F7-7425-47FC-80A1-4139F338D501@tik.ee.ethz.ch> <20090713172652.8356.17391CF2@nttv6.net> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060502060609080306040703" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group , Juergen Quittek Subject: Re: [IPFIX] transport mediation in IPFIX Mediation? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 10:19:29 -0000 This is a cryptographically signed message in MIME format. --------------ms060502060609080306040703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, In the MIB and in the configuration data model, we have the exportMemberType parameter. If an Exporting Process is configured with multiple export destinations, this parameter determines if the data is exported in parallel or in a load balancing fashion. In my opinion, this kind of load balancing is performed statistically without considering the message content. As an IPFIX Distributor is supposed to make more sophisticated decision regarding where to export a record, it is IPFIX Mediation requiring an Intermediate Process. At least, that's how I would interpret it. Gerhard Nishida Haruhiko wrote: > all, >=20 > I agree to exclude transport mediation from our scope.=20 > Juregen's comment on transport medation form UDP to TCP=20 > (or something else) is a good example. I have no intention to > call it a "Mediator". >=20 > One case I worried was a "Distributor", which receives (in the simplest= =20 > case) one IPFIX stream and export it to a number of collectors,=20 > without any mediation on records. By definition, it is not a "Mediator"= =20 > if we exclude "transport mediation". >=20 > As Atsushi pointed out that if the device changes "observation=20 > domain ID" or filters some records, it is a "Mediator". And I could=20 > implement filtering function "configurable", means I can configure=20 > "just pass through" filter, then it is not a "Mediator"... >=20 > I wonder whether there is a better solution, but I think I could > survive. A device which could be configured as a "Mediator" > should follow Mediator standards anyway. >=20 > -- Haru Nishida >=20 > On 2009/07/13, at 17:29, Atsushi Kobayashi wrote: >=20 >> Hi Gerhard, Brian, Juergen, and all, >> >> I recognize that you (Juergen, Brian, Gerhard) seem have a same opinio= n >> that IPFIX Mediation doesn't include transport mediation. >> I would like to clarify your point. >> >> Ok, I agree the document does not use ambiguous word "transport". >> Ok, I agree that IPFIX Mediation does not cover the transport mediatio= n >> relaying IPFIX Messages directly with not changing whole of them. >> >> What about manipulating IPFIX Messages?=20 >> >> In case of changing Observation Domain ID in IPFIX Messages, is it >> covered in IPFIX Mediation? I think Yes. >> >> Observation Domain ID and Export Time are subsidiary information of Da= ta >> Record. Maybe they seem be included in general word "record". >> Thus, the manipulating IPFIX Messages is covered in IPFIX Mediator. Do= es >> it make sense? >> >> I think terms IPFIX Mediation/Mediator are as follows. >> >> IPFIX Mediation >> >> IPFIX Mediation describes the manipulation and conversion of >> records for subsequent export using IPFIX, by applying mediatio= n >> functions to a stream of records. >> >> In my opinion, IPFIX Mediation is executed in Original Exporter as wel= l. >> Thus, basically, IPFIX Mediation manipulates records.=20 >> >> IPFIX Mediator >> >> An IPFIX Mediator is an IPFIX Device that provides mediation >> capabilities by receiving records from some data source, hosting >> zero or more Intermediate Processes to transform those records, >> and exporting those records in IPFIX Messages via an Exporting >> Process. In the common case, a Mediator receives records from a >> Collecting Process but could also receive records from data >> sources not encoded using IPFIX, e.g., in the case of NetFlow V9 >> protocol translation. >> >> The above term is kept in current one. >> In my opinion, IPFIX Mediator is separate box. Thus, IPFIX Mediator ca= n >> manipulate records. and IPFIX Messages as well. It is reason for IPFIX= >> Mediator hosting zero Intermediate Process. >> >> Regards, >> Atsushi >> >> On Fri, 10 Jul 2009 13:55:03 +0200 >> "Juergen Quittek" wrote: >> >>> Hi all, >>> >>> Writing as technical contributor, I am not too happy about including >>> transport in the mediation definition. >>> >>> First, I think that mediation rather is a process that affects the >>> IPFIX records and not the transport. But I know that there are many >>> definitions for general mediation in use and not all are in line >>> with this. However, if using different transport requires modificatio= n >>> of IPFIX records, then we can talk about mediation, not because >>> transport is changed, but because IPFIX records are changed. >>> >>> Second, using the word "transport" in the definition may be ambiguous= =2E >>> For example, if there is a UDP-based tunnel on the the path of an IPF= IX >>> export. Would then the tunnel endpoints be mediators? >>> Probably, we could exclude such cases by a more complicated statement= , >>> but I would prefer to keep it simple: mediation is affecting the IPFI= X >>> records and not how records are transmitted. >>> >>> Third, how would we see an exporter offering different transport >>> capabilities at the same time, for example, export to collector 1 >>> over SNMP and to collector 2 over TCP. Would it then be correct to >>> state that it contains a mediation function for putting its internal >>> representation of flow records onto different transport protocols? >>> >>> Thanks, >>> >>> Juergen >>> >>> >>> On 10.07.09 13:15 "Brian Trammell" wrote: >>> >>>> hi Gerhard, Atsushi, everyone, >>>> >>>> We seem to be getting there... >>>> >>>> IPFIX Mediation is, in my view, an activity that takes traffic _data= _ >>>> from somewhere (not traffic off the wire; that's an MP's job), _may_= >>>> change its content if necessary for the application, and sends it >>>> somewhere else _via IPFIX_. A Mediator is something that mediates. >>>> First we make sure the definitions express this; they seem to. Then >>>> we can get down to details. Which I will. Inline. :) >>>> >>>> On Jul 10, 2009, at 1:08 PM, Gerhard Muenz wrote: >>>> >>>>> Dear Atsushi, >>>>> >>>>> Atsushi Kobayashi wrote: >>>>>> Dear all, >>>>>> >>>>>> I change the thread. I would like to ask IPFIX members. >>>>>> >>>>>> I and Gerhald are discussing terms IPFIX Mediation/IPFIX Mediaor. >>>>>> These current terms are: >>>>>> >>>>>> IPFIX Mediation >>>>>> >>>>>> IPFIX Mediation describes the manipulation and conversion of >>>>>> records for subsequent export using IPFIX, by applying >>>>>> mediation >>>>>> functions within one or more Intermediate Processes to a >>>>>> stream of >>>>>> records in an IPFIX Mediator. >>>>>> >>>>>> IPFIX Mediator >>>>>> >>>>>> An IPFIX Mediator is an IPFIX Device that provides mediation >>>>>> capabilities by receiving records from some data source, >>>>>> hosting >>>>>> zero or more Intermediate Processes to transform those record= s, >>>>>> and exporting those records in IPFIX Messages via an Exportin= g >>>>>> Process. In the common case, a Mediator receives records >>>>>> from a >>>>>> Collecting Process, but could also receive records from data >>>>>> sources not encoded using IPFIX, e.g., in the case of >>>>>> NetFlow V9 >>>>>> protocol translation. >>>>>> >>>>>> Question: >>>>>> >>>>>> Does IPFIX Mediation or an IPFIX Mediator cover the transport >>>>>> mediation, >>>>>> e.g. from IPFIX-over-UDP to IPFIX-over-SCTP ? >>>>>> >>>>>> According to above terms, we can choose in two ways: >>>>>> >>>>>> a) An IPFIX Mediator covers the transport mediation, and IPFIX >>>>>> Mediation >>>>>> does not, if an Intermediate Process does not cover the transport >>>>>> mediation. >>>>>> >>>>>> b) Both of an IPFIX Mediator and IPFIX Mediation cover the transpo= rt >>>>>> mediation, if an Intermediate Process covers the transport mediati= on. >>>>>> >>>>>> First of all, I believe the IPFIX Mediation covering transport >>>>>> mediation >>>>>> is already consensus regardless of whether an Intermediate Process= >>>>>> covers transport mediation or not, because I presented the followi= ng >>>>>> slide in IETF73rd and there is no objection so far. >>>>>> https://www.ietf.org/proceedings/08nov/slides/ipfix-1.pdf >>>>>> >>>>>> Thus, I agree the following new term. >>>>>> >>>>>> IPFIX Mediation >>>>>> >>>>>> IPFIX Mediation is the manipulation and conversion of >>>>>> records or IPFIX Messages for subsequent export using IPFIX, >>>>>> by applying mediation functions to a stream of records, and/o= r >>>>>> applying transport based mediation functions to IPFIX Message= s. >>>>>> >>>>>> Let me know your opinions. I will write down this feedback in new >>>>>> version drafts according to consensus as far as possible. Its >>>>>> deadline >>>>>> next monday is approaching. >>>>> I still do not think that this is not a good definition. Especially= , I >>>>> would object to the formulation "transport based mediation function= s". >>>>> It is not clear what "transport based" is supposed to be. >>>> Agreed, and I'd prefer not to define them, because they're only used= >>>> for this definition. >>>> >>>>> What about the following: >>>>> >>>>> IPFIX Mediation >>>>> >>>>> IPFIX Mediation is the manipulation and conversion of >>>>> records or IPFIX Messages for subsequent export using IPFIX, >>>>> by applying mediation functions to a stream of records, and/or= >>>>> applying transport protocol mediation. >>>>> >>>>> Note that this corresponds much better to what is written for IPFIX= >>>>> Proxy: >>>>> >>>>> IPFIX Proxy >>>>> >>>>> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX >>>>> Messages or messages in other protocols to one or more >>>>> Collectors. >>>>> It can provide transport protocol mediation and re-encoding. >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> Agreed... "transport protocol mediation" is better here. >>>> >>>> Regards, >>>> >>>> Brian >>>> >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >> ---=20 >> Atsushi KOBAYASHI >> NTT Information Sharing Platform Lab. >> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms060502060609080306040703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzE0MTAxNTAxWjAjBgkqhkiG9w0BCQQxFgQU wEBb8XQemZWk9F7IzN6JLl9K1LQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAIJSQDhw5qGMK+nXxXd65NT4qRYafqFI/ETkuvXbqmqO8j0L XsW5+LdJpJpUi9m6+iIYqCf/ID7ou1gvn0VLsmyKjHusV1gIUy+PXTebGCYWooOoOD67FzMq vSG9NjL1v5/GCtwrJ9VPDJ7fcYHRtKgDcAmFyASlLvMwt+jxocQDC2dI8ZS0pjchs+uIkwFR Dq38TEVBnwMea68v+nqQcRKOUi3tRAqIcPl7FNZmjUKbYkCeQsVLNOrvgqz8NASrpwwgkmgY wsf3mYT9VhOBg/mtg9siy47QAFfRrtVJCOSGS14B7DE0gYDoN2u7t5DauQNbLIvUGxbxG3t4 nZYcNEIAAAAAAAA= --------------ms060502060609080306040703-- From trammell@tik.ee.ethz.ch Tue Jul 14 03:32:15 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40E43A6912 for ; Tue, 14 Jul 2009 03:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3AUpHfyvCRO for ; Tue, 14 Jul 2009 03:32:14 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id EBF083A6BC3 for ; Tue, 14 Jul 2009 03:32:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1AE8DD938B; Tue, 14 Jul 2009 12:24:17 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0ixTBLIsHQ1u; Tue, 14 Jul 2009 12:24:16 +0200 (MEST) Received: from [10.0.1.11] (84-75-161-38.dclient.hispeed.ch [84.75.161.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id AAC31D9362; Tue, 14 Jul 2009 12:24:16 +0200 (MEST) Message-Id: <9CEE9656-7D24-4C0F-B0C4-0025D2E8D0BD@tik.ee.ethz.ch> From: Brian Trammell To: Gerhard Muenz In-Reply-To: <4A5C5AA4.2040004@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 12:24:16 +0200 References: <74D804F7-7425-47FC-80A1-4139F338D501@tik.ee.ethz.ch> <20090713172652.8356.17391CF2@nttv6.net> <4A5C5AA4.2040004@net.in.tum.de> X-Mailer: Apple Mail (2.935.3) Cc: IETF IPFIX Working Group , Juergen Quittek Subject: Re: [IPFIX] transport mediation in IPFIX Mediation? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 10:32:15 -0000 Gerhard, I agree fully in this use case... however, this implies that an =20 Intermediate Process is not just a potentially stateful record shovel; =20= it also receives control inputs from upstream processes (e.g., the =20 identity of the exporter from which records were received), and passes =20= control outputs to downstream processes (in the distributor case, =20 which exporter to send to). Cheers, Brian On Jul 14, 2009, at 12:15 PM, Gerhard Muenz wrote: > > Hi, > > In the MIB and in the configuration data model, we have the > exportMemberType parameter. If an Exporting Process is configured with > multiple export destinations, this parameter determines if the data is > exported in parallel or in a load balancing fashion. In my opinion, =20= > this > kind of load balancing is performed statistically without considering > the message content. > > As an IPFIX Distributor is supposed to make more sophisticated =20 > decision > regarding where to export a record, it is IPFIX Mediation requiring an > Intermediate Process. At least, that's how I would interpret it. > > Gerhard > > > Nishida Haruhiko wrote: >> all, >> >> I agree to exclude transport mediation from our scope. >> Juregen's comment on transport medation form UDP to TCP >> (or something else) is a good example. I have no intention to >> call it a "Mediator". >> >> One case I worried was a "Distributor", which receives (in the =20 >> simplest >> case) one IPFIX stream and export it to a number of collectors, >> without any mediation on records. By definition, it is not a =20 >> "Mediator" >> if we exclude "transport mediation". >> >> As Atsushi pointed out that if the device changes "observation >> domain ID" or filters some records, it is a "Mediator". And I could >> implement filtering function "configurable", means I can configure >> "just pass through" filter, then it is not a "Mediator"... >> >> I wonder whether there is a better solution, but I think I could >> survive. A device which could be configured as a "Mediator" >> should follow Mediator standards anyway. >> >> -- Haru Nishida >> >> On 2009/07/13, at 17:29, Atsushi Kobayashi wrote: >> >>> Hi Gerhard, Brian, Juergen, and all, >>> >>> I recognize that you (Juergen, Brian, Gerhard) seem have a same =20 >>> opinion >>> that IPFIX Mediation doesn't include transport mediation. >>> I would like to clarify your point. >>> >>> Ok, I agree the document does not use ambiguous word "transport". >>> Ok, I agree that IPFIX Mediation does not cover the transport =20 >>> mediation >>> relaying IPFIX Messages directly with not changing whole of them. >>> >>> What about manipulating IPFIX Messages? >>> >>> In case of changing Observation Domain ID in IPFIX Messages, is it >>> covered in IPFIX Mediation? I think Yes. >>> >>> Observation Domain ID and Export Time are subsidiary information =20 >>> of Data >>> Record. Maybe they seem be included in general word "record". >>> Thus, the manipulating IPFIX Messages is covered in IPFIX =20 >>> Mediator. Does >>> it make sense? >>> >>> I think terms IPFIX Mediation/Mediator are as follows. >>> >>> IPFIX Mediation >>> >>> IPFIX Mediation describes the manipulation and conversion of >>> records for subsequent export using IPFIX, by applying =20 >>> mediation >>> functions to a stream of records. >>> >>> In my opinion, IPFIX Mediation is executed in Original Exporter as =20= >>> well. >>> Thus, basically, IPFIX Mediation manipulates records. >>> >>> IPFIX Mediator >>> >>> An IPFIX Mediator is an IPFIX Device that provides mediation >>> capabilities by receiving records from some data source, hosting >>> zero or more Intermediate Processes to transform those records, >>> and exporting those records in IPFIX Messages via an Exporting >>> Process. In the common case, a Mediator receives records from a >>> Collecting Process but could also receive records from data >>> sources not encoded using IPFIX, e.g., in the case of NetFlow V9 >>> protocol translation. >>> >>> The above term is kept in current one. >>> In my opinion, IPFIX Mediator is separate box. Thus, IPFIX =20 >>> Mediator can >>> manipulate records. and IPFIX Messages as well. It is reason for =20 >>> IPFIX >>> Mediator hosting zero Intermediate Process. >>> >>> Regards, >>> Atsushi >>> >>> On Fri, 10 Jul 2009 13:55:03 +0200 >>> "Juergen Quittek" wrote: >>> >>>> Hi all, >>>> >>>> Writing as technical contributor, I am not too happy about =20 >>>> including >>>> transport in the mediation definition. >>>> >>>> First, I think that mediation rather is a process that affects the >>>> IPFIX records and not the transport. But I know that there are many >>>> definitions for general mediation in use and not all are in line >>>> with this. However, if using different transport requires =20 >>>> modification >>>> of IPFIX records, then we can talk about mediation, not because >>>> transport is changed, but because IPFIX records are changed. >>>> >>>> Second, using the word "transport" in the definition may be =20 >>>> ambiguous. >>>> For example, if there is a UDP-based tunnel on the the path of an =20= >>>> IPFIX >>>> export. Would then the tunnel endpoints be mediators? >>>> Probably, we could exclude such cases by a more complicated =20 >>>> statement, >>>> but I would prefer to keep it simple: mediation is affecting the =20= >>>> IPFIX >>>> records and not how records are transmitted. >>>> >>>> Third, how would we see an exporter offering different transport >>>> capabilities at the same time, for example, export to collector 1 >>>> over SNMP and to collector 2 over TCP. Would it then be correct to >>>> state that it contains a mediation function for putting its =20 >>>> internal >>>> representation of flow records onto different transport protocols? >>>> >>>> Thanks, >>>> >>>> Juergen >>>> >>>> >>>> On 10.07.09 13:15 "Brian Trammell" =20 >>>> wrote: >>>> >>>>> hi Gerhard, Atsushi, everyone, >>>>> >>>>> We seem to be getting there... >>>>> >>>>> IPFIX Mediation is, in my view, an activity that takes traffic =20 >>>>> _data_ >>>>> from somewhere (not traffic off the wire; that's an MP's job), =20 >>>>> _may_ >>>>> change its content if necessary for the application, and sends it >>>>> somewhere else _via IPFIX_. A Mediator is something that mediates. >>>>> First we make sure the definitions express this; they seem to. =20 >>>>> Then >>>>> we can get down to details. Which I will. Inline. :) >>>>> >>>>> On Jul 10, 2009, at 1:08 PM, Gerhard Muenz wrote: >>>>> >>>>>> Dear Atsushi, >>>>>> >>>>>> Atsushi Kobayashi wrote: >>>>>>> Dear all, >>>>>>> >>>>>>> I change the thread. I would like to ask IPFIX members. >>>>>>> >>>>>>> I and Gerhald are discussing terms IPFIX Mediation/IPFIX =20 >>>>>>> Mediaor. >>>>>>> These current terms are: >>>>>>> >>>>>>> IPFIX Mediation >>>>>>> >>>>>>> IPFIX Mediation describes the manipulation and conversion of >>>>>>> records for subsequent export using IPFIX, by applying >>>>>>> mediation >>>>>>> functions within one or more Intermediate Processes to a >>>>>>> stream of >>>>>>> records in an IPFIX Mediator. >>>>>>> >>>>>>> IPFIX Mediator >>>>>>> >>>>>>> An IPFIX Mediator is an IPFIX Device that provides mediation >>>>>>> capabilities by receiving records from some data source, >>>>>>> hosting >>>>>>> zero or more Intermediate Processes to transform those =20 >>>>>>> records, >>>>>>> and exporting those records in IPFIX Messages via an =20 >>>>>>> Exporting >>>>>>> Process. In the common case, a Mediator receives records >>>>>>> from a >>>>>>> Collecting Process, but could also receive records from data >>>>>>> sources not encoded using IPFIX, e.g., in the case of >>>>>>> NetFlow V9 >>>>>>> protocol translation. >>>>>>> >>>>>>> Question: >>>>>>> >>>>>>> Does IPFIX Mediation or an IPFIX Mediator cover the transport >>>>>>> mediation, >>>>>>> e.g. from IPFIX-over-UDP to IPFIX-over-SCTP ? >>>>>>> >>>>>>> According to above terms, we can choose in two ways: >>>>>>> >>>>>>> a) An IPFIX Mediator covers the transport mediation, and IPFIX >>>>>>> Mediation >>>>>>> does not, if an Intermediate Process does not cover the =20 >>>>>>> transport >>>>>>> mediation. >>>>>>> >>>>>>> b) Both of an IPFIX Mediator and IPFIX Mediation cover the =20 >>>>>>> transport >>>>>>> mediation, if an Intermediate Process covers the transport =20 >>>>>>> mediation. >>>>>>> >>>>>>> First of all, I believe the IPFIX Mediation covering transport >>>>>>> mediation >>>>>>> is already consensus regardless of whether an Intermediate =20 >>>>>>> Process >>>>>>> covers transport mediation or not, because I presented the =20 >>>>>>> following >>>>>>> slide in IETF73rd and there is no objection so far. >>>>>>> https://www.ietf.org/proceedings/08nov/slides/ipfix-1.pdf >>>>>>> >>>>>>> Thus, I agree the following new term. >>>>>>> >>>>>>> IPFIX Mediation >>>>>>> >>>>>>> IPFIX Mediation is the manipulation and conversion of >>>>>>> records or IPFIX Messages for subsequent export using IPFIX, >>>>>>> by applying mediation functions to a stream of records, =20 >>>>>>> and/or >>>>>>> applying transport based mediation functions to IPFIX =20 >>>>>>> Messages. >>>>>>> >>>>>>> Let me know your opinions. I will write down this feedback in =20= >>>>>>> new >>>>>>> version drafts according to consensus as far as possible. Its >>>>>>> deadline >>>>>>> next monday is approaching. >>>>>> I still do not think that this is not a good definition. =20 >>>>>> Especially, I >>>>>> would object to the formulation "transport based mediation =20 >>>>>> functions". >>>>>> It is not clear what "transport based" is supposed to be. >>>>> Agreed, and I'd prefer not to define them, because they're only =20= >>>>> used >>>>> for this definition. >>>>> >>>>>> What about the following: >>>>>> >>>>>> IPFIX Mediation >>>>>> >>>>>> IPFIX Mediation is the manipulation and conversion of >>>>>> records or IPFIX Messages for subsequent export using IPFIX, >>>>>> by applying mediation functions to a stream of records, and/=20= >>>>>> or >>>>>> applying transport protocol mediation. >>>>>> >>>>>> Note that this corresponds much better to what is written for =20 >>>>>> IPFIX >>>>>> Proxy: >>>>>> >>>>>> IPFIX Proxy >>>>>> >>>>>> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX >>>>>> Messages or messages in other protocols to one or more >>>>>> Collectors. >>>>>> It can provide transport protocol mediation and re-encoding. >>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>> Agreed... "transport protocol mediation" is better here. >>>>> >>>>> Regards, >>>>> >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>> --- >>> Atsushi KOBAYASHI >>> NTT Information Sharing Platform Lab. >>> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > --=20 > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From Tanja.Zseby9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Wed Jul 15 03:30:48 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F433A6BC1 for ; Wed, 15 Jul 2009 03:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkiyduYMkEs2 for ; Wed, 15 Jul 2009 03:30:47 -0700 (PDT) Received: from relay04-haj2.antispameurope.com (relay04-haj2.antispameurope.com [83.246.65.54]) by core3.amsl.com (Postfix) with ESMTP id 357223A67F7 for ; Wed, 15 Jul 2009 03:30:46 -0700 (PDT) Received: by relay04-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 473955EC190; Wed, 15 Jul 2009 12:27:14 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay04-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id B41475EC190; Wed, 15 Jul 2009 12:27:13 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n6FAR9o1011732; Wed, 15 Jul 2009 12:27:10 +0200 (MEST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jul 2009 12:27:09 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA102D2D4FF@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <4A56CC57.3000004@auckland.ac.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] ***First Draft*** Agenda for Stockholm meeting Thread-Index: AcoBHGWUR0XamOIGQxmlTyNRRJ/u5QEGhOWA References: <4A56CC57.3000004@auckland.ac.nz> From: "Zseby, Tanja" To: "Nevil Brownlee" , "IPFIX Working Group" Subject: Re: [IPFIX] ***First Draft*** Agenda for Stockholm meeting X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 10:45:37 -0000 Hi Nevil, unfortunately I cannot attend IETF this time due to another meeting in = the same week. But if there is time on the agenda I would appreciate to = get 5-10 minutes for the flow selection draft. Elisa could present it on = behalf of me.=20 Kind regards Tanja > -----Urspr=FCngliche Nachricht----- > Von: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Im Auftrag > von Nevil Brownlee > Gesendet: Freitag, 10. Juli 2009 07:07 > An: IPFIX Working Group > Betreff: [IPFIX] ***First Draft*** Agenda for Stockholm meeting >=20 > Hi all: >=20 > Here's my first attempt at an agenda for the IPFIX meeting at IETF 75 > in Stockholm. Please send me any changes, suggestions for > improvements, > etc. >=20 > Thanks, Nevil >=20 > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Ip Flow Information Export WG (ipfix) > IETF #75, Stockholm > Monday, 27 July 09 at 1520-1720 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >=20 > Chairs: > Juergen Quittek > Nevil Brownlee >=20 > AGENDA: >=20 > 1. Agenda review WG Status =3D 5 min >=20 > 2. Update from last meeting =3D 3 min > a) Exporting Type Information for IPFIX IEs (Elisa Boschi) > - draft-ietf-ipfix-exporting-type-02.txt > Approved as PS, to RFC Editor 10 Jun 09 > b) Information Element Registry status > - Nevil is (slowly) working with IANA on getting the > changes made as per the current errata >=20 > 4. Drafts submitted to IESG =3D 17 min > a) IPFIX File Format (Brian Trammell) ( 3 min) > - draft-ietf-ipfix-file-03.txt 24 Oct 08 > - draft-ietf-ipfix-file-04.txt >=20 > b) IPFIX Per-Stream SCTP reporting (Benoit CLaise) ( 5 min) > - draft-ietf-ipfix-export-per-sctp-stream-02.txt 26 Jan 09 > - draft-ietf-ipfix-export-per-sctp-stream-03.txt >=20 > c) IPFIX MIB (Thomas Dietz) ( 9 min) > - draft-ietf-ipfix-mib-06.txt 9 Mar 09 > - draft-ietf-ipfix-mib-07.txt >=20 > 5. Current WG drafts =3D 50 min > b) Configuration Data Model ( 5 min) > - draft-ietf-ipfix-configuration-model-02.txt, 6 Mar 09 >=20 > c) IPFIX Mediation: (Kobayashi Atsushi) (15 min) > - draft-ietf-ipfix-mediators-problem-statement-03.txt > 30 Apr 09 > - draft-ietf-ipfix-mediators-framework-02.txt (25 min) > 11 Feb 09 >=20 > 6. Other drafts =3D 30 min > a) Handling Structured Data (Benoit Claise) > - draft-claise-structured-data-in-ipfix-01.txt (15 min) > b) VoIP Monitoring and Exporting (Sven Anderson) > - draft-huici-ipfix-sipfix-00.txt 22 Jun 09 (15 min) >=20 > 7. Any Other Drafts ??? =3D 15 min > [from last meeting: > a) Flow Selection (Lorenzo Peluso, Tanja Zseby) > - draft-peluso-flowselection-tech-02 >=20 > b) IP Flow Anonymization Support (Elisa Bschi, Brian Trammel) > - draft-boschi-ipfix-anon-02 12 Jan 09 > ] >=20 > Presentation slides will be available at >=20 > = https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D7= > 5 > (search for IPFIX in the Operations and Management Area) >=20 > Participation via jabber is offered at ipfix@jabber.ietf.org >=20 > ------------------ > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From dromasca@avaya.com Thu Jul 16 01:45:28 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424EB3A6A58; Thu, 16 Jul 2009 01:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paoJ+P4CgdLV; Thu, 16 Jul 2009 01:45:27 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id DFA843A6983; Thu, 16 Jul 2009 01:45:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,410,1243828800"; d="scan'208";a="151387453" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Jul 2009 04:45:57 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 16 Jul 2009 04:45:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jul 2009 10:45:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The curtain falls on PSAMP thread-index: AcoF8dQVtoSBlb3QQBu7AjCbXp7+kg== From: "Romascanu, Dan (Dan)" To: "IETF PSAMP Working Group" Cc: IETF IPFIX Working Group Subject: [IPFIX] The curtain falls on PSAMP X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 08:45:28 -0000 With the rechartering of IPFIX to include the PSAMP MIB work the transfer of this final item in the charter to IPFIX is concluded. I will ask the secretariat to mark PSAMP as concluded. I think that we can also shut down the mail list and manage whatever PSAMP discussions will show up on the IPFIX list. The archives will stay available in the concluded WG pages.=20 On this opportunity I would like to thank all editors, chairs and contributors to PSAMP for their work.=20 Champagne s'il vous plait! Dan From n.brownlee@auckland.ac.nz Sat Jul 18 22:48:24 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711353A6BD7 for ; Sat, 18 Jul 2009 22:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+y2ydi5aIz9 for ; Sat, 18 Jul 2009 22:48:23 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 23C383A6919 for ; Sat, 18 Jul 2009 22:48:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 603A5682814 for ; Sun, 19 Jul 2009 17:48:06 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il4Ty-l67S7M for ; Sun, 19 Jul 2009 17:48:06 +1200 (NZST) Received: from [192.168.0.6] (unknown [121.98.151.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1F729680C82 for ; Sun, 19 Jul 2009 17:48:03 +1200 (NZST) Message-ID: <4A62B393.2080005@auckland.ac.nz> Date: Sat, 18 Jul 2009 22:48:03 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Agenda for Stockholm IPFIX meeting X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 05:48:24 -0000 Hi all: Herewith the agenda - presenters, please email a .pdf of your slides to ipfix-chairs@ietf.org so that either Juergen or I can get them onto the Meeting Materials page before the session. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand ====================================================== Ip Flow Information Export WG (ipfix) IETF #75, Stockholm Monday, 27 July 09 at 1520-1720 ====================================================== Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review WG Status = 5 min 2. Update from last meeting = 3 min a) Exporting Type Information for IPFIX IEs (Elisa Boschi) - draft-ietf-ipfix-exporting-type-05.txt Approved as PS, to RFC Editor 10 Jun 09 b) Information Element Registry status - Nevil is (slowly) working with IANA on getting the changes made as per the current errata 4. Drafts submitted to IESG = 17 min a) IPFIX File Format (Brian Trammell) ( 3 min) - draft-ietf-ipfix-file-04.txt 10 Jul 09 b) IPFIX Per-Stream SCTP reporting (Benoit CLaise) ( 5 min) - draft-ietf-ipfix-export-per-sctp-stream-03.txt 10 Jul 09 c) IPFIX MIB (Thomas Dietz) ( 9 min) - draft-ietf-ipfix-mib-07.txt 13 Jul 09 5. Current WG drafts = 45 min b) Configuration Data Model ( 5 min) - draft-ietf-ipfix-configuration-model-03.txt, 17 Jul 09 c) IPFIX Mediation: (Kobayashi Atsushi) (15 min) - draft-ietf-ipfix-mediators-problem-statement-04.txt 13 Jul 09 - draft-ietf-ipfix-mediators-framework-03.txt (25 min) 13 Jul 09 6. Other drafts = 45 min a) Handling Structured Data (Benoit Claise) 26 Jun 09 - draft-claise-structured-data-in-ipfix-01.txt ( 9 min) b) VoIP Monitoring and Exporting (Sven Anderson) - draft-huici-ipfix-sipfix-00.txt 22 Jun 09 ( 9 min) c) Implementing IPFIX over DTLS (Gerhard Muenz) 6 Jul 09 - draft-mentz-ipfix-dtls-recommendations-00 ( 9 min) d) IP Flow Anonymization Support (Elisa Boschi) 10 Jul 09 - draft-boschi-ipfix-anon-04 12 Jan 09 ( 9 min) e) Flow Selection (Elisa Boschi) 2 Mar 09 - draft-peluso-flowselection-tech-02 ( 9 min) 7. Any Other Business = 5 min - Milestones Review Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=75 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org ------------------ From boschie@tik.ee.ethz.ch Mon Jul 20 04:43:26 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962FD3A683B for ; Mon, 20 Jul 2009 04:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXIQLYU7jgNt for ; Mon, 20 Jul 2009 04:43:25 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 4BD4F3A6359 for ; Mon, 20 Jul 2009 04:43:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7D91FD9391; Mon, 20 Jul 2009 13:43:20 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BpNsOGWKVdNw; Mon, 20 Jul 2009 13:43:20 +0200 (MEST) Received: from [82.130.102.89] (nb-5442.ethz.ch [82.130.102.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: boschie) by smtp.ee.ethz.ch (Postfix) with ESMTP id 45172D9373; Mon, 20 Jul 2009 13:43:20 +0200 (MEST) Message-ID: <4A645862.9030103@tik.ee.ethz.ch> Date: Mon, 20 Jul 2009 13:43:30 +0200 From: Elisa Boschi User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Nevil Brownlee , IPFIX list References: <4A62B393.2080005@auckland.ac.nz> In-Reply-To: <4A62B393.2080005@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] Agenda for Stockholm IPFIX meeting X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 13:44:59 -0000 all, a new version of the anonymisation draft is now available at: http://www.ietf.org/id/draft-boschi-ipfix-anon-04.txt Please have a look at it; we'd like to discuss its adoption as new working group item at the upcoming Stockholm meeting. Regards, Elisa Nevil Brownlee wrote: > > Hi all: > > Herewith the agenda - presenters, please email a .pdf of your > slides to ipfix-chairs@ietf.org so that either Juergen or I can > get them onto the Meeting Materials page before the session. > > Cheers, Nevil > From gowri@cisco.com Thu Jul 23 12:51:41 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA3C3A69A9; Thu, 23 Jul 2009 12:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wCPXKA33ygS; Thu, 23 Jul 2009 12:51:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BBCE13A69DE; Thu, 23 Jul 2009 12:51:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,257,1246838400"; d="scan'208,217";a="352696055" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2009 19:51:25 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6NJpP8C017726; Thu, 23 Jul 2009 12:51:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6NJpPK8006788; Thu, 23 Jul 2009 19:51:25 GMT Received: from xmb-sjc-232.amer.cisco.com ([128.107.191.41]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 12:51:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0BCE.F58A9DDA" Date: Thu, 23 Jul 2009 12:51:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Correction in draft-claise-structured-data-in-ipfix-01 Thread-Index: AcoLzvUX6wrHxgenTcSizNsbMygvTQ== From: "Gowri Dhandapani (gowri)" To: , X-OriginalArrivalTime: 23 Jul 2009 19:51:25.0137 (UTC) FILETIME=[F5F8C410:01CA0BCE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=30999; t=1248378685; x=1249242685; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gowri@cisco.com; z=From:=20=22Gowri=20Dhandapani=20(gowri)=22=20 |Subject:=20Correction=20in=20draft-claise-structured-data- in-ipfix-01=20 |Sender:=20; bh=eGj6ah51ntVGF0/gM/jW908aJENeAxYP4pdX/FAv4wo=; b=fbpgZXwYr5pnRWXAKMR/qn6Ob9Bv5YkRGDx/ufSDaxSU1hWEn+9hX3uCCA sjj9aQNeWwd0aewAuQXamxmICOz/6VsKCNUKOJwSASvvM0CxfYp3RpRHWnp/ BSBqWUOg7I; Authentication-Results: sj-dkim-3; header.From=gowri@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "Stan Yates \(syates\)" , "Brian Lam \(brlam\)" , "Zhipu Jin \(zhipjin\)" Subject: [IPFIX] Correction in draft-claise-structured-data-in-ipfix-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 19:51:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0BCE.F58A9DDA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We uncovered an encoding error in Section 8.3, 'Figure T: Encoding subTemplateMultiList, Data Set'. I have included the old and new examples for your reference here, the new example uses 2 bytes for encoding the 'Element n Length' as described in Section 4.4.3. A new version of the draft with the example corrected will be posted after the IETF meeting.=20 =20 Old:=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID =3D 261 | Length =3D 66 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signatureId =3D 1003 | protocolId=3D17 | riskRating=3D10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | participant Length =3D 55 |participant ...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Template ID=3D260| 255 |subTemplateMultiList Length=3D50 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | attacker1 Length =3D 10 | attacker1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Template ID=3D259| attacker1 sourceIPv4Address =3D | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 192.0.2.3 | attacker1 applicationId =3D | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 103 | 255 | target1 Length =3D 21 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | target1 Template ID =3D 258 |target1 destinationIPv4Address=3D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 192.0.2.103 | 255 |target1 appId..|=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |List Length=3D12 | target1 appId Field ID =3D 95 |target1 appId..| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field ID Len=3D4| target1 applicationId =3D | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 3001 | target1 applicationId =3D | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 3002 | 255 | attacker2 Length =3D 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | attacker2 Template ID =3D 259 | attacker2 srcIPv4Address =3D | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 192.0.2.4 | attacker2 applicationId =3D | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 104 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 New:=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID =3D 261 | Length =3D 63 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signatureId =3D 1003 | protocolId=3D17 | riskRating=3D10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | participant Length =3D 52 |participant ...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Template ID=3D260| 255 |subTemplateMultiList Length=3D47 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | attacker1 Length =3D 10 | attacker1 Template ID =3D 259 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | attacker1 sourceIPv4Address =3D 192.0.2.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | attacker1 applicationId =3D 103 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | target1 Length =3D 21 | target1 Template ID =3D 258 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | target1 destinationIPv4Address =3D 192.0.2.103 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | target1 appId List Length=3D12 |target1 appId..| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field ID =3D 95 | target1 appId Field ID Len =3D 4|target1 appId =3D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 3001 |target1 appId =3D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 3002 | attacker2 ...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length =3D 10 | attacker2 Template ID =3D 259 | attacker2 ...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... sourceIPv4Address =3D 192.0.2.4 | attacker2 ...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... applicationId =3D 104 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Any comments/thoughts welcome.=20 =20 Thanks. ------_=_NextPart_001_01CA0BCE.F58A9DDA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
We uncovered an encoding error in = Section=20 8.3, 'Figure T: Encoding subTemplateMultiList, Data Set'. I = have included=20 the old and new examples for your reference here, the new example uses 2 = bytes=20 for encoding the 'Element n Length' as described in Section = 4.4.3. A new=20 version of the draft with the example corrected will be posted after the = IETF=20 meeting.
 
Old:

0           &n= bsp;      =20 1           &n= bsp;      =20 2           &n= bsp;      =20 3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0=20 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

|         =20 Set ID =3D 261        =20 |        =20 Length =3D 66          =20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

|      = signatureId =3D=20 1003      =20 | protocolId=3D17 | riskRating=3D10 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

|      = 255      | =  participant Length  =3D 55     |participant = ...|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

|Template = ID=3D260|      = 255     =20 |subTemplateMultiList Length=3D50 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

|      = 255      |    attacker1 Length = =3D 10      | = attacker1 ...=20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

|Template = ID=3D259|          =20 attacker1 sourceIPv4Address =3D       = |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

| ... 192.0.2.3 = |          =20 attacker1 applicationId =3D          =20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

|  ... 103      |      = 255      |      = target1 Length =3D=20 21      = |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

| target1 Template = ID =3D=20 258     = |target1=20 destinationIPv4Address=3D|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

|    ... = 192.0.2.103           =20 |      = 255     =20 |target1 appId..|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

|List Length=3D12 | = target1=20 appId Field ID =3D 95   = |target1=20 appId..|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

| Field ID = Len=3D4|           =20 target1 applicationId =3D           =20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

|  ... 3001     |           =20 target1 applicationId =3D           =20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

|  ... 3002     |      = 255      |    attacker2 Length = =3D 10      |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

| attacker2 = Template ID =3D=20 259   | attacker2=20 srcIPv4Address =3D    = |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

|      ...=20 192.0.2.4        =20    | = attacker2=20 applicationId =3D    =20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

|       ...  104           &n= bsp;   =20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

New:

 0           &n= bsp;      =20 1           &n= bsp;      =20 2           &n= bsp;      =20 3

 0 1 = 2 3 4 5 6 7=20 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|         =20 Set ID =3D 261        =20 |        =20 Length =3D 63          =20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|      = signatureId =3D=20 1003      =20 | protocolId=3D17 | riskRating=3D10 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|      255 =      |  participant Length  =3D 52     |participant = ...|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Template ID=3D260|      = 255      |subTemplateMultiList = Length=3D47=20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|  =    attacker1 Length = =3D 10     | attacker1 = Template=20 ID =3D 259  =20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|       =20   attacker1=20 sourceIPv4Address =3D 192.0.2.3           &n= bsp; =20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|       =20        attacker1=20 applicationId =3D 103           &n= bsp;      =20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|  =     target1 Length =3D 21      |  target1 Template ID =3D = 258    = |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|    =20    target1=20 destinationIPv4Address =3D 192.0.2.103          =20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|    =20 255      =20 | target1 appId List Length=3D12 =20 |target1 appId..|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|=20 Field ID =3D 95 | target1 appId Field ID Len =3D 4|target1 appId=20 =3D|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|=20 ...           &n= bsp;       =20 3001           &n= bsp;      =20 |target1 appId =3D|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|=20 ...           &n= bsp;       =20 3002           &n= bsp;      =20 | attacker2 =20 ...|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|=20 Length =3D 10   | = attacker2=20 Template ID =3D 259   = |=20 attacker2 =20 ...|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|=20 ...   = sourceIPv4Address =3D=20 192.0.2.4          =20 | attacker2 =20 ...|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|=20 ...     =20 applicationId =3D 104           &n= bsp;     =20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

 
Any comments/thoughts welcome. =
 
Thanks.
------_=_NextPart_001_01CA0BCE.F58A9DDA-- From bclaise@cisco.com Fri Jul 24 07:08:30 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49EDD28C15D for ; Fri, 24 Jul 2009 07:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H9snIdpcGNj for ; Fri, 24 Jul 2009 07:08:28 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 297D628C0EC for ; Fri, 24 Jul 2009 07:08:28 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6OE70Xi019577; Fri, 24 Jul 2009 16:07:00 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6OE6xbE028518; Fri, 24 Jul 2009 16:06:59 +0200 (CEST) Message-ID: <4A69C003.4010507@cisco.com> Date: Fri, 24 Jul 2009 16:06:59 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Atsushi Kobayashi References: <74D804F7-7425-47FC-80A1-4139F338D501@tik.ee.ethz.ch> <20090713172652.8356.17391CF2@nttv6.net> In-Reply-To: <20090713172652.8356.17391CF2@nttv6.net> Content-Type: multipart/alternative; boundary="------------070301030304060803020106" Cc: IETF IPFIX Working Group , Juergen Quittek Subject: Re: [IPFIX] transport mediation in IPFIX Mediation? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 14:08:30 -0000 This is a multi-part message in MIME format. --------------070301030304060803020106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kobayashi-san, > Hi Gerhard, Brian, Juergen, and all, > > I recognize that you (Juergen, Brian, Gerhard) seem have a same opinion > that IPFIX Mediation doesn't include transport mediation. > I would like to clarify your point. > > Ok, I agree the document does not use ambiguous word "transport". > Ok, I agree that IPFIX Mediation does not cover the transport mediation > relaying IPFIX Messages directly with not changing whole of them. > Does it imply that we should change the abstract? Abstract Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. _IPFIX Mediation covers two classes of mediation: content mediation for traffic data and transport mediation for transport protocols. _ This document describes the IPFIX Mediation applicability examples, along with some problems that network administrators have been facing. Regards, Benoit. > What about manipulating IPFIX Messages? > > In case of changing Observation Domain ID in IPFIX Messages, is it > covered in IPFIX Mediation? I think Yes. > > Observation Domain ID and Export Time are subsidiary information of Data > Record. Maybe they seem be included in general word "record". > Thus, the manipulating IPFIX Messages is covered in IPFIX Mediator. Does > it make sense? > > I think terms IPFIX Mediation/Mediator are as follows. > > IPFIX Mediation > > IPFIX Mediation describes the manipulation and conversion of > records for subsequent export using IPFIX, by applying mediation > functions to a stream of records. > > In my opinion, IPFIX Mediation is executed in Original Exporter as well. > Thus, basically, IPFIX Mediation manipulates records. > > IPFIX Mediator > > An IPFIX Mediator is an IPFIX Device that provides mediation > capabilities by receiving records from some data source, hosting > zero or more Intermediate Processes to transform those records, > and exporting those records in IPFIX Messages via an Exporting > Process. In the common case, a Mediator receives records from a > Collecting Process but could also receive records from data > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > protocol translation. > > The above term is kept in current one. > In my opinion, IPFIX Mediator is separate box. Thus, IPFIX Mediator can > manipulate records. and IPFIX Messages as well. It is reason for IPFIX > Mediator hosting zero Intermediate Process. > > Regards, > Atsushi > > On Fri, 10 Jul 2009 13:55:03 +0200 > "Juergen Quittek" wrote: > > >> Hi all, >> >> Writing as technical contributor, I am not too happy about including >> transport in the mediation definition. >> >> First, I think that mediation rather is a process that affects the >> IPFIX records and not the transport. But I know that there are many >> definitions for general mediation in use and not all are in line >> with this. However, if using different transport requires modification >> of IPFIX records, then we can talk about mediation, not because >> transport is changed, but because IPFIX records are changed. >> >> Second, using the word "transport" in the definition may be ambiguous. >> For example, if there is a UDP-based tunnel on the the path of an IPFIX >> export. Would then the tunnel endpoints be mediators? >> Probably, we could exclude such cases by a more complicated statement, >> but I would prefer to keep it simple: mediation is affecting the IPFIX >> records and not how records are transmitted. >> >> Third, how would we see an exporter offering different transport >> capabilities at the same time, for example, export to collector 1 >> over SNMP and to collector 2 over TCP. Would it then be correct to >> state that it contains a mediation function for putting its internal >> representation of flow records onto different transport protocols? >> >> Thanks, >> >> Juergen >> >> >> On 10.07.09 13:15 "Brian Trammell" wrote: >> >> >>> hi Gerhard, Atsushi, everyone, >>> >>> We seem to be getting there... >>> >>> IPFIX Mediation is, in my view, an activity that takes traffic _data_ >>> from somewhere (not traffic off the wire; that's an MP's job), _may_ >>> change its content if necessary for the application, and sends it >>> somewhere else _via IPFIX_. A Mediator is something that mediates. >>> First we make sure the definitions express this; they seem to. Then >>> we can get down to details. Which I will. Inline. :) >>> >>> On Jul 10, 2009, at 1:08 PM, Gerhard Muenz wrote: >>> >>> >>>> Dear Atsushi, >>>> >>>> Atsushi Kobayashi wrote: >>>> >>>>> Dear all, >>>>> >>>>> I change the thread. I would like to ask IPFIX members. >>>>> >>>>> I and Gerhald are discussing terms IPFIX Mediation/IPFIX Mediaor. >>>>> These current terms are: >>>>> >>>>> IPFIX Mediation >>>>> >>>>> IPFIX Mediation describes the manipulation and conversion of >>>>> records for subsequent export using IPFIX, by applying >>>>> mediation >>>>> functions within one or more Intermediate Processes to a >>>>> stream of >>>>> records in an IPFIX Mediator. >>>>> >>>>> IPFIX Mediator >>>>> >>>>> An IPFIX Mediator is an IPFIX Device that provides mediation >>>>> capabilities by receiving records from some data source, >>>>> hosting >>>>> zero or more Intermediate Processes to transform those records, >>>>> and exporting those records in IPFIX Messages via an Exporting >>>>> Process. In the common case, a Mediator receives records >>>>> from a >>>>> Collecting Process, but could also receive records from data >>>>> sources not encoded using IPFIX, e.g., in the case of >>>>> NetFlow V9 >>>>> protocol translation. >>>>> >>>>> Question: >>>>> >>>>> Does IPFIX Mediation or an IPFIX Mediator cover the transport >>>>> mediation, >>>>> e.g. from IPFIX-over-UDP to IPFIX-over-SCTP ? >>>>> >>>>> According to above terms, we can choose in two ways: >>>>> >>>>> a) An IPFIX Mediator covers the transport mediation, and IPFIX >>>>> Mediation >>>>> does not, if an Intermediate Process does not cover the transport >>>>> mediation. >>>>> >>>>> b) Both of an IPFIX Mediator and IPFIX Mediation cover the transport >>>>> mediation, if an Intermediate Process covers the transport mediation. >>>>> >>>>> First of all, I believe the IPFIX Mediation covering transport >>>>> mediation >>>>> is already consensus regardless of whether an Intermediate Process >>>>> covers transport mediation or not, because I presented the following >>>>> slide in IETF73rd and there is no objection so far. >>>>> https://www.ietf.org/proceedings/08nov/slides/ipfix-1.pdf >>>>> >>>>> Thus, I agree the following new term. >>>>> >>>>> IPFIX Mediation >>>>> >>>>> IPFIX Mediation is the manipulation and conversion of >>>>> records or IPFIX Messages for subsequent export using IPFIX, >>>>> by applying mediation functions to a stream of records, and/or >>>>> applying transport based mediation functions to IPFIX Messages. >>>>> >>>>> Let me know your opinions. I will write down this feedback in new >>>>> version drafts according to consensus as far as possible. Its >>>>> deadline >>>>> next monday is approaching. >>>>> >>>> I still do not think that this is not a good definition. Especially, I >>>> would object to the formulation "transport based mediation functions". >>>> It is not clear what "transport based" is supposed to be. >>>> >>> Agreed, and I'd prefer not to define them, because they're only used >>> for this definition. >>> >>> >>>> What about the following: >>>> >>>> IPFIX Mediation >>>> >>>> IPFIX Mediation is the manipulation and conversion of >>>> records or IPFIX Messages for subsequent export using IPFIX, >>>> by applying mediation functions to a stream of records, and/or >>>> applying transport protocol mediation. >>>> >>>> Note that this corresponds much better to what is written for IPFIX >>>> Proxy: >>>> >>>> IPFIX Proxy >>>> >>>> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX >>>> Messages or messages in other protocols to one or more >>>> Collectors. >>>> It can provide transport protocol mediation and re-encoding. >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> >>> Agreed... "transport protocol mediation" is better here. >>> >>> Regards, >>> >>> Brian >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>> > > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------070301030304060803020106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kobayashi-san,
Hi Gerhard, Brian, Juergen, and all,

I recognize that you (Juergen, Brian, Gerhard) seem have a same opinion
that IPFIX Mediation doesn't include transport mediation.
I would like to clarify your point.

Ok, I agree the document does not use ambiguous word "transport".
Ok, I agree that IPFIX Mediation does not cover the transport mediation
relaying IPFIX Messages directly with not changing whole of them.
Does it imply that we should change the abstract?
Abstract

   Flow-based measurement is a popular method for various network
   monitoring usages.  The sharing of flow-based information for
   monitoring applications having different requirements raises some
   open issues in terms of measurement system scalability, flow-based
   measurement flexibility, and export reliability that IPFIX Mediation
   may help resolve.  IPFIX Mediation covers two classes of mediation:
   content mediation for traffic data and transport mediation for
   transport protocols.  This document describes the IPFIX Mediation
   applicability examples, along with some problems that network
   administrators have been facing.
Regards, Benoit.
What about manipulating IPFIX Messages? 

In case of changing Observation Domain ID in IPFIX Messages, is it
covered in IPFIX Mediation? I think Yes.

Observation Domain ID and Export Time are subsidiary information of Data
Record. Maybe they seem be included in general word "record".
Thus, the manipulating IPFIX Messages is covered in IPFIX Mediator. Does
it make sense?

I think terms IPFIX Mediation/Mediator are as follows.

    IPFIX Mediation

        IPFIX Mediation describes the manipulation and conversion of
        records for subsequent export using IPFIX, by applying mediation
        functions to a stream of records.

In my opinion, IPFIX Mediation is executed in Original Exporter as well.
Thus, basically, IPFIX Mediation manipulates records. 

   IPFIX Mediator

      An IPFIX Mediator is an IPFIX Device that provides mediation
      capabilities by receiving records from some data source, hosting
      zero or more Intermediate Processes to transform those records,
      and exporting those records in IPFIX Messages via an Exporting
      Process.  In the common case, a Mediator receives records from a
      Collecting Process but could also receive records from data
      sources not encoded using IPFIX, e.g., in the case of NetFlow V9
      protocol translation.

The above term is kept in current one.
In my opinion, IPFIX Mediator is separate box. Thus, IPFIX Mediator can
manipulate records. and IPFIX Messages as well. It is reason for IPFIX
Mediator hosting zero Intermediate Process.

Regards,
Atsushi

On Fri, 10 Jul 2009 13:55:03 +0200
"Juergen Quittek" <Quittek@nw.neclab.eu> wrote:

  
Hi all,

Writing as technical contributor, I am not too happy about including
transport in the mediation definition.

First, I think that mediation rather is a process that affects the
IPFIX records and not the transport. But I know that there are many
definitions for general mediation in use and not all are in line
with this. However, if using different transport requires modification
of IPFIX records, then we can talk about mediation, not because
transport is changed, but because IPFIX records are changed.

Second, using the word "transport" in the definition may be ambiguous.
For example, if there is a UDP-based tunnel on the the path of an IPFIX
export. Would then the tunnel endpoints be mediators?
Probably, we could exclude such cases by a more complicated statement,
but I would prefer to keep it simple: mediation is affecting the IPFIX
records and not how records are transmitted.

Third, how would we see an exporter offering different transport
capabilities at the same time, for example, export to collector 1
over SNMP and to collector 2 over TCP. Would it then be correct to
state that it contains a mediation function for putting its internal
representation of flow records onto different transport protocols?

Thanks,

    Juergen


On 10.07.09 13:15  "Brian Trammell" <trammell@tik.ee.ethz.ch> wrote:

    
hi Gerhard, Atsushi, everyone,

We seem to be getting there...

IPFIX Mediation is, in my view, an activity that takes traffic _data_
from somewhere (not traffic off the wire; that's an MP's job), _may_
change its content if necessary for the application, and sends it
somewhere else _via IPFIX_. A Mediator is something that mediates.
First we make sure the definitions express this; they seem to. Then
we can get down to details. Which I will. Inline. :)

On Jul 10, 2009, at 1:08 PM, Gerhard Muenz wrote:

      
Dear Atsushi,

Atsushi Kobayashi wrote:
        
Dear all,

I change the thread. I would like to ask IPFIX members.

I and Gerhald are discussing terms IPFIX Mediation/IPFIX Mediaor.
These current terms are:

   IPFIX Mediation

      IPFIX Mediation describes the manipulation and conversion of
      records for subsequent export using IPFIX, by applying
mediation
      functions within one or more Intermediate Processes to a
stream of
      records in an IPFIX Mediator.

   IPFIX Mediator

      An IPFIX Mediator is an IPFIX Device that provides mediation
      capabilities by receiving records from some data source,
hosting
      zero or more Intermediate Processes to transform those records,
      and exporting those records in IPFIX Messages via an Exporting
      Process.  In the common case, a Mediator receives records
from a
      Collecting Process, but could also receive records from data
      sources not encoded using IPFIX, e.g., in the case of
NetFlow V9
      protocol translation.

Question:

Does IPFIX Mediation or an IPFIX Mediator cover the transport
mediation,
e.g. from IPFIX-over-UDP to IPFIX-over-SCTP ?

According to above terms, we can choose in two ways:

a) An IPFIX Mediator covers the transport mediation, and IPFIX
Mediation
does not, if an Intermediate Process does not cover the transport
mediation.

b) Both of an IPFIX Mediator and IPFIX Mediation cover the transport
mediation, if an Intermediate Process covers the transport mediation.

First of all, I believe the IPFIX Mediation covering transport
mediation
is already consensus regardless of whether an Intermediate Process
covers transport mediation or not, because I presented the following
slide in IETF73rd and there is no objection so far.
https://www.ietf.org/proceedings/08nov/slides/ipfix-1.pdf

Thus, I agree the following new term.

   IPFIX Mediation

      IPFIX Mediation is the manipulation and conversion of
      records or IPFIX Messages for subsequent export using IPFIX,
      by applying mediation functions to a stream of records, and/or
      applying transport based mediation functions to IPFIX Messages.

Let me know your opinions. I will write down this feedback in new
version drafts according to consensus as far as possible. Its
deadline
next monday is approaching.
          
I still do not think that this is not a good definition. Especially, I
would object to the formulation "transport based mediation functions".
It is not clear what "transport based" is supposed to be.
        
Agreed, and I'd prefer not to define them, because they're only used
for this definition.

      
What about the following:

   IPFIX Mediation

      IPFIX Mediation is the manipulation and conversion of
      records or IPFIX Messages for subsequent export using IPFIX,
      by applying mediation functions to a stream of records, and/or
      applying transport protocol mediation.

Note that this corresponds much better to what is written for IPFIX
Proxy:

  IPFIX Proxy

     An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX
     Messages or messages in other protocols to one or more
Collectors.
     It can provide transport protocol mediation and re-encoding.
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        
Agreed... "transport protocol mediation" is better here.

Regards,

Brian

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
      

--- 
Atsushi KOBAYASHI  <akoba@nttv6.net>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------070301030304060803020106-- From morariu@ifi.uzh.ch Fri Jul 24 04:06:19 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549FA3A6A56 for ; Fri, 24 Jul 2009 04:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCMeimb5iGtG for ; Fri, 24 Jul 2009 04:06:18 -0700 (PDT) Received: from nikolai.ifi.uzh.ch (nikolai.ifi.uzh.ch [130.60.155.10]) by core3.amsl.com (Postfix) with ESMTP id 8ADE63A6A40 for ; Fri, 24 Jul 2009 04:06:18 -0700 (PDT) Received: from authenticated sender morariu by nikolai.ifi.uzh.ch (postfix) with ESMTP id 946EA2A6DAE; Fri, 24 Jul 2009 13:06:18 +0200 (CEST) Message-ID: <4A6995A8.80102@ifi.uzh.ch> Date: Fri, 24 Jul 2009 13:06:16 +0200 From: Cristian Morariu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20090710144529.8329.17391CF2@nttv6.net> In-Reply-To: <20090710144529.8329.17391CF2@nttv6.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9610/Fri Jul 24 04:11:48 2009 on nikolai.ifi.uzh.ch X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 24 Jul 2009 09:03:16 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] Mediation Problem Statement X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 11:06:19 -0000 Hi, there is an editing error in draft-ietf-ipfix-mediators-problem-statement-04 in the IPFIX Concentrator definition: IPFIX Concentrator An IPFIX Distributor is an IPFIX Mediator that receives data from ^^^^^^^^^^^ one or more Exporters and sends them to one or more Collectors, deciding which Collector(s) to send each record to based upon the decision of an Intermediate Process. IPFIX Distributor An IPFIX Distributor is an IPFIX Mediator that receives data from one or more Exporters and sends them to one or more Collectors, deciding which Collector(s) to send each record to based upon the decision of an Intermediate Process. Version 3 of the draft reads fine that section. Regards, Cristian Morariu From akoba@nttv6.net Sun Jul 26 06:51:51 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0B93A6A63 for ; Sun, 26 Jul 2009 06:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdTireen4KTs for ; Sun, 26 Jul 2009 06:51:51 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id A59743A6A2C for ; Sun, 26 Jul 2009 06:51:50 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:293b:2446:63c:e81b]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n6QDpmhv005771; Sun, 26 Jul 2009 22:51:49 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sun, 26 Jul 2009 22:46:39 +0900 From: Atsushi Kobayashi To: Cristian Morariu In-Reply-To: <4A6995A8.80102@ifi.uzh.ch> References: <20090710144529.8329.17391CF2@nttv6.net> <4A6995A8.80102@ifi.uzh.ch> Message-Id: <20090726222805.403B.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Sun, 26 Jul 2009 22:51:49 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Mediation Problem Statement X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 13:51:51 -0000 Dear Cristian, oops, I will correct it. Thank you! Regards, Atsushi On Fri, 24 Jul 2009 13:06:16 +0200 Cristian Morariu wrote: > Hi, > > there is an editing error in > draft-ietf-ipfix-mediators-problem-statement-04 in the IPFIX > Concentrator definition: > > IPFIX Concentrator > > An IPFIX Distributor is an IPFIX Mediator that receives data from > ^^^^^^^^^^^ > one or more Exporters and sends them to one or more Collectors, > deciding which Collector(s) to send each record to based upon the > decision of an Intermediate Process. > > IPFIX Distributor > > An IPFIX Distributor is an IPFIX Mediator that receives data from > one or more Exporters and sends them to one or more Collectors, > deciding which Collector(s) to send each record to based upon the > decision of an Intermediate Process. > > > Version 3 of the draft reads fine that section. > > Regards, > Cristian Morariu --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From vkg@alcatel-lucent.com Sun Jul 26 14:41:49 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464AF3A6AD2; Sun, 26 Jul 2009 14:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQd393EH7c22; Sun, 26 Jul 2009 14:41:48 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 0A9CA3A6A0D; Sun, 26 Jul 2009 14:41:47 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n6QLfmO1019824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Jul 2009 16:41:48 -0500 (CDT) Received: from shoonya.ih.lucent.com (guard.research.bell-labs.com [135.104.2.9]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n6QLfh5b000704; Sun, 26 Jul 2009 16:41:44 -0500 (CDT) Message-ID: <4A6CCDC3.5030502@alcatel-lucent.com> Date: Sun, 26 Jul 2009 16:42:27 -0500 From: Vijay Gurbani User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "sip-clf@ietf.org" Subject: [IPFIX] SIP CLF work to be presented in opsarea meeting X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 21:41:49 -0000 Hello: In the RAI area, we will be starting work on the definition of a SIP Common Log Format (CLF) -- this is essentially a summary of a SIP packet in a well-defined format produced by a SIP actor (user agent client, user agent server, proxy, etc.) that is saved to some persistent store. We will be making a presentation on this work at the opsarea meeting on Thursday, 1300-1500. This email is to kindly request interested folks from ipfix to attend the opsarea meeting as we discuss whether existing protocols can aid in SIP CLF work. Thank you, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://ect.bell-labs.com/who/vkg From web-usrn@ISI.EDU Sun Jul 26 15:42:00 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDDDF3A688C for ; Sun, 26 Jul 2009 15:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.565 X-Spam-Level: X-Spam-Status: No, score=-16.565 tagged_above=-999 required=5 tests=[AWL=1.034, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoMCev+1+x75 for ; Sun, 26 Jul 2009 15:42:00 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 252383A683C for ; Sun, 26 Jul 2009 15:42:00 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n6QMfFjU000827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 26 Jul 2009 15:41:16 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n6QMfENE000826; Sun, 26 Jul 2009 15:41:14 -0700 (PDT) Date: Sun, 26 Jul 2009 15:41:14 -0700 (PDT) Message-Id: <200907262241.n6QMfENE000826@boreas.isi.edu> To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@netlab.nec.de From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (1818) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 22:42:01 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=1818 -------------------------------------- Type: Editorial Reported by: Benoit Claise Section: All Original Text ------------- Corrected Text -------------- Notes ----- Throughout the document, all instances of "Option Template" must be replaced by "Options Template" Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From akoba@nttv6.net Sun Jul 26 21:37:34 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857923A6AC0 for ; Sun, 26 Jul 2009 21:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.245 X-Spam-Level: X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[AWL=-2.355, BAYES_00=-2.599, HELO_EQ_LOCALHOST=0.457, HELO_LOCALHOST=3.941, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hfwxET3KEnQ for ; Sun, 26 Jul 2009 21:37:31 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 66CC73A69BF for ; Sun, 26 Jul 2009 21:37:31 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n6R4bQEZ029765 for ; Mon, 27 Jul 2009 13:37:30 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 27 Jul 2009 13:37:32 +0900 From: Atsushi Kobayashi To: ipfix@ietf.org Message-Id: <20090727124958.66FA.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [192.16.178.5]); Mon, 27 Jul 2009 13:37:31 +0900 (JST) Subject: [IPFIX] IPFIX Mediation terminologies again X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 04:37:34 -0000 Dear Gerhard, Brian, Benoit, and all After my much thought and Gerhard suggestion, I think that current terminologies need some minor changes. I will appreciate your reviewing them in prior to the meeting. Sorry for long mail. OLD (-04) IPFIX Mediation IPFIX Mediation is the manipulation and conversion of records for subsequent export using IPFIX, by applying mediation functions to a stream of records. - Manipulation of records seem not include selection function. According to PSAMP Selection Process, it say "a stream of records" instead of "records." - I think first reader maybe wonder what mediation functions indicate. We can remove the last sentense. NEW IPFIX Mediation IPFIX Mediation is the manipulation and conversion of a stream of records for subsequent export using IPFIX. OLD (-04) Intermediate Process An Intermediate Process takes a sequence of records from a Collecting Process, Metering Process, IPFIX File Reader, or another Intermediate Process; performs some transformation on these records based upon the content of the records themselves, keeps state across multiple records, configuration parameters, or other data; and passes a sequence of transformed records on to an Exporting Process, IPFIX File Writer, or another Intermediate Process. Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter. - There is no description regarding IPFIX Mediation. - Configuration parameters are covered in other data. Maybe we can remove this. - I found typo "keeps state", it will be replaced with "kept state". NEW Intermediate Process An Intermediate Process implements functions of IPFIX Mediation. It takes a stream of records as its input from a Collecting Process, Metering Process, IPFIX File Reader, or another Intermediate Process; performs some transformation on these records based upon the content of the records themselves, kept state across multiple records, or other data; and passes a stream of transformed records as its output on to an Exporting Process, IPFIX File Writer, or another Intermediate Process. Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter. OLD (-04) IPFIX Mediator An IPFIX Mediator is an IPFIX Device that provides mediation capabilities by receiving records from some data source, hosting zero or more Intermediate Processes to transform those records, and exporting those records in IPFIX Messages via an Exporting Process. In the common case, an IPFIX Mediator receives records from a Collecting Process but could also receive records from data sources not encoded using IPFIX, e.g., in the case of NetFlow V9 protocol translation. - Which case is considered in zero Intermediate Process? Regarding transport protocol mediation, we concluded simple relaying UDP-to-UDP is not IPFIX Mediation. However, relaying UDP-to-SCTP needs some function to manipulate IPFIX Messages. For example, Exporting Process needs to send Template Withdrawal Messages, when a Collecting Process detects refresh time out of Template. I think that an Intermediate Process can give the trigger to Exporting Process. In my conclusion, zero Intermediate Process means not IPFIX Mediation. NEW IPFIX Mediator An IPFIX Mediator is an IPFIX Device that provides mediation capabilities by receiving records from some data source, hosting one or more Intermediate Processes to transform those records, and exporting those records in IPFIX Messages via an Exporting Process. In the common case, an IPFIX Mediator receives records from a Collecting Process but could also receive records from data sources not encoded using IPFIX, e.g., in the case of NetFlow V9 protocol translation. Regards, Atsushi -- Atsushi Kobayashi From trammell@tik.ee.ethz.ch Sun Jul 26 23:00:15 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0B53A6898 for ; Sun, 26 Jul 2009 23:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU7ND7GC6ck9 for ; Sun, 26 Jul 2009 23:00:14 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 9866B3A682E for ; Sun, 26 Jul 2009 23:00:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2D49DD934D; Mon, 27 Jul 2009 08:00:14 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id O5jhfNN557nk; Mon, 27 Jul 2009 08:00:14 +0200 (MEST) Received: from [10.43.1.226] (unknown [212.112.167.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id AB2D2D9307; Mon, 27 Jul 2009 08:00:13 +0200 (MEST) Message-Id: <68C3A7FA-1002-434A-BF36-FB158824FA5D@tik.ee.ethz.ch> From: Brian Trammell To: Atsushi Kobayashi In-Reply-To: <20090727124958.66FA.17391CF2@nttv6.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 08:00:13 +0200 References: <20090727124958.66FA.17391CF2@nttv6.net> X-Mailer: Apple Mail (2.935.3) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX Mediation terminologies again X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 06:00:15 -0000 hi Atsushi, all: replies inline. On Jul 27, 2009, at 6:37 AM, Atsushi Kobayashi wrote: > Dear Gerhard, Brian, Benoit, and all > > After my much thought and Gerhard suggestion, I think that current > terminologies need some minor changes. I will appreciate your > reviewing > them in prior to the meeting. Sorry for long mail. > > OLD (-04) > > IPFIX Mediation > > IPFIX Mediation is the manipulation and conversion of records for > subsequent export using IPFIX, by applying mediation functions to > a stream of records. > > - Manipulation of records seem not include selection function. > According > to PSAMP Selection Process, it say "a stream of records" instead of > "records." > - I think first reader maybe wonder what mediation functions indicate. > We can remove the last sentense. > > NEW > > IPFIX Mediation > > IPFIX Mediation is the manipulation and conversion of a stream of > records for subsequent export using IPFIX. Looks good. > OLD (-04) > > Intermediate Process > > An Intermediate Process takes a sequence of records from a > Collecting Process, Metering Process, IPFIX File Reader, or > another Intermediate Process; performs some transformation on > these records based upon the content of the records themselves, > keeps state across multiple records, configuration parameters, or > other data; and passes a sequence of transformed records on to an > Exporting Process, IPFIX File Writer, or another Intermediate > Process. Typically, an Intermediate Process is hosted by an > IPFIX > Mediator. Alternatively, an Intermediate Process may be hosted > by > an Original Exporter. > > - There is no description regarding IPFIX Mediation. Why does the IntP definition need to say anything explicitly about mediation? It's obvious, to me anyway, from the fact that it's defined in the mediation document, and that it is hosted in a Mediator/OE... > - Configuration parameters are covered in other data. Maybe we can > remove this. Good point. > - I found typo "keeps state", it will be replaced with "kept state". This is not an error; "keeps state" is in present tense in parallel with all other clauses in the list, and properly spelled. If the wording is confusing, suggest "maintains state" instead. > > NEW > > Intermediate Process > > An Intermediate Process implements functions of IPFIX Mediation. > It takes a stream of records as its input from a Collecting > Process, Metering Process, IPFIX File Reader, or another > Intermediate Process; performs some transformation on these > records based upon the content of the records themselves, kept > state across multiple records, or other data; and passes a stream > of transformed records as its output on to an Exporting Process, > IPFIX File Writer, or another Intermediate Process. > Typically, an Intermediate Process is hosted by an IPFIX > Mediator. > Alternatively, an Intermediate Process may be hosted by > an Original Exporter. > > OLD (-04) > > IPFIX Mediator > > An IPFIX Mediator is an IPFIX Device that provides mediation > capabilities by receiving records from some data source, hosting > zero or more Intermediate Processes to transform those records, > and exporting those records in IPFIX Messages via an Exporting > Process. In the common case, an IPFIX Mediator receives records > from a Collecting Process but could also receive records from > data > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > protocol translation. > > - Which case is considered in zero Intermediate Process? > Regarding transport protocol mediation, we concluded simple relaying > UDP-to-UDP is not IPFIX Mediation. However, relaying UDP-to-SCTP needs > some function to manipulate IPFIX Messages. For example, Exporting > Process needs to send Template Withdrawal Messages, when a Collecting > Process detects refresh time out of Template. I think that an > Intermediate Process can give the trigger to Exporting Process. > In my conclusion, zero Intermediate Process means not IPFIX Mediation. > > NEW > > IPFIX Mediator > > An IPFIX Mediator is an IPFIX Device that provides mediation > capabilities by receiving records from some data source, hosting > one or more Intermediate Processes to transform those records, > and exporting those records in IPFIX Messages via an Exporting > Process. In the common case, an IPFIX Mediator receives records > from a Collecting Process but could also receive records from > data > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > protocol translation. This is still not accurate; it is entirely possible (i.e. distributor use case) that the records are not transformed, only rerouted. If we insist on requiring 1..n multiplicity on IntP in a Mediator, then suggest "hosting one or more Intermediate Processes to process those records"... Regards, Brian From akoba@nttv6.net Sun Jul 26 23:59:46 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252233A698F for ; Sun, 26 Jul 2009 23:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.932 X-Spam-Level: X-Spam-Status: No, score=0.932 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_00=-2.599, HELO_EQ_LOCALHOST=0.457, HELO_LOCALHOST=3.941, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+ZC-GwfW-Kn for ; Sun, 26 Jul 2009 23:59:45 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id DBAAD3A6906 for ; Sun, 26 Jul 2009 23:59:43 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n6R6xei4030594; Mon, 27 Jul 2009 15:59:42 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 27 Jul 2009 15:59:44 +0900 From: Atsushi Kobayashi To: Brian Trammell In-Reply-To: <68C3A7FA-1002-434A-BF36-FB158824FA5D@tik.ee.ethz.ch> References: <20090727124958.66FA.17391CF2@nttv6.net> <68C3A7FA-1002-434A-BF36-FB158824FA5D@tik.ee.ethz.ch> Message-Id: <20090727153415.66FD.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [192.16.178.5]); Mon, 27 Jul 2009 15:59:43 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX Mediation terminologies again X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 06:59:46 -0000 Hi Brian, and all, On Mon, 27 Jul 2009 08:00:13 +0200 Brian Trammell wrote: > hi Atsushi, all: > > replies inline. > > On Jul 27, 2009, at 6:37 AM, Atsushi Kobayashi wrote: > > > Dear Gerhard, Brian, Benoit, and all > > > > After my much thought and Gerhard suggestion, I think that current > > terminologies need some minor changes. I will appreciate your > > reviewing > > them in prior to the meeting. Sorry for long mail. > > > > OLD (-04) > > > > IPFIX Mediation > > > > IPFIX Mediation is the manipulation and conversion of records for > > subsequent export using IPFIX, by applying mediation functions to > > a stream of records. > > > > - Manipulation of records seem not include selection function. > > According > > to PSAMP Selection Process, it say "a stream of records" instead of > > "records." > > - I think first reader maybe wonder what mediation functions indicate. > > We can remove the last sentense. > > > > NEW > > > > IPFIX Mediation > > > > IPFIX Mediation is the manipulation and conversion of a stream of > > records for subsequent export using IPFIX. > > Looks good. > > > OLD (-04) > > > > Intermediate Process > > > > An Intermediate Process takes a sequence of records from a > > Collecting Process, Metering Process, IPFIX File Reader, or > > another Intermediate Process; performs some transformation on > > these records based upon the content of the records themselves, > > keeps state across multiple records, configuration parameters, or > > other data; and passes a sequence of transformed records on to an > > Exporting Process, IPFIX File Writer, or another Intermediate > > Process. Typically, an Intermediate Process is hosted by an > > IPFIX > > Mediator. Alternatively, an Intermediate Process may be hosted > > by > > an Original Exporter. > > > > - There is no description regarding IPFIX Mediation. > > Why does the IntP definition need to say anything explicitly about > mediation? It's obvious, to me anyway, from the fact that it's defined > in the mediation document, and that it is hosted in a Mediator/OE... > Sorry for lack of explanation. The current IntP takes a stream of record as its input and transmits a stream of records as its output. In below case, IntP gives the trigger to Exporting Process to send Withdrawal Message rather than manipulating a stream of records. So, although we can define another Process, I think it is better to avoid creating new Process. IntP can execute other function related to template or IPFIX Messages by adding the first sentence. Does it make sense? > > - Configuration parameters are covered in other data. Maybe we can > > remove this. > > Good point. > > > - I found typo "keeps state", it will be replaced with "kept state". > > This is not an error; "keeps state" is in present tense in parallel > with all other clauses in the list, and properly spelled. If the > wording is confusing, suggest "maintains state" instead. > Does it need a semicolon before "keeps state"? An Intermediate Process takes a sequence of records from a Collecting Process, Metering Process, IPFIX File Reader, or another Intermediate Process; performs some transformation on these records based upon the content of the records themselves; keeps state across multiple records, ^^^^^^^^^^^^^^^^^^^^^^^^ > > > > NEW > > > > Intermediate Process > > > > An Intermediate Process implements functions of IPFIX Mediation. > > It takes a stream of records as its input from a Collecting > > Process, Metering Process, IPFIX File Reader, or another > > Intermediate Process; performs some transformation on these > > records based upon the content of the records themselves, kept > > state across multiple records, or other data; and passes a stream > > of transformed records as its output on to an Exporting Process, > > IPFIX File Writer, or another Intermediate Process. > > Typically, an Intermediate Process is hosted by an IPFIX > > Mediator. > > Alternatively, an Intermediate Process may be hosted by > > an Original Exporter. > > > > OLD (-04) > > > > IPFIX Mediator > > > > An IPFIX Mediator is an IPFIX Device that provides mediation > > capabilities by receiving records from some data source, hosting > > zero or more Intermediate Processes to transform those records, > > and exporting those records in IPFIX Messages via an Exporting > > Process. In the common case, an IPFIX Mediator receives records > > from a Collecting Process but could also receive records from > > data > > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > > protocol translation. > > > > - Which case is considered in zero Intermediate Process? > > Regarding transport protocol mediation, we concluded simple relaying > > UDP-to-UDP is not IPFIX Mediation. However, relaying UDP-to-SCTP needs > > some function to manipulate IPFIX Messages. For example, Exporting > > Process needs to send Template Withdrawal Messages, when a Collecting > > Process detects refresh time out of Template. I think that an > > Intermediate Process can give the trigger to Exporting Process. > > In my conclusion, zero Intermediate Process means not IPFIX Mediation. > > > > NEW > > > > IPFIX Mediator > > > > An IPFIX Mediator is an IPFIX Device that provides mediation > > capabilities by receiving records from some data source, hosting > > one or more Intermediate Processes to transform those records, > > and exporting those records in IPFIX Messages via an Exporting > > Process. In the common case, an IPFIX Mediator receives records > > from a Collecting Process but could also receive records from > > data > > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > > protocol translation. > > This is still not accurate; it is entirely possible (i.e. distributor > use case) that the records are not transformed, only rerouted. If we > insist on requiring 1..n multiplicity on IntP in a Mediator, then > suggest "hosting one or more Intermediate Processes to process those > records"... > Good. Regards, Atsushi > Regards, > > Brian > -- Atsushi Kobayashi From akoba@nttv6.net Mon Jul 27 00:20:41 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0703A69FA for ; Mon, 27 Jul 2009 00:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.325 X-Spam-Level: * X-Spam-Status: No, score=1.325 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_00=-2.599, HELO_EQ_LOCALHOST=0.457, HELO_LOCALHOST=3.941, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgiRSQZvPsCB for ; Mon, 27 Jul 2009 00:20:41 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 8E1963A69AD for ; Mon, 27 Jul 2009 00:20:40 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n6R7KanE030781; Mon, 27 Jul 2009 16:20:39 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 27 Jul 2009 16:20:41 +0900 From: Atsushi Kobayashi To: "Saverio Niccolini" In-Reply-To: <547F018265F92642B577B986577D671C9E3B8E@VENUS.office> References: <547F018265F92642B577B986577D671C9E3B8E@VENUS.office> Message-Id: <20090727160547.6700.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [192.16.178.5]); Mon, 27 Jul 2009 16:20:40 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] SIP/RTP extensions to IPFIX: SIPFIX X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 07:20:41 -0000 Dear Saverio, and all, I support it. I have same opinion regarding problem statement section. Sip/rtp monitoring would be useful for other trouble shooting case. It would be utilized more, when a end customer asks the quality degradation, the terminal configuration, or busy line. And it can be applied to IPTV monitoring as well. I have one question. Is the title "SIPFIX" suitable for IETF document? I think generalized name is better. Regards, Atsushi On Wed, 24 Jun 2009 09:46:06 +0200 "Saverio Niccolini" wrote: > Dear all, > > we just submitted the draft about SIP/RTP extensions to IPFIX: > http://www.ietf.org/internet-drafts/draft-huici-ipfix-sipfix-00.txt > > The current draft (to make it easier to read) presents the > problem-statement and the standardizing solution all in one > document. If this draft proceeds we will take care of splitting > these two items later on. > > The first question for the group is: > is this something you would like to discuss in the context of this WG? > > We know from our experience that currently information about > SIP and RTP sessions is exported in proprietary ways and that > would be useful to have L7 information in the IPFIX to enable > better (and application-aware) monitoring solutions at collectors > (or mediators). > > Let us know any comments you can have, > Saverio > From Saverio.Niccolini@nw.neclab.eu Mon Jul 27 00:35:14 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2134B3A6A8B for ; Mon, 27 Jul 2009 00:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xmku04Crfzhf for ; Mon, 27 Jul 2009 00:35:13 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2B17428C1D2 for ; Mon, 27 Jul 2009 00:34:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id E81A32C0012C8; Mon, 27 Jul 2009 09:34:23 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r3B183R4sQn; Mon, 27 Jul 2009 09:34:23 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id B3F8A2C0012C5; Mon, 27 Jul 2009 09:34:13 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Jul 2009 09:34:12 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0044_01CA0E9D.66ABCD30" Message-ID: <547F018265F92642B577B986577D671CADE137@VENUS.office> In-Reply-To: <20090727160547.6700.17391CF2@nttv6.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] SIP/RTP extensions to IPFIX: SIPFIX thread-index: AcoOiskgb0yXHq3LT7mBKhWeghYdawAAQtXw References: <547F018265F92642B577B986577D671C9E3B8E@VENUS.office> <20090727160547.6700.17391CF2@nttv6.net> From: "Saverio Niccolini" To: "Atsushi Kobayashi" Cc: ipfix@ietf.org Subject: Re: [IPFIX] SIP/RTP extensions to IPFIX: SIPFIX X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 07:35:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0044_01CA0E9D.66ABCD30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Kobayashi-san, thanks for the support. Today we will present the draft in the IPFIX session, where we present our motivation of the work. Indeed, we started from VoIP/SIP monitoring but indeed is also for other applications, just needs to be extended a bit. And yes, the idea is to support a wide range of monitoring and operations applications, that is why we came to IPFIX and=20 did not go to RAI area. You can see a preview of the slides here: http://www.ietf.org/proceedings/75/slides/ipfix-2.pdf We can call how you like, SIPFIX was just a cool name to start with :-) Today, Thomas will present our draft where we also analyzed differences with respect to SIP-CLF, I am not sure if this group followed that discussion as well, but there are similarities that needs to be discussed even if the application use case is totally different. Cheers, Saverio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Manager, Real-Time Communications Group NEC Laboratories Europe, Network Research Division=A0=A0=A0=A0=A0 Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 4342-118 Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 e-mail:=A0 saverio.niccolini@nw.neclab.eu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 =A0=20 > -----Original Message----- > From: Atsushi Kobayashi [mailto:akoba@nttv6.net] > Sent: 27 July 2009 09:21 > To: Saverio Niccolini > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] SIP/RTP extensions to IPFIX: SIPFIX >=20 >=20 > Dear Saverio, and all, >=20 > I support it. >=20 > I have same opinion regarding problem statement section. > Sip/rtp monitoring would be useful for other trouble shooting case. It > would be utilized more, when a end customer asks the quality > degradation, > the terminal configuration, or busy line. And it can be applied to = IPTV > monitoring as well. >=20 > I have one question. >=20 > Is the title "SIPFIX" suitable for IETF document? I think generalized > name is better. >=20 > Regards, > Atsushi >=20 > On Wed, 24 Jun 2009 09:46:06 +0200 > "Saverio Niccolini" wrote: >=20 > > Dear all, > > > > we just submitted the draft about SIP/RTP extensions to IPFIX: > > http://www.ietf.org/internet-drafts/draft-huici-ipfix-sipfix-00.txt > > > > The current draft (to make it easier to read) presents the > > problem-statement and the standardizing solution all in one > > document. If this draft proceeds we will take care of splitting > > these two items later on. > > > > The first question for the group is: > > is this something you would like to discuss in the context of this > WG? > > > > We know from our experience that currently information about > > SIP and RTP sessions is exported in proprietary ways and that > > would be useful to have L7 information in the IPFIX to enable > > better (and application-aware) monitoring solutions at collectors > > (or mediators). > > > > Let us know any comments you can have, > > Saverio > > ------=_NextPart_000_0044_01CA0E9D.66ABCD30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISQTCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFQjCCBCqgAwIBAgIEDmFlYTANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0wOTA2MjQwODQ2MDlaFw0xMjA2MjMwODQ2MDlaMGUx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRowGAYDVQQDExFTYXZlcmlvIE5pY2NvbGluaTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAJPLTMpOPSnKG+NN4sQp4LyhifvTrQkdQvxTu9uBJsz7Q90V2lVr CQMIDGRjGydPfENpmCIZ5aJCvupFsnC+gCtAqqgFXDmnmw3MH3tk4nH1pexWdU34dZoaWHcpjInT B+X1W92hR6Dln3EC34GhXUwx0jJmg6+dlo8QIWrOSiKh+Zo6nm1zu1Iv2aQcmjtZdc4O4R62kcPN p5kIzbthI8cA2n6RyGqO3eHQRvv4v2/DexJwpOGTbnGPhxSKBB+MYtEKQn4za7ZPlG2GfSJWTfyz BGSV44mJnT22ulmZ5dHmQH+hjpwK+HjxCPzFPOnsgshpiYTgTzkgMN3UsLpJwO0CAwEAAaOCAcww ggHIMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcD BAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUG/1Z3R3tW3Sk88OO9Nc9qBUirnQwHwYDVR0jBBgwFoAU TxyHeh3gL5n2vhWq0TWdDkrmujYwKQYDVR0RBCIwIIEeU2F2ZXJpby5OaWNjb2xpbmlAbncubmVj bGFiLmV1MH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvbmVjbGFiLWNh L3B1Yi9jcmwvY2FjcmwuY3JsMDigNqA0hjJodHRwOi8vY2RwMi5wY2EuZGZuLmRlL25lY2xhYi1j YS9wdWIvY3JsL2NhY3JsLmNybDCBmAYIKwYBBQUHAQEEgYswgYgwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBCBggrBgEF BQcwAoY2aHR0cDovL2NkcDIucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQAr+OhxRjRYhlNyAS+ayX47J26jfWSZKS/XTB2pP6sZdTQ1 mkoQKCXLylT74IwXkEC4X2cjR+JJRkU8VrWgLuZ9rl/1OpqJFcWMFD1YPfSv7kaDyqmAMY4Fm4oT tj0tnTQaC3O/Tm/MYIJ47knXOh6IlDsDYust5u6YFm0ik+8CO+4Nf9VKD6HK7l0bMiri0B7UdT5P y55XtN57S6yu+vfsCaFH+7G1iZpi6IV5bAY9JiSmLio27sJLk05cADo+jTRKSp1wsIX7SGzuu5Y8 kClAjQjNcBs+FRvI6d+WdZU9OUJSnCFhtkHKtugBYxHyT5ma2YdUhJRR3gX7Ya18rOMdMYID5zCC A+MCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNV BAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlORUNMQUItQ0ExMTAvBgkqhkiG 9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIuZXUCBA5hZWEwCQYFKw4DAhoF AKCCAiIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzI3MDcz NDEyWjAjBgkqhkiG9w0BCQQxFgQUR/xWLbsNU61/vMy/aI910jgw3UEwZwYJKoZIhvcNAQkPMVow WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgaoGCSsGAQQBgjcQBDGBnDCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDmFlYTCBrAYLKoZIhvcNAQkQAgsxgZyggZkw gZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBM YWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlORUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInpl cnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIuZXUCBA5hZWEwDQYJKoZIhvcNAQEBBQAEggEA eow2mc5vDHA3IZ1SUSIvtSJwKn4K0zck7a2KeePF0+dw4ibfBXziEDeBMDREg8CdxAau3jk8OT0z WAG58/8X3i3tHq3dKqNg/eneBPq4A/xkWcWmDu7Qpu0RX4qkK2YsaD+jSL23+kTtbqbHKH6uoT0v VGcuyvLYUoptnKEGeSy2Mt3mqN/pvksM3weg8qJB3wWW3wgCiDCO9ubTLWjKhginVTP2UDDNVFME GBHT3zM7w5VTU/Gu/aql6lY5eihJtzoRlzFp7zCy+ZkcJWTPckZjNWGiS1CtMe4aoytIbIVdeh+F a8iaH47tPidrtU787xrjkF8SiXKtTmll1pFihAAAAAAAAA== ------=_NextPart_000_0044_01CA0E9D.66ABCD30-- From trammell@tik.ee.ethz.ch Mon Jul 27 01:34:03 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBB4928C13F for ; Mon, 27 Jul 2009 01:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5P5F9zI1kzLE for ; Mon, 27 Jul 2009 01:34:03 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id D35D828C233 for ; Mon, 27 Jul 2009 01:33:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 711D5D9361; Mon, 27 Jul 2009 10:33:55 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vPFE18UuPVAJ; Mon, 27 Jul 2009 10:33:55 +0200 (MEST) Received: from dhcp-57d7.meeting.ietf.org (unknown [130.129.87.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0DA8BD9303; Mon, 27 Jul 2009 10:33:55 +0200 (MEST) Message-Id: From: Brian Trammell To: Atsushi Kobayashi In-Reply-To: <20090727153415.66FD.17391CF2@nttv6.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 10:33:54 +0200 References: <20090727124958.66FA.17391CF2@nttv6.net> <68C3A7FA-1002-434A-BF36-FB158824FA5D@tik.ee.ethz.ch> <20090727153415.66FD.17391CF2@nttv6.net> X-Mailer: Apple Mail (2.935.3) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX Mediation terminologies again X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 08:34:04 -0000 hi, Atsushi, replies inline. :) On Jul 27, 2009, at 8:59 AM, Atsushi Kobayashi wrote: > >>> >>> >>> - There is no description regarding IPFIX Mediation. >> >> Why does the IntP definition need to say anything explicitly about >> mediation? It's obvious, to me anyway, from the fact that it's >> defined >> in the mediation document, and that it is hosted in a Mediator/OE... >> > > Sorry for lack of explanation. The current IntP takes a stream of > record > as its input and transmits a stream of records as its output. In below > case, IntP gives the trigger to Exporting Process to send Withdrawal > Message rather than manipulating a stream of records. So, although we > can define another Process, I think it is better to avoid creating new > Process. > > IntP can execute other function related to template or IPFIX > Messages by > adding the first sentence. Does it make sense? Yes, now it does. Thanks. :) >>> - Configuration parameters are covered in other data. Maybe we can >>> remove this. >> >> Good point. >> >>> - I found typo "keeps state", it will be replaced with "kept state". >> >> This is not an error; "keeps state" is in present tense in parallel >> with all other clauses in the list, and properly spelled. If the >> wording is confusing, suggest "maintains state" instead. >> > > Does it need a semicolon before "keeps state"? > > An Intermediate Process takes a sequence of records from a Collecting > Process, Metering Process, IPFIX File Reader, or another Intermediate > Process; performs some transformation on these records based upon the > content of the records themselves; keeps state across multiple > records, > ^^^^^^^^^^^^^^^^^^^^^^^^ yes. but... ahhhhh... Okay, I see the issue here. It does keep state, but it also needs to make decisions based on the state that it keeps. Keeps/kept makes this read a bit confusingly, so let me see if I can fix this by rewording slightly: NEW Intermediate Process An Intermediate Process implements the functions of IPFIX Mediation. It takes a stream of records as its input from a Collecting Process, Metering Process, IPFIX File Reader, or another Intermediate Process; performs some transformation on these records based upon the content of each record, state maintained across multiple records, or other data sources; and passes a stream of transformed records as its output on to an Exporting Process, IPFIX File Writer, or another Intermediate Process. Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter. This still needs to handle the case of record routing -- where the output of the IntP is some configuration input to a downstream EP. So how about: NEWER Intermediate Process An Intermediate Process implements the functions of IPFIX Mediation. It takes a stream of records as its input from a Collecting Process, Metering Process, IPFIX File Reader, or another Intermediate Process; performs some transformation on these records, or makes some decision about their subsequent processing, based upon the content of each record, state maintained across multiple records, or other data sources; and passes a stream of transformed records as its output on to an Exporting Process, IPFIX File Writer, or another Intermediate Process. Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter. Regards, Brian From muenz@net.in.tum.de Mon Jul 27 01:45:18 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC2F28C25A for ; Mon, 27 Jul 2009 01:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66IBNbEqDw+u for ; Mon, 27 Jul 2009 01:45:17 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 9AA4628C1D7 for ; Mon, 27 Jul 2009 01:45:12 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id E2162481D8; Mon, 27 Jul 2009 10:45:11 +0200 (CEST) Received: from [127.0.0.1] (ldap [131.159.14.1]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id AC73950BD; Mon, 27 Jul 2009 10:45:11 +0200 (CEST) Message-ID: <4A6D6919.2050602@net.in.tum.de> Date: Mon, 27 Jul 2009 10:45:13 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Brian Trammell References: <20090727124958.66FA.17391CF2@nttv6.net> <68C3A7FA-1002-434A-BF36-FB158824FA5D@tik.ee.ethz.ch> <20090727153415.66FD.17391CF2@nttv6.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX Mediation terminologies again X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 08:45:18 -0000 Hi Brian, Brian Trammell wrote: > hi, Atsushi, > > replies inline. :) > > On Jul 27, 2009, at 8:59 AM, Atsushi Kobayashi wrote: > >>>> - There is no description regarding IPFIX Mediation. >>> >>> Why does the IntP definition need to say anything explicitly about >>> mediation? It's obvious, to me anyway, from the fact that it's defined >>> in the mediation document, and that it is hosted in a Mediator/OE... There does not have to be a reference to IPFIX Mediation in the definition of IP. Though, I thought it would make sense. >> Sorry for lack of explanation. The current IntP takes a stream of record >> as its input and transmits a stream of records as its output. In below >> case, IntP gives the trigger to Exporting Process to send Withdrawal >> Message rather than manipulating a stream of records. So, although we >> can define another Process, I think it is better to avoid creating new >> Process. >> >> IntP can execute other function related to template or IPFIX Messages by >> adding the first sentence. Does it make sense? > > Yes, now it does. Thanks. :) > >>>> - Configuration parameters are covered in other data. Maybe we can >>>> remove this. >>> >>> Good point. >>> >>>> - I found typo "keeps state", it will be replaced with "kept state". >>> >>> This is not an error; "keeps state" is in present tense in parallel >>> with all other clauses in the list, and properly spelled. If the >>> wording is confusing, suggest "maintains state" instead. >>> >> >> Does it need a semicolon before "keeps state"? >> >> An Intermediate Process takes a sequence of records from a Collecting >> Process, Metering Process, IPFIX File Reader, or another Intermediate >> Process; performs some transformation on these records based upon the >> content of the records themselves; keeps state across multiple records, >> ^^^^^^^^^^^^^^^^^^^^^^^^ > > yes. but... ahhhhh... Okay, I see the issue here. It does keep state, > but it also needs to make decisions based on the state that it keeps. > Keeps/kept makes this read a bit confusingly, so let me see if I can fix > this by rewording slightly: > > NEW > > Intermediate Process > > An Intermediate Process implements the functions of IPFIX Mediation. Why did you add "the"? We explicitly wrote "implements functions" and not "implements the functions" because an Intermediate Process can implement any number and types of functions of IPFIX Mediation, but probably not all functions that exist. > It takes a stream of records as its input from a Collecting > Process, Metering Process, IPFIX File Reader, or another > Intermediate Process; performs some transformation on these > records based upon the content of each record, state maintained across > multiple records, or other data sources; fine. > and passes a stream > of transformed records as its output on to an Exporting Process, > IPFIX File Writer, or another Intermediate Process. > Typically, an Intermediate Process is hosted by an IPFIX Mediator. > Alternatively, an Intermediate Process may be hosted by > an Original Exporter. > > This still needs to handle the case of record routing -- where the > output of the IntP is some configuration input to a downstream EP. So > how about: > > > NEWER > > Intermediate Process > > An Intermediate Process implements the functions of IPFIX Mediation. same as above. > It takes a stream of records as its input from a Collecting > Process, Metering Process, IPFIX File Reader, or another > Intermediate Process; performs some transformation on these > records, or makes some decision about their subsequent processing, > based upon the content of each record, state maintained across > multiple records, or other data sources; also fine. > and passes a stream > of transformed records as its output on to an Exporting Process, > IPFIX File Writer, or another Intermediate Process. > Typically, an Intermediate Process is hosted by an IPFIX Mediator. > Alternatively, an Intermediate Process may be hosted by > an Original Exporter. Gerhard -- Dipl.-Ing. Gerhard Münz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universität München Boltzmannstr. 3, 85748 Garching bei München, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz From trammell@tik.ee.ethz.ch Mon Jul 27 01:50:02 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38B128C25B for ; Mon, 27 Jul 2009 01:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf51iyUfAKx2 for ; Mon, 27 Jul 2009 01:50:02 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id A0D0528C25D for ; Mon, 27 Jul 2009 01:48:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6B81DD936A; Mon, 27 Jul 2009 10:48:36 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id I8uBNNNuTIaU; Mon, 27 Jul 2009 10:48:36 +0200 (MEST) Received: from dhcp-57d7.meeting.ietf.org (unknown [130.129.87.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 07448D9303; Mon, 27 Jul 2009 10:48:35 +0200 (MEST) Message-Id: From: Brian Trammell To: Gerhard Muenz In-Reply-To: <4A6D6919.2050602@net.in.tum.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 10:48:35 +0200 References: <20090727124958.66FA.17391CF2@nttv6.net> <68C3A7FA-1002-434A-BF36-FB158824FA5D@tik.ee.ethz.ch> <20090727153415.66FD.17391CF2@nttv6.net> <4A6D6919.2050602@net.in.tum.de> X-Mailer: Apple Mail (2.935.3) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX Mediation terminologies again X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 08:50:02 -0000 hi, Gerhard, inline. :) Regards, Brian On Jul 27, 2009, at 10:45 AM, Gerhard Muenz wrote: >> NEW >> >> Intermediate Process >> >> An Intermediate Process implements the functions of IPFIX >> Mediation. > > Why did you add "the"? > > We explicitly wrote "implements functions" and not "implements the > functions" because an Intermediate Process can implement any number > and > types of functions of IPFIX Mediation, but probably not all functions > that exist. Point. Oops. Hadn't actually noticed that I'd added it. > >> It takes a stream of records as its input from a Collecting >> Process, Metering Process, IPFIX File Reader, or another >> Intermediate Process; performs some transformation on these >> records based upon the content of each record, state maintained >> across >> multiple records, or other data sources; > > fine. > >> and passes a stream >> of transformed records as its output on to an Exporting Process, >> IPFIX File Writer, or another Intermediate Process. >> Typically, an Intermediate Process is hosted by an IPFIX Mediator. >> Alternatively, an Intermediate Process may be hosted by >> an Original Exporter. >> >> This still needs to handle the case of record routing -- where the >> output of the IntP is some configuration input to a downstream EP. So >> how about: >> >> >> NEWER >> >> Intermediate Process >> >> An Intermediate Process implements the functions of IPFIX >> Mediation. > > same as above. Suggest, then, "An Intermediate Process implements IPFIX Mediation functions" (prepositional form here is a little awkward). From Quittek@nw.neclab.eu Mon Jul 27 02:01:30 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2024A28C14F for ; Mon, 27 Jul 2009 02:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJAyyhWYyRtQ for ; Mon, 27 Jul 2009 02:01:29 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 498C328C14D for ; Mon, 27 Jul 2009 02:01:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3B5DC2C0012C8; Mon, 27 Jul 2009 11:01:30 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdXqcp033K6W; Mon, 27 Jul 2009 11:01:30 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 16D1F2C0012C5; Mon, 27 Jul 2009 11:01:15 +0200 (CEST) Received: from [10.7.0.54] ([10.7.0.54]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 11:01:15 +0200 In-Reply-To: <4A69C003.4010507@cisco.com> References: <74D804F7-7425-47FC-80A1-4139F338D501@tik.ee.ethz.ch> <20090713172652.8356.17391CF2@nttv6.net> <4A69C003.4010507@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04492AE4-8CD6-4AA8-AF23-25851D112706@nw.neclab.eu> Content-Transfer-Encoding: 7bit From: Juergen Quittek Date: Mon, 27 Jul 2009 11:01:11 +0200 To: Benoit Claise X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 27 Jul 2009 09:01:15.0085 (UTC) FILETIME=[CBD237D0:01CA0E98] Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] transport mediation in IPFIX Mediation? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 09:01:30 -0000 On 24.07.2009 at 16:06 Benoit Claise wrote: > Kobayashi-san, >> Hi Gerhard, Brian, Juergen, and all, >> >> I recognize that you (Juergen, Brian, Gerhard) seem have a same >> opinion >> that IPFIX Mediation doesn't include transport mediation. >> I would like to clarify your point. >> >> Ok, I agree the document does not use ambiguous word "transport". >> Ok, I agree that IPFIX Mediation does not cover the transport >> mediation >> relaying IPFIX Messages directly with not changing whole of them. >> > Does it imply that we should change the abstract? > Abstract > > Flow-based measurement is a popular method for various network > monitoring usages. The sharing of flow-based information for > monitoring applications having different requirements raises some > open issues in terms of measurement system scalability, flow-based > measurement flexibility, and export reliability that IPFIX > Mediation > may help resolve. IPFIX Mediation covers two classes of mediation: > content mediation for traffic data and transport mediation for > transport protocols. This document describes the IPFIX Mediation > applicability examples, along with some problems that network > administrators have been facing. Yes. Juergen From bclaise@cisco.com Mon Jul 27 02:08:19 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8205E3A6C4E for ; Mon, 27 Jul 2009 02:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qfHmmAKs5Am for ; Mon, 27 Jul 2009 02:08:18 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id A356E3A6C4C for ; Mon, 27 Jul 2009 02:08:18 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6R98Ips001654; Mon, 27 Jul 2009 11:08:18 +0200 (CEST) Received: from [10.61.101.72] (dhcp-10-61-101-72.cisco.com [10.61.101.72]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6R98Hvt026163; Mon, 27 Jul 2009 11:08:17 +0200 (CEST) Message-ID: <4A6D6E81.7020905@cisco.com> Date: Mon, 27 Jul 2009 11:08:17 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Brian Trammell References: <20090727124958.66FA.17391CF2@nttv6.net> <68C3A7FA-1002-434A-BF36-FB158824FA5D@tik.ee.ethz.ch> <20090727153415.66FD.17391CF2@nttv6.net> <4A6D6919.2050602@net.in.tum.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX Mediation terminologies again -> meeting this week? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 09:08:19 -0000 Dear all, I have also some (minor) comments on the terminology. Why don't we simply meet after the IPFIX meeting today to sort out the remaining issues? Most of the time, a 15 minute discussion is more efficient than a long email thread... Regards, Benoit. From trammell@tik.ee.ethz.ch Mon Jul 27 02:16:52 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B279C3A6C55 for ; Mon, 27 Jul 2009 02:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfWGOuW4P17H for ; Mon, 27 Jul 2009 02:16:52 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id F14AD3A6886 for ; Mon, 27 Jul 2009 02:16:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B9247D9353; Mon, 27 Jul 2009 11:16:51 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KaPpl3deuMJ9; Mon, 27 Jul 2009 11:16:51 +0200 (MEST) Received: from dhcp-57d7.meeting.ietf.org (unknown [130.129.87.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5E70AD9324; Mon, 27 Jul 2009 11:16:51 +0200 (MEST) Message-Id: <3618EC7E-1182-45A6-91CD-BD607102E602@tik.ee.ethz.ch> From: Brian Trammell To: Benoit Claise In-Reply-To: <4A6D6E81.7020905@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 11:16:50 +0200 References: <20090727124958.66FA.17391CF2@nttv6.net> <68C3A7FA-1002-434A-BF36-FB158824FA5D@tik.ee.ethz.ch> <20090727153415.66FD.17391CF2@nttv6.net> <4A6D6919.2050602@net.in.tum.de> <4A6D6E81.7020905@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX Mediation terminologies again -> meeting this week? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 09:16:52 -0000 hi, Benoit, Indeed. Sounds good. Regards, Brian On Jul 27, 2009, at 11:08 AM, Benoit Claise wrote: > Dear all, > > I have also some (minor) comments on the terminology. > Why don't we simply meet after the IPFIX meeting today to sort out > the remaining issues? > Most of the time, a 15 minute discussion is more efficient than a > long email thread... > > Regards, Benoit. From akoba@nttv6.net Mon Jul 27 02:19:17 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F57C3A6C3D for ; Mon, 27 Jul 2009 02:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.521 X-Spam-Level: * X-Spam-Status: No, score=1.521 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, HELO_EQ_LOCALHOST=0.457, HELO_LOCALHOST=3.941, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLJFVj8jaxqy for ; Mon, 27 Jul 2009 02:19:16 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id CDF043A6C3B for ; Mon, 27 Jul 2009 02:19:15 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n6R9IpHa031796; Mon, 27 Jul 2009 18:18:52 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 27 Jul 2009 18:18:55 +0900 From: Atsushi Kobayashi To: Benoit Claise In-Reply-To: <4A6D6E81.7020905@cisco.com> References: <4A6D6E81.7020905@cisco.com> Message-Id: <20090727181202.670F.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [192.16.178.5]); Mon, 27 Jul 2009 18:18:54 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX Mediation terminologies again -> meeting this week? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 09:19:17 -0000 Dear Benoit, Brian and Gerhard, Benoit, Ok. The following terms include Brian and Gerhard feedbacks. IPFIX Mediation IPFIX Mediation is the manipulation and conversion of a stream of records for subsequent export using IPFIX. Intermediate Process An Intermediate Process implements IPFIX Mediation functions. It takes a stream of records as its input from a Collecting Process, Metering Process, IPFIX File Reader, or another Intermediate Process; performs some transformation on these records, or makes some decision about their subsequent processing, based upon the content of each record, state maintained across multiple records, or other data sources; and passes a stream of transformed records as its output on to an Exporting Process, IPFIX File Writer, or another Intermediate Process. Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter. IPFIX Mediator An IPFIX Mediator is an IPFIX Device that provides mediation capabilities by receiving records from some data source, hosting one or more Intermediate Processes to process those records, and exporting those records in IPFIX Messages via an Exporting Process. In the common case, an IPFIX Mediator receives records from a Collecting Process but could also receive records from data sources not encoded using IPFIX, e.g., in the case of NetFlow V9 protocol translation. Regards, Atsushi On Mon, 27 Jul 2009 11:08:17 +0200 Benoit Claise wrote: > Dear all, > > I have also some (minor) comments on the terminology. > Why don't we simply meet after the IPFIX meeting today to sort out the > remaining issues? > Most of the time, a 15 minute discussion is more efficient than a long > email thread... > > Regards, Benoit. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Atsushi Kobayashi From rfc-editor@rfc-editor.org Mon Jul 27 02:34:23 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93BED3A688D; Mon, 27 Jul 2009 02:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.326 X-Spam-Level: X-Spam-Status: No, score=-16.326 tagged_above=-999 required=5 tests=[AWL=0.673, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYRR-D4WaKjY; Mon, 27 Jul 2009 02:34:22 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id AB3CC3A657C; Mon, 27 Jul 2009 02:34:22 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id EABF02F549F; Mon, 27 Jul 2009 02:29:56 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090727092956.EABF02F549F@bosco.isi.edu> Date: Mon, 27 Jul 2009 02:29:56 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] RFC 5610 on Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 09:34:23 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5610 Title: Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements Author: E. Boschi, B. Trammell, L. Mark, T. Zseby Status: Standards Track Date: July 2009 Mailbox: elisa.boschi@hitachi-eu.com, brian.trammell@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de Pages: 20 Characters: 42526 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipfix-exporting-type-05.txt URL: http://www.rfc-editor.org/rfc/rfc5610.txt This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. [STANDARDS TRACK] This document is a product of the IP Flow Information Export Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From akoba@nttv6.net Mon Jul 27 04:06:29 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7FE3A68DE for ; Mon, 27 Jul 2009 04:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.639 X-Spam-Level: * X-Spam-Status: No, score=1.639 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, HELO_EQ_LOCALHOST=0.457, HELO_LOCALHOST=3.941, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwPTTWBLpcOj for ; Mon, 27 Jul 2009 04:06:29 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 97C9C3A67FE for ; Mon, 27 Jul 2009 04:06:28 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n6RB6N8X032475; Mon, 27 Jul 2009 20:06:24 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 27 Jul 2009 20:06:26 +0900 From: Atsushi Kobayashi To: Benoit Claise In-Reply-To: <4A44C262.3070301@cisco.com> References: <4A44C262.3070301@cisco.com> Message-Id: <20090727163253.6703.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [192.16.178.5]); Mon, 27 Jul 2009 20:06:25 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-claise-structured-data-in-ipfix-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 11:06:29 -0000 Dear Benoit and all, I send it to IPFIX only. Several examples bring the motivation of structured data. However, I come up with a question during going through this draft. - Is IPFIX version kept, even if the IPFIX extension installed? This extension can provide new exporting method regarding multicast outgoing interfaces, MPLS stacks, and Packet Selection Sequence Report Interpretation. An Exporter can choose two methods regardless of Collector side implementation. A Collector complying with only RFC5101 cannot decode all of data. Regards, Atsushi On Fri, 26 Jun 2009 14:43:14 +0200 Benoit Claise wrote: > Dear all, > > A new version of the IPFIX structured is in the process of being posted > (manual post requested) > Note: as requested by Dan in the OPS-AREA meeting minutes, I'll include > OPS-AREA in the email > > Most of the points discussed during both the IPFIX and OPS-AREA meetings > were addressed. > - more justifications why we need this structured data type and why > appropriate protocols are not suitable > - less focus on security. More example related to IPFIX, such as list of > interfaces in a multicast flow, such as the MPLS label stack entry, > - discussion about the recursive structured data > - connection with the current IPFIX mediation function work. > - connection with the one-way delay export, specified in PSAMP > - Example of an aggregated observation point in a mediation function, > which might be needed as a scope in an options template record > - etc... > > As always, your feedback is welcome > > Regards, Benoit. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Atsushi Kobayashi From paitken@cisco.com Mon Jul 27 04:32:38 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C347328C1BA for ; Mon, 27 Jul 2009 04:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYgd9ljrJFwk for ; Mon, 27 Jul 2009 04:32:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 82B3128C17F for ; Mon, 27 Jul 2009 04:32:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,276,1246838400"; d="scan'208";a="45901543" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Jul 2009 11:32:37 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6RBWb3c019338; Mon, 27 Jul 2009 13:32:37 +0200 Received: from [144.254.153.45] (dhcp-144-254-153-45.cisco.com [144.254.153.45]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6RBWbkV012778; Mon, 27 Jul 2009 11:32:37 GMT Message-ID: <4A6D9055.1070704@cisco.com> Date: Mon, 27 Jul 2009 12:32:37 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 (Ubuntu-1.1.15+nobinonly-0ubuntu2) MIME-Version: 1.0 To: Atsushi Kobayashi References: <4A44C262.3070301@cisco.com> <20090727163253.6703.17391CF2@nttv6.net> In-Reply-To: <20090727163253.6703.17391CF2@nttv6.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1068; t=1248694357; x=1249558357; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20draft-claise-structured-data-in-ipfix-0 1 |Sender:=20; bh=20wGmYgs2kvsiltR34OuZ+zPWSYyvZL1pu2ZeHMf4es=; b=WD6anlQrgoTnA8T86E5K+xiCu0NXlyoD27aSCCuCzYr4T8CxNuTnpG88qm OgKERt2uzg5d1XCx8dyPdTlEMgUHAUMjsdd4SER5hMcE92424/6N1/q5wgul E1SRYJfS98; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-claise-structured-data-in-ipfix-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 11:32:38 -0000 Atsushi-san, > Dear Benoit and all, > > I send it to IPFIX only. > Several examples bring the motivation of structured data. > However, I come up with a question during going through this draft. > > - Is IPFIX version kept, even if the IPFIX extension installed? I believe the IPFIX version should not be changed, because the protocol has only been extended a little rather than being substantially changed. > This extension can provide new exporting method regarding multicast > outgoing interfaces, MPLS stacks, and Packet Selection Sequence Report > Interpretation. An Exporter can choose two methods regardless of > Collector side implementation. A Collector complying with only RFC5101 > cannot decode all of data. However it can skip over the data - which is the usual IPFIX model: if you cannot read something, at least you can move on to the following information. Even if the IPFIX version was changed, the collector would still be unable to decode the data. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. From trammell@tik.ee.ethz.ch Mon Jul 27 04:53:32 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D67A3A6C43 for ; Mon, 27 Jul 2009 04:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoUujJQgGdSk for ; Mon, 27 Jul 2009 04:53:31 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id BB69A3A680B for ; Mon, 27 Jul 2009 04:53:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 334D2D936C; Mon, 27 Jul 2009 13:53:31 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DR7FHrUK2Lua; Mon, 27 Jul 2009 13:53:30 +0200 (MEST) Received: from dhcp-57d7.meeting.ietf.org (unknown [130.129.87.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id AF976D934A; Mon, 27 Jul 2009 13:53:30 +0200 (MEST) Message-Id: From: Brian Trammell To: Paul Aitken In-Reply-To: <4A6D9055.1070704@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 13:53:29 +0200 References: <4A44C262.3070301@cisco.com> <20090727163253.6703.17391CF2@nttv6.net> <4A6D9055.1070704@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-claise-structured-data-in-ipfix-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 11:53:32 -0000 hi, Paul, all, I concur; version 11 should be reserved for framing changes, not information model changes. By framing these structures within IEs, we get to use them without defining a new version. However, we might want to include in this effort 1. an identification of all IEs in the information model at publication time which are clear "kludges" (mainly here I mean the MPLS label stack), and 2. creation of IEs to cover these cases within the structured data IEs, if necessary. This document should also note that EPs supporting export of information using structured data for these cases SHOULD provide configuration to disable them and use the old methods for interoperability. Regards, Brian On Jul 27, 2009, at 1:32 PM, Paul Aitken wrote: > Atsushi-san, > >> Dear Benoit and all, >> I send it to IPFIX only. >> Several examples bring the motivation of structured data. >> However, I come up with a question during going through this draft. >> - Is IPFIX version kept, even if the IPFIX extension installed? > > I believe the IPFIX version should not be changed, because the > protocol has only been extended a little rather than being > substantially changed. > > >> This extension can provide new exporting method regarding multicast >> outgoing interfaces, MPLS stacks, and Packet Selection Sequence >> Report >> Interpretation. An Exporter can choose two methods regardless of >> Collector side implementation. A Collector complying with only >> RFC5101 >> cannot decode all of data. > > However it can skip over the data - which is the usual IPFIX model: > if you cannot read something, at least you can move on to the > following information. > > Even if the IPFIX version was changed, the collector would still be > unable to decode the data. > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From akoba@nttv6.net Mon Jul 27 05:25:37 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5DD28C140 for ; Mon, 27 Jul 2009 05:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.717 X-Spam-Level: * X-Spam-Status: No, score=1.717 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, HELO_EQ_LOCALHOST=0.457, HELO_LOCALHOST=3.941, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1HkB-ClSVRO for ; Mon, 27 Jul 2009 05:25:36 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id EB70C28C121 for ; Mon, 27 Jul 2009 05:25:32 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n6RCPRPW032961; Mon, 27 Jul 2009 21:25:29 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 27 Jul 2009 21:25:31 +0900 From: Atsushi Kobayashi To: Brian Trammell In-Reply-To: References: <4A6D9055.1070704@cisco.com> Message-Id: <20090727212057.6715.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [192.16.178.5]); Mon, 27 Jul 2009 21:25:30 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-claise-structured-data-in-ipfix-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 12:25:37 -0000 Hi Brian and Paul, On Mon, 27 Jul 2009 13:53:29 +0200 Brian Trammell wrote: > hi, Paul, all, > > I concur; version 11 should be reserved for framing changes, not > information model changes. By framing these structures within IEs, we > get to use them without defining a new version. > > However, we might want to include in this effort 1. an identification > of all IEs in the information model at publication time which are > clear "kludges" (mainly here I mean the MPLS label stack), and 2. > creation of IEs to cover these cases within the structured data IEs, > if necessary. This document should also note that EPs supporting > export of information using structured data for these cases SHOULD > provide configuration to disable them and use the old methods for > interoperability. I agree. It resolves my question. Regards, Atsushi > > Regards, > > Brian > > On Jul 27, 2009, at 1:32 PM, Paul Aitken wrote: > > > Atsushi-san, > > > >> Dear Benoit and all, > >> I send it to IPFIX only. > >> Several examples bring the motivation of structured data. > >> However, I come up with a question during going through this draft. > >> - Is IPFIX version kept, even if the IPFIX extension installed? > > > > I believe the IPFIX version should not be changed, because the > > protocol has only been extended a little rather than being > > substantially changed. > > > > > >> This extension can provide new exporting method regarding multicast > >> outgoing interfaces, MPLS stacks, and Packet Selection Sequence > >> Report > >> Interpretation. An Exporter can choose two methods regardless of > >> Collector side implementation. A Collector complying with only > >> RFC5101 > >> cannot decode all of data. > > > > However it can skip over the data - which is the usual IPFIX model: > > if you cannot read something, at least you can move on to the > > following information. > > > > Even if the IPFIX version was changed, the collector would still be > > unable to decode the data. > > > > -- > > Paul Aitken > > Cisco Systems Ltd, Edinburgh, Scotland. > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix > -- Atsushi Kobayashi From bclaise@cisco.com Tue Jul 28 01:37:09 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE47E3A6995 for ; Tue, 28 Jul 2009 01:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aijH+WrLeAQ0 for ; Tue, 28 Jul 2009 01:37:08 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 5CF033A6DC1 for ; Tue, 28 Jul 2009 01:37:03 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6S8b3EZ015963; Tue, 28 Jul 2009 10:37:03 +0200 (CEST) Received: from [10.61.103.210] (dhcp-10-61-103-210.cisco.com [10.61.103.210]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6S8b2kT029900; Tue, 28 Jul 2009 10:37:02 +0200 (CEST) Message-ID: <4A6EB8AE.5000204@cisco.com> Date: Tue, 28 Jul 2009 10:37:02 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gerhard Muenz References: <4A1BE50E.6040407@net.in.tum.de> In-Reply-To: <4A1BE50E.6040407@net.in.tum.de> Content-Type: multipart/alternative; boundary="------------000800050204060706040001" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:37:09 -0000 This is a multi-part message in MIME format. --------------000800050204060706040001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, Thinking some more, I would like to come back to that point below. > >> >> 6.8. Consideration for Aggregation >> >> In case of Flow Key aggregation, Time Composition, and Spatial >> Composition, there are the following considerations: >> >> o Aggregation rule for non Flow Keys >> > > "non Flow Keys" => "non-key fields" > > >> There are no obvious rules of non Flow Keys. For example, if an >> > > "non Flow Keys" => "non-key fields" > > >> IPFIX Mediation receives two Flow Records with different DSCP >> values, and this DSCP field is not a Flow Key, those two Flow >> Records can be aggregated based on the Flow Keys value. However, >> there is no rules for what the DSCP value should be for the >> aggregated Data Record. Potential solutions are: the value of >> > > Actually, there is a rule! > Unless specified differently, the value of the first packet must be > included in the record. Hence, as long as timestamps are present and > allow to determine which one of the Flow Records includes the earliest > packet, the decision is evident! > I agree with this rule on Exporter. However, for a Mediator, it's not obvious that we should follow it. Anyway, it should be specified in the mediation framework or protocol draft. In the mean time, I would like to keep this issue in the problem statement. Regards, Benoit. > >> single of the two DSCP, the value 0 (in this case, the value 0 is >> a valid DSCP value), or removing a DSCP field in its Data Record. >> >> o Configured Selection Fraction on aggregation >> >> There is no obvious rules of how to compute Configured Selection >> Fraction, and whether a Mediator should report Configured >> > > remove ", and whether....," > It is obvious, that Configured or Attained Selection Fraction is > necessary to interpret the Flow Records. > > > >> Selection Fraction, when aggregation resulting from Sampling. For >> > > "...when aggregating IPFIX Flow Records of sampled packets." > > >> example, special care must be taken in the following: aggregation >> resulting from the different Configured Selection Fraction, >> aggregation resulting from different Sampling techniques, such as >> Systematic Count-Based Sampling and Random n-out-of-N Sampling >> etc. >> > > > >> 7. Summary and Conclusion >> >> This document described the problems that network administrators have >> been facing, the applicability of IPFIX Mediation to these problems, >> and the problems related to the implementation of IPFIX Mediators. >> To assist the operations of the Exporters and Collectors, there are >> various IPFIX Mediations from which the administrators may select. >> Examples of the applicability of IPFIX Mediation are as follows. >> >> o Regarding large-scale measurement system, IPFIX Concentrators or >> IPFIX Distributors help to achieve traffic analysis with high data >> accuracy and fine flow granularity even as IP traffic grows. As >> IPFIX Mediation capabilities, Flow selection Sampling, >> > > flow sampling? > > >> aggregation, and composition are effective. >> >> o Regarding data retention, IPFIX Mediators enhance the export >> reliability, and the storage of the measurement system. >> >> o Regarding the distribution of Data Records, IPFIX Distributors >> help to achieve multipurpose traffic analysis for different >> organizations, or help to achieve respective traffic analysis >> based on Data Record types(IPv4, IPv6, MPLS, and VPN). >> >> o Regarding IPFIX Exporting across domains, IPFIX Masquerading >> > > exporting > > >> Proxies help administrators to anonymize or filter Flow Records/ >> > > Data Records > > >> Packet Reports, preventing privacy violations. >> >> o Regarding interoperability, IPFIX Proxies provide interoperability >> between legacy protocols and IPFIX, even during the migration >> period to IPFIX. >> >> As a result, the IPFIX Mediation benefits become apparent. However, >> there are still some open issues with the use of IPFIX Mediators. >> >> o Both Observation Point and IPFIX Message 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 IPFIX Mediators are required to manage Transport Sessions, >> Template IDs, and Observation Domain IDs. Otherwise, anomalous >> IPFIX messages could be created. >> >> o Data advertised by Option Templates from the Original Exporter, >> > > _Options_ Templates > > better: > "Options Data Records exported by the Original Exporter, such as those > reporting the Sampling rate...." > > Maybe the term "Options Data Record" should be introduced to simplify > things. BTW, we had the same problem in per-sctp-stream, and always > wrote "Data Record defined by an Options Template Record", which is not > very easy to read. > > >> such as the Sampling rate and Sampling algorithm used, might be >> lost. If a Collector is not informed of current Sampling rates, >> traffic information might become worthless. >> >> These problems stem from the fact that no standards regarding IPFIX >> Mediation have been set. In particular, the minimum set of >> information that should be communicated between Original Exporters >> and Collectors, the management between different IPFIX Transport >> Sessions, and the internal components of IPFIX Mediators should be >> standardized. >> > > > >> 8. Security Considerations >> >> A flow-based measurement system must prevent potential security >> threats: the disclosure of confidential traffic data, injection of >> incorrect data, and unauthorized access to traffic data. These >> security threats of the IPFIX protocol are covered by the security >> considerations section in [RFC5101] and are still valid for IPFIX >> Mediators. >> >> And a measurement system must also prevent following security threats >> > > "...the following..." > > >> related to IPFIX Mediation: >> >> o Attacks against IPFIX Mediator >> >> IPFIX Mediators can be considered as a prime target for attacks, >> as an alternative to IPFIX Exporters and Collectors. IPFIX >> Proxies or Masquerading Proxies need to prevent unauthorized >> access or denial-of-service (DoS) attacks from untrusted public >> networks. >> >> o Man-in-the-middle attack by untrusted IPFIX Mediator >> >> The Collector-Mediator-Exporter structure model would increase the >> risk of the man-in-the-middle attack. >> >> o Configuration on IPFIX Mediation >> >> In the case of IPFIX Distributors and IPFIX Masquerading Proxies, >> an accidental misconfiguration and unauthorized access to >> configuration data could lead to the crucial problem of disclosure >> of confidential traffic data. >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------000800050204060706040001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard,

Thinking some more, I would like to come back to that point below.



6.8.  Consideration for Aggregation

   In case of Flow Key aggregation, Time Composition, and Spatial
   Composition, there are the following considerations:

   o  Aggregation rule for non Flow Keys
    

"non Flow Keys" => "non-key fields"

  
      There are no obvious rules of non Flow Keys.  For example, if an
    

"non Flow Keys" => "non-key fields"

  
      IPFIX Mediation receives two Flow Records with different DSCP
      values, and this DSCP field is not a Flow Key, those two Flow
      Records can be aggregated based on the Flow Keys value.  However,
      there is no rules for what the DSCP value should be for the
      aggregated Data Record.  Potential solutions are: the value of
    

Actually, there is a rule!
Unless specified differently, the value of the first packet must be
included in the record. Hence, as long as timestamps are present and
allow to determine which one of the Flow Records includes the earliest
packet, the decision is evident!
I agree with this rule on Exporter.
However, for a Mediator, it's not obvious that we should follow it.
Anyway, it should be specified in the mediation framework or protocol draft.
In the mean time, I would like to keep this issue in the problem statement.

Regards, Benoit.

  
      single of the two DSCP, the value 0 (in this case, the value 0 is
      a valid DSCP value), or removing a DSCP field in its Data Record.

   o  Configured Selection Fraction on aggregation

      There is no obvious rules of how to compute Configured Selection
      Fraction, and whether a Mediator should report Configured
    

remove ", and whether....,"
It is obvious, that Configured or Attained Selection Fraction is
necessary to interpret the Flow Records.


  
      Selection Fraction, when aggregation resulting from Sampling.  For
    

"...when aggregating IPFIX Flow Records of sampled packets."

  
      example, special care must be taken in the following: aggregation
      resulting from the different Configured Selection Fraction,
      aggregation resulting from different Sampling techniques, such as
      Systematic Count-Based Sampling and Random n-out-of-N Sampling
      etc.
    


  
7.  Summary and Conclusion

   This document described the problems that network administrators have
   been facing, the applicability of IPFIX Mediation to these problems,
   and the problems related to the implementation of IPFIX Mediators.
   To assist the operations of the Exporters and Collectors, there are
   various IPFIX Mediations from which the administrators may select.
   Examples of the applicability of IPFIX Mediation are as follows.

   o  Regarding large-scale measurement system, IPFIX Concentrators or
      IPFIX Distributors help to achieve traffic analysis with high data
      accuracy and fine flow granularity even as IP traffic grows.  As
      IPFIX Mediation capabilities, Flow selection Sampling,
    

flow sampling?

  
      aggregation, and composition are effective.

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

   o  Regarding the distribution of Data Records, IPFIX Distributors
      help to achieve multipurpose traffic analysis for different
      organizations, or help to achieve respective traffic analysis
      based on Data Record types(IPv4, IPv6, MPLS, and VPN).

   o  Regarding IPFIX Exporting across domains, IPFIX Masquerading
    

exporting

  
      Proxies help administrators to anonymize or filter Flow Records/
    

Data Records

  
      Packet Reports, preventing privacy violations.

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

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

   o  Both Observation Point and IPFIX Message 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  IPFIX Mediators are required to manage Transport Sessions,
      Template IDs, and Observation Domain IDs.  Otherwise, anomalous
      IPFIX messages could be created.

   o  Data advertised by Option Templates from the Original Exporter,
    

_Options_ Templates

better:
"Options Data Records exported by the Original Exporter, such as those
reporting the Sampling rate...."

Maybe the term "Options Data Record" should be introduced to simplify
things. BTW, we had the same problem in per-sctp-stream, and always
wrote "Data Record defined by an Options Template Record", which is not
very easy to read.

  
      such as the Sampling rate and Sampling algorithm used, might be
      lost.  If a Collector is not informed of current Sampling rates,
      traffic information might become worthless.

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


  
8.  Security Considerations

   A flow-based measurement system must prevent potential security
   threats: the disclosure of confidential traffic data, injection of
   incorrect data, and unauthorized access to traffic data.  These
   security threats of the IPFIX protocol are covered by the security
   considerations section in [RFC5101] and are still valid for IPFIX
   Mediators.

   And a measurement system must also prevent following security threats
    

"...the following..."

  
   related to IPFIX Mediation:

   o  Attacks against IPFIX Mediator

      IPFIX Mediators can be considered as a prime target for attacks,
      as an alternative to IPFIX Exporters and Collectors.  IPFIX
      Proxies or Masquerading Proxies need to prevent unauthorized
      access or denial-of-service (DoS) attacks from untrusted public
      networks.

   o  Man-in-the-middle attack by untrusted IPFIX Mediator

      The Collector-Mediator-Exporter structure model would increase the
      risk of the man-in-the-middle attack.

   o  Configuration on IPFIX Mediation

      In the case of IPFIX Distributors and IPFIX Masquerading Proxies,
      an accidental misconfiguration and unauthorized access to
      configuration data could lead to the crucial problem of disclosure
      of confidential traffic data.
    


  

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------000800050204060706040001-- From muenz@net.in.tum.de Tue Jul 28 01:41:35 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760E13A69C8; Tue, 28 Jul 2009 01:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKw82O23rL3w; Tue, 28 Jul 2009 01:41:31 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id CECF93A6DB9; Tue, 28 Jul 2009 01:41:30 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 3F232480F0; Tue, 28 Jul 2009 10:41:29 +0200 (CEST) Received: from [131.159.20.251] (vpn-1.net.in.tum.de [131.159.20.251]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id DCF0E50BD; Tue, 28 Jul 2009 10:41:28 +0200 (CEST) Message-ID: <4A6EB9BB.9040002@net.in.tum.de> Date: Tue, 28 Jul 2009 10:41:31 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: syslog@ietf.org, "ipfix@ietf.org" Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070108000207050009070503" X-Virus-Scanned: ClamAV using ClamSMTP Cc: Michael Tuexen , Robin Seggelmann , Daniel Mentz Subject: [IPFIX] Missing dead peer detection in DTLS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:41:35 -0000 This is a cryptographically signed message in MIME format. --------------ms070108000207050009070503 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, This mail goes to the ipfix and syslog mailing lists in order to summarize the common issues regarding DTLS. IPFIX specifies support of DTLS as mandatory for transport over UDP and SCTP in RFC5101. In SYSLOG, it is intended to standardize DTLS for transport over UDP. In IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, and we will have a first implementation of IPFIX-over-DTLS/SCTP very soon. During this implementation effort, we found that the current specification of DTLS/UDP has a severe flaw when used with unidirectional protocols (like IPFIX): The sender cannot recognize if the receiver has crashed and lost the DTLS state. We discuss this issue in a draft: http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00 http://www.ietf.org/proceedings/75/slides/ipfix-6.pdf I've had a look at draft-feng-syslog-transport-dtls-01 and draft-petch-gerhards-syslog-transport-dtls-02. It seems that this problem has not yet been covered, although the problem should be the same for SYSLOG. As a solution, the DTLS Heartbeat Extension has been proposed very recent= ly: http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00 A feature patch for OpenSSL is available: http://sctp.fh-muenster.de/dtls-patches.html#features So, I think that we should support this standardization initiative as it solves our problem. For IPFIX and SYSLOG over DTLS/UDP, we then can specify that the DTLS Heartbeat Extension MUST be implemented. Dan suggested to have a single document solving the DTLS issues regarding unidirectional protocols. I think that such a document is not needed if we have DTLS Heartbeat Extension. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms070108000207050009070503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzI4MDg0MTMxWjAjBgkqhkiG9w0BCQQxFgQU tOEFwnKDog7FB4yKUX2Npk55h6gwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAFTC9aCUItVHApTCoxogSFoiRy/jOO6obyTjAsUNaY5Aq1s0 rKsZZ5v0uRKMuXmWiIfG05tCTHZCigHrvcYcdo4qo+7x+Km2XTNGNP5Wmgz3tpbKul1w4bPn WJJEgXBOpDUueed1dF6FcJO68AGJqMeOFO4wORy2s/3wqMisxYfheOz7lEUSeP4zg36fyLnV ibaOiI0IwhyP8kACPGU4ivJ4QRa4ktGqiMTdmRoJarOqQnQzi4OzpP/zGQPpXLM3Yjh9CmVB DTIgk78xPE4hfQImiO0jhhDSzmoGP/sEAGK7Tc/sfotC7obzhrEBhdN2AxXB8FN8nqtt6bgp 20AsWr0AAAAAAAA= --------------ms070108000207050009070503-- From muenz@net.in.tum.de Tue Jul 28 02:22:16 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125FA3A6CEE for ; Tue, 28 Jul 2009 02:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQDcuihiH4Xq for ; Tue, 28 Jul 2009 02:22:14 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) by core3.amsl.com (Postfix) with ESMTP id 8F3053A6D17 for ; Tue, 28 Jul 2009 02:22:14 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 5A795485B0; Tue, 28 Jul 2009 11:22:11 +0200 (CEST) Received: from [131.159.20.251] (vpn-1.net.in.tum.de [131.159.20.251]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 118C5540F; Tue, 28 Jul 2009 11:22:11 +0200 (CEST) Message-ID: <4A6EC345.9060109@net.in.tum.de> Date: Tue, 28 Jul 2009 11:22:13 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Benoit Claise References: <4A1BE50E.6040407@net.in.tum.de> <4A6EB8AE.5000204@cisco.com> In-Reply-To: <4A6EB8AE.5000204@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000106070203040803090705" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:22:16 -0000 This is a cryptographically signed message in MIME format. --------------ms000106070203040803090705 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit, Benoit Claise wrote: > Gerhard, >=20 > Thinking some more, I would like to come back to that point below. >=20 >>> 6.8. Consideration for Aggregation >>> >>> In case of Flow Key aggregation, Time Composition, and Spatial >>> Composition, there are the following considerations: >>> >>> o Aggregation rule for non Flow Keys >> >> "non Flow Keys" =3D> "non-key fields" >> >>> There are no obvious rules of non Flow Keys. For example, if a= n >>> =20 >> >> "non Flow Keys" =3D> "non-key fields" >> =20 >>> IPFIX Mediation receives two Flow Records with different DSCP >>> values, and this DSCP field is not a Flow Key, those two Flow >>> Records can be aggregated based on the Flow Keys value. Howeve= r, >>> there is no rules for what the DSCP value should be for the >>> aggregated Data Record. Potential solutions are: the value of >> >> Actually, there is a rule! >> Unless specified differently, the value of the first packet must be >> included in the record. Hence, as long as timestamps are present and >> allow to determine which one of the Flow Records includes the earliest= >> packet, the decision is evident! >> =20 > I agree with this rule on Exporter. > However, for a Mediator, it's not obvious that we should follow it. > Anyway, it should be specified in the mediation framework or protocol d= raft. > In the mean time, I would like to keep this issue in the problem statem= ent. RFC5102: If they do not serve as Flow Keys, their value may change from packet to packet within a single Flow. For Information Elements with values that are derived from fields of packets or from packet treatment and for which the value may change from packet to packet within a single Flow, the IPFIX information model defines that their value is determined *by the first packet* observed for the corresponding Flow, unless the description of the Information Element explicitly specifies a different semantics. So, if a Collector receives a Flow Record with non-key field ipDiffServCodePoint, it can assume that this is the DSCP value of the first packet of all packets in the Flow. Are you suggesting that RFC5102 is not valid for Mediator? I'm not sure if this is useful. If you want to keep this issue in the problem statement draft, the text should be changed. It should be clarified that RFC5102 specifies that a non-key field value is taken from the first packet. The issue I see is that a Mediator might have problems to determine which one of the original Flow Records contains the first packet. For example, the flow start timestamp might be missing or have equal values for multiple original Flow Records. If the router clocks are not very well synchronized, the timestamps may be biased. Regards, Gerhard > Regards, Benoit. >=20 >> =20 >>> single of the two DSCP, the value 0 (in this case, the value 0 = is >>> a valid DSCP value), or removing a DSCP field in its Data Recor= d. >>> >>> o Configured Selection Fraction on aggregation >>> >>> There is no obvious rules of how to compute Configured Selectio= n >>> Fraction, and whether a Mediator should report Configured >>> =20 >> >> remove ", and whether....," >> It is obvious, that Configured or Attained Selection Fraction is >> necessary to interpret the Flow Records. >> >> >> =20 >>> Selection Fraction, when aggregation resulting from Sampling. = For >>> =20 >> >> "...when aggregating IPFIX Flow Records of sampled packets." >> >> =20 >>> example, special care must be taken in the following: aggregati= on >>> resulting from the different Configured Selection Fraction, >>> aggregation resulting from different Sampling techniques, such = as >>> Systematic Count-Based Sampling and Random n-out-of-N Sampling >>> etc. >>> =20 >> >> >> =20 >>> 7. Summary and Conclusion >>> >>> This document described the problems that network administrators h= ave >>> been facing, the applicability of IPFIX Mediation to these problem= s, >>> and the problems related to the implementation of IPFIX Mediators.= >>> To assist the operations of the Exporters and Collectors, there ar= e >>> various IPFIX Mediations from which the administrators may select.= >>> Examples of the applicability of IPFIX Mediation are as follows. >>> >>> o Regarding large-scale measurement system, IPFIX Concentrators o= r >>> IPFIX Distributors help to achieve traffic analysis with high d= ata >>> accuracy and fine flow granularity even as IP traffic grows. A= s >>> IPFIX Mediation capabilities, Flow selection Sampling, >>> =20 >> >> flow sampling? >> >> =20 >>> aggregation, and composition are effective. >>> >>> o Regarding data retention, IPFIX Mediators enhance the export >>> reliability, and the storage of the measurement system. >>> >>> o Regarding the distribution of Data Records, IPFIX Distributors >>> help to achieve multipurpose traffic analysis for different >>> organizations, or help to achieve respective traffic analysis >>> based on Data Record types(IPv4, IPv6, MPLS, and VPN). >>> >>> o Regarding IPFIX Exporting across domains, IPFIX Masquerading >>> =20 >> >> exporting >> >> =20 >>> Proxies help administrators to anonymize or filter Flow Records= / >>> =20 >> >> Data Records >> >> =20 >>> Packet Reports, preventing privacy violations. >>> >>> o Regarding interoperability, IPFIX Proxies provide interoperabil= ity >>> between legacy protocols and IPFIX, even during the migration >>> period to IPFIX. >>> >>> As a result, the IPFIX Mediation benefits become apparent. Howeve= r, >>> there are still some open issues with the use of IPFIX Mediators. >>> >>> o Both Observation Point and IPFIX Message header information, su= ch >>> as the Exporter IP address, Observation Domain ID, and Export T= ime >>> field, might be lost. This data should therefore be communicat= ed >>> between the Original Exporter and Collector via the IPFIX >>> Mediator. >>> >>> o IPFIX Mediators are required to manage Transport Sessions, >>> Template IDs, and Observation Domain IDs. Otherwise, anomalous= >>> IPFIX messages could be created. >>> >>> o Data advertised by Option Templates from the Original Exporter,= >>> =20 >> >> _Options_ Templates >> >> better: >> "Options Data Records exported by the Original Exporter, such as those= >> reporting the Sampling rate...." >> >> Maybe the term "Options Data Record" should be introduced to simplify >> things. BTW, we had the same problem in per-sctp-stream, and always >> wrote "Data Record defined by an Options Template Record", which is no= t >> very easy to read. >> >> =20 >>> such as the Sampling rate and Sampling algorithm used, might be= >>> lost. If a Collector is not informed of current Sampling rates= , >>> traffic information might become worthless. >>> >>> These problems stem from the fact that no standards regarding IPFI= X >>> Mediation have been set. In particular, the minimum set of >>> information that should be communicated between Original Exporters= >>> and Collectors, the management between different IPFIX Transport >>> Sessions, and the internal components of IPFIX Mediators should be= >>> standardized. >>> =20 >> >> >> =20 >>> 8. Security Considerations >>> >>> A flow-based measurement system must prevent potential security >>> threats: the disclosure of confidential traffic data, injection of= >>> incorrect data, and unauthorized access to traffic data. These >>> security threats of the IPFIX protocol are covered by the security= >>> considerations section in [RFC5101] and are still valid for IPFIX >>> Mediators. >>> >>> And a measurement system must also prevent following security thre= ats >>> =20 >> >> "...the following..." >> >> =20 >>> related to IPFIX Mediation: >>> >>> o Attacks against IPFIX Mediator >>> >>> IPFIX Mediators can be considered as a prime target for attacks= , >>> as an alternative to IPFIX Exporters and Collectors. IPFIX >>> Proxies or Masquerading Proxies need to prevent unauthorized >>> access or denial-of-service (DoS) attacks from untrusted public= >>> networks. >>> >>> o Man-in-the-middle attack by untrusted IPFIX Mediator >>> >>> The Collector-Mediator-Exporter structure model would increase = the >>> risk of the man-in-the-middle attack. >>> >>> o Configuration on IPFIX Mediation >>> >>> In the case of IPFIX Distributors and IPFIX Masquerading Proxie= s, >>> an accidental misconfiguration and unauthorized access to >>> configuration data could lead to the crucial problem of disclos= ure >>> of confidential traffic data. >>> =20 >> >> >> =20 >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> =20 >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms000106070203040803090705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzI4MDkyMjEzWjAjBgkqhkiG9w0BCQQxFgQU nW8JJpPRW+VpaPEcRwqiuJhe7n0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBADDIeqMW6X6ewcNlS6G9JrYPoBvy4jx8LSXadgMQIu9Pplm5 URtV4mCd0UtkzbdIDPMKo9d4TDpuTq+xKygSkJm41oGolgAPDRAoOxCVt5+2clgiqM+d+ImE SIHlmPDl8yZwptkQZneF26lvMTYqorr+JkgsUFpYE4nvaeNFHE7i9qeNf4j1YqmnJfypgTRC d3s+LeLM5IPrR+9k5r4/tPfP2uaI+RgaeXaf19rilxoJooc+DsaA4S6O+CcsH0hcTb1Dq/EW oNCQGhez6YNgwcockUGEOoc3iQtQFBS1bCLGKpfPPexhXevVJUgGYMDEKeLZHkhi8fXiwITe M+gvbo0AAAAAAAA= --------------ms000106070203040803090705-- From bclaise@cisco.com Tue Jul 28 02:29:56 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53BA3A67DB for ; Tue, 28 Jul 2009 02:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGPYDBDTf951 for ; Tue, 28 Jul 2009 02:29:55 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 9EAF93A6D29 for ; Tue, 28 Jul 2009 02:29:54 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6S9TSDe029295; Tue, 28 Jul 2009 11:29:28 +0200 (CEST) Received: from [10.61.81.25] (ams3-vpn-dhcp4378.cisco.com [10.61.81.25]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6S9TORi014385; Tue, 28 Jul 2009 11:29:24 +0200 (CEST) Message-ID: <4A6EC4F4.8080005@cisco.com> Date: Tue, 28 Jul 2009 11:29:24 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gerhard Muenz References: <4A1BE50E.6040407@net.in.tum.de> <4A6EB8AE.5000204@cisco.com> <4A6EC345.9060109@net.in.tum.de> In-Reply-To: <4A6EC345.9060109@net.in.tum.de> Content-Type: multipart/alternative; boundary="------------010002070004070002020503" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:29:56 -0000 This is a multi-part message in MIME format. --------------010002070004070002020503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, > Benoit, > > Benoit Claise wrote: > >> Gerhard, >> >> Thinking some more, I would like to come back to that point below. >> >> >>>> 6.8. Consideration for Aggregation >>>> >>>> In case of Flow Key aggregation, Time Composition, and Spatial >>>> Composition, there are the following considerations: >>>> >>>> o Aggregation rule for non Flow Keys >>>> >>> "non Flow Keys" => "non-key fields" >>> >>> >>>> There are no obvious rules of non Flow Keys. For example, if an >>>> >>>> >>> "non Flow Keys" => "non-key fields" >>> >>> >>>> IPFIX Mediation receives two Flow Records with different DSCP >>>> values, and this DSCP field is not a Flow Key, those two Flow >>>> Records can be aggregated based on the Flow Keys value. However, >>>> there is no rules for what the DSCP value should be for the >>>> aggregated Data Record. Potential solutions are: the value of >>>> >>> Actually, there is a rule! >>> Unless specified differently, the value of the first packet must be >>> included in the record. Hence, as long as timestamps are present and >>> allow to determine which one of the Flow Records includes the earliest >>> packet, the decision is evident! >>> >>> >> I agree with this rule on Exporter. >> However, for a Mediator, it's not obvious that we should follow it. >> Anyway, it should be specified in the mediation framework or protocol draft. >> In the mean time, I would like to keep this issue in the problem statement. >> > > RFC5102: > > If they do not serve as Flow Keys, their value may change from packet > to packet within a single Flow. For Information Elements with values > that are derived from fields of packets or from packet treatment and > for which the value may change from packet to packet within a single > Flow, the IPFIX information model defines that their value is > determined *by the first packet* observed for the corresponding Flow, > unless the description of the Information Element explicitly > specifies a different semantics. > > So, if a Collector receives a Flow Record with non-key field > ipDiffServCodePoint, it can assume that this is the DSCP value of the > first packet of all packets in the Flow. > > Are you suggesting that RFC5102 is not valid for Mediator? > No. This rule is still fine. However, in case of aggregation (this is the title for section 6.8 Consideration for Aggregation), the question is: what should be Mediator do? If the Mediator receives two Flow Records from different Exporters: one with DSCP=1 (non-key field) one with DCSP=2 (non-key field) What to put in the aggregated Flow Record is the question? And it's not obvious to me that it should be the one of the Flow Record that started the first... That's all I want to say. > I'm not sure if this is useful. > > If you want to keep this issue in the problem statement draft, the text > should be changed. It should be clarified that RFC5102 specifies that a > non-key field value is taken from the first packet. The issue I see is > that a Mediator might have problems to determine which one of the > original Flow Records contains the first packet. For example, the flow > start timestamp might be missing or have equal values for multiple > original Flow Records. If the router clocks are not very well > synchronized, the timestamps may be biased. > Two good reasons why the rule you mentioned can't be applied as it is, and why it's a real problem to be described in the problem statement. Regards, Benoit. > Regards, > Gerhard > > >> Regards, Benoit. >> >> >>> >>> >>>> single of the two DSCP, the value 0 (in this case, the value 0 is >>>> a valid DSCP value), or removing a DSCP field in its Data Record. >>>> >>>> o Configured Selection Fraction on aggregation >>>> >>>> There is no obvious rules of how to compute Configured Selection >>>> Fraction, and whether a Mediator should report Configured >>>> >>>> >>> remove ", and whether....," >>> It is obvious, that Configured or Attained Selection Fraction is >>> necessary to interpret the Flow Records. >>> >>> >>> >>> >>>> Selection Fraction, when aggregation resulting from Sampling. For >>>> >>>> >>> "...when aggregating IPFIX Flow Records of sampled packets." >>> >>> >>> >>>> example, special care must be taken in the following: aggregation >>>> resulting from the different Configured Selection Fraction, >>>> aggregation resulting from different Sampling techniques, such as >>>> Systematic Count-Based Sampling and Random n-out-of-N Sampling >>>> etc. >>>> >>>> >>> >>> >>>> 7. Summary and Conclusion >>>> >>>> This document described the problems that network administrators have >>>> been facing, the applicability of IPFIX Mediation to these problems, >>>> and the problems related to the implementation of IPFIX Mediators. >>>> To assist the operations of the Exporters and Collectors, there are >>>> various IPFIX Mediations from which the administrators may select. >>>> Examples of the applicability of IPFIX Mediation are as follows. >>>> >>>> o Regarding large-scale measurement system, IPFIX Concentrators or >>>> IPFIX Distributors help to achieve traffic analysis with high data >>>> accuracy and fine flow granularity even as IP traffic grows. As >>>> IPFIX Mediation capabilities, Flow selection Sampling, >>>> >>>> >>> flow sampling? >>> >>> >>> >>>> aggregation, and composition are effective. >>>> >>>> o Regarding data retention, IPFIX Mediators enhance the export >>>> reliability, and the storage of the measurement system. >>>> >>>> o Regarding the distribution of Data Records, IPFIX Distributors >>>> help to achieve multipurpose traffic analysis for different >>>> organizations, or help to achieve respective traffic analysis >>>> based on Data Record types(IPv4, IPv6, MPLS, and VPN). >>>> >>>> o Regarding IPFIX Exporting across domains, IPFIX Masquerading >>>> >>>> >>> exporting >>> >>> >>> >>>> Proxies help administrators to anonymize or filter Flow Records/ >>>> >>>> >>> Data Records >>> >>> >>> >>>> Packet Reports, preventing privacy violations. >>>> >>>> o Regarding interoperability, IPFIX Proxies provide interoperability >>>> between legacy protocols and IPFIX, even during the migration >>>> period to IPFIX. >>>> >>>> As a result, the IPFIX Mediation benefits become apparent. However, >>>> there are still some open issues with the use of IPFIX Mediators. >>>> >>>> o Both Observation Point and IPFIX Message 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 IPFIX Mediators are required to manage Transport Sessions, >>>> Template IDs, and Observation Domain IDs. Otherwise, anomalous >>>> IPFIX messages could be created. >>>> >>>> o Data advertised by Option Templates from the Original Exporter, >>>> >>>> >>> _Options_ Templates >>> >>> better: >>> "Options Data Records exported by the Original Exporter, such as those >>> reporting the Sampling rate...." >>> >>> Maybe the term "Options Data Record" should be introduced to simplify >>> things. BTW, we had the same problem in per-sctp-stream, and always >>> wrote "Data Record defined by an Options Template Record", which is not >>> very easy to read. >>> >>> >>> >>>> such as the Sampling rate and Sampling algorithm used, might be >>>> lost. If a Collector is not informed of current Sampling rates, >>>> traffic information might become worthless. >>>> >>>> These problems stem from the fact that no standards regarding IPFIX >>>> Mediation have been set. In particular, the minimum set of >>>> information that should be communicated between Original Exporters >>>> and Collectors, the management between different IPFIX Transport >>>> Sessions, and the internal components of IPFIX Mediators should be >>>> standardized. >>>> >>>> >>> >>> >>>> 8. Security Considerations >>>> >>>> A flow-based measurement system must prevent potential security >>>> threats: the disclosure of confidential traffic data, injection of >>>> incorrect data, and unauthorized access to traffic data. These >>>> security threats of the IPFIX protocol are covered by the security >>>> considerations section in [RFC5101] and are still valid for IPFIX >>>> Mediators. >>>> >>>> And a measurement system must also prevent following security threats >>>> >>>> >>> "...the following..." >>> >>> >>> >>>> related to IPFIX Mediation: >>>> >>>> o Attacks against IPFIX Mediator >>>> >>>> IPFIX Mediators can be considered as a prime target for attacks, >>>> as an alternative to IPFIX Exporters and Collectors. IPFIX >>>> Proxies or Masquerading Proxies need to prevent unauthorized >>>> access or denial-of-service (DoS) attacks from untrusted public >>>> networks. >>>> >>>> o Man-in-the-middle attack by untrusted IPFIX Mediator >>>> >>>> The Collector-Mediator-Exporter structure model would increase the >>>> risk of the man-in-the-middle attack. >>>> >>>> o Configuration on IPFIX Mediation >>>> >>>> In the case of IPFIX Distributors and IPFIX Masquerading Proxies, >>>> an accidental misconfiguration and unauthorized access to >>>> configuration data could lead to the crucial problem of disclosure >>>> of confidential traffic data. >>>> >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>> >>> > > --------------010002070004070002020503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard, 
Benoit,

Benoit Claise wrote:
  
Gerhard,

Thinking some more, I would like to come back to that point below.

    
6.8.  Consideration for Aggregation

   In case of Flow Key aggregation, Time Composition, and Spatial
   Composition, there are the following considerations:

   o  Aggregation rule for non Flow Keys
        
"non Flow Keys" => "non-key fields"

      
      There are no obvious rules of non Flow Keys.  For example, if an
    
        
"non Flow Keys" => "non-key fields"
  
      
      IPFIX Mediation receives two Flow Records with different DSCP
      values, and this DSCP field is not a Flow Key, those two Flow
      Records can be aggregated based on the Flow Keys value.  However,
      there is no rules for what the DSCP value should be for the
      aggregated Data Record.  Potential solutions are: the value of
        
Actually, there is a rule!
Unless specified differently, the value of the first packet must be
included in the record. Hence, as long as timestamps are present and
allow to determine which one of the Flow Records includes the earliest
packet, the decision is evident!
  
      
I agree with this rule on Exporter.
However, for a Mediator, it's not obvious that we should follow it.
Anyway, it should be specified in the mediation framework or protocol draft.
In the mean time, I would like to keep this issue in the problem statement.
    

RFC5102:

   If they do not serve as Flow Keys, their value may change from packet
   to packet within a single Flow.  For Information Elements with values
   that are derived from fields of packets or from packet treatment and
   for which the value may change from packet to packet within a single
   Flow, the IPFIX information model defines that their value is
   determined *by the first packet* observed for the corresponding Flow,
   unless the description of the Information Element explicitly
   specifies a different semantics.

So, if a Collector receives a Flow Record with non-key field
ipDiffServCodePoint, it can assume that this is the DSCP value of the
first packet of all packets in the Flow.

Are you suggesting that RFC5102 is not valid for Mediator?
No. This rule is still fine.
However, in case of aggregation (this is the title for section 6.8 Consideration for Aggregation), the question is: what should be Mediator do?
If the Mediator receives two Flow Records from different Exporters:
    one with DSCP=1 (non-key field)
    one with DCSP=2 (non-key field)
What to put in the aggregated Flow Record is the question? And it's not obvious to me that it should be the one of the Flow Record that started the first...
That's all I want to say.
I'm not sure if this is useful.

If you want to keep this issue in the problem statement draft, the text
should be changed. It should be clarified that RFC5102 specifies that a
non-key field value is taken from the first packet. The issue I see is
that a Mediator might have problems to determine which one of the
original Flow Records contains the first packet. For example, the flow
start timestamp might be missing or have equal values for multiple
original Flow Records. If the router clocks are not very well
synchronized, the timestamps may be biased.
Two good reasons why the rule you mentioned can't be applied as it is, and why it's a real problem to be described in the problem statement.

Regards, Benoit.
Regards,
Gerhard

  
Regards, Benoit.

    
  
      
      single of the two DSCP, the value 0 (in this case, the value 0 is
      a valid DSCP value), or removing a DSCP field in its Data Record.

   o  Configured Selection Fraction on aggregation

      There is no obvious rules of how to compute Configured Selection
      Fraction, and whether a Mediator should report Configured
    
        
remove ", and whether....,"
It is obvious, that Configured or Attained Selection Fraction is
necessary to interpret the Flow Records.


  
      
      Selection Fraction, when aggregation resulting from Sampling.  For
    
        
"...when aggregating IPFIX Flow Records of sampled packets."

  
      
      example, special care must be taken in the following: aggregation
      resulting from the different Configured Selection Fraction,
      aggregation resulting from different Sampling techniques, such as
      Systematic Count-Based Sampling and Random n-out-of-N Sampling
      etc.
    
        
  
      
7.  Summary and Conclusion

   This document described the problems that network administrators have
   been facing, the applicability of IPFIX Mediation to these problems,
   and the problems related to the implementation of IPFIX Mediators.
   To assist the operations of the Exporters and Collectors, there are
   various IPFIX Mediations from which the administrators may select.
   Examples of the applicability of IPFIX Mediation are as follows.

   o  Regarding large-scale measurement system, IPFIX Concentrators or
      IPFIX Distributors help to achieve traffic analysis with high data
      accuracy and fine flow granularity even as IP traffic grows.  As
      IPFIX Mediation capabilities, Flow selection Sampling,
    
        
flow sampling?

  
      
      aggregation, and composition are effective.

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

   o  Regarding the distribution of Data Records, IPFIX Distributors
      help to achieve multipurpose traffic analysis for different
      organizations, or help to achieve respective traffic analysis
      based on Data Record types(IPv4, IPv6, MPLS, and VPN).

   o  Regarding IPFIX Exporting across domains, IPFIX Masquerading
    
        
exporting

  
      
      Proxies help administrators to anonymize or filter Flow Records/
    
        
Data Records

  
      
      Packet Reports, preventing privacy violations.

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

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

   o  Both Observation Point and IPFIX Message 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  IPFIX Mediators are required to manage Transport Sessions,
      Template IDs, and Observation Domain IDs.  Otherwise, anomalous
      IPFIX messages could be created.

   o  Data advertised by Option Templates from the Original Exporter,
    
        
_Options_ Templates

better:
"Options Data Records exported by the Original Exporter, such as those
reporting the Sampling rate...."

Maybe the term "Options Data Record" should be introduced to simplify
things. BTW, we had the same problem in per-sctp-stream, and always
wrote "Data Record defined by an Options Template Record", which is not
very easy to read.

  
      
      such as the Sampling rate and Sampling algorithm used, might be
      lost.  If a Collector is not informed of current Sampling rates,
      traffic information might become worthless.

   These problems stem from the fact that no standards regarding IPFIX
   Mediation have been set.  In particular, the minimum set of
   information that should be communicated between Original Exporters
   and Collectors, the management between different IPFIX Transport
   Sessions, and the internal components of IPFIX Mediators should be
   standardized.
    
        
  
      
8.  Security Considerations

   A flow-based measurement system must prevent potential security
   threats: the disclosure of confidential traffic data, injection of
   incorrect data, and unauthorized access to traffic data.  These
   security threats of the IPFIX protocol are covered by the security
   considerations section in [RFC5101] and are still valid for IPFIX
   Mediators.

   And a measurement system must also prevent following security threats
    
        
"...the following..."

  
      
   related to IPFIX Mediation:

   o  Attacks against IPFIX Mediator

      IPFIX Mediators can be considered as a prime target for attacks,
      as an alternative to IPFIX Exporters and Collectors.  IPFIX
      Proxies or Masquerading Proxies need to prevent unauthorized
      access or denial-of-service (DoS) attacks from untrusted public
      networks.

   o  Man-in-the-middle attack by untrusted IPFIX Mediator

      The Collector-Mediator-Exporter structure model would increase the
      risk of the man-in-the-middle attack.

   o  Configuration on IPFIX Mediation

      In the case of IPFIX Distributors and IPFIX Masquerading Proxies,
      an accidental misconfiguration and unauthorized access to
      configuration data could lead to the crucial problem of disclosure
      of confidential traffic data.
    
        
  
------------------------------------------------------------------------

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------010002070004070002020503-- From bclaise@cisco.com Wed Jul 29 16:45:09 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A477128C106 for ; Wed, 29 Jul 2009 16:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhmw3pQMGyd9 for ; Wed, 29 Jul 2009 16:45:04 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 715133A70C9 for ; Wed, 29 Jul 2009 16:45:03 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6TNj357012616; Thu, 30 Jul 2009 01:45:03 +0200 (CEST) Received: from [10.61.95.4] (ams3-vpn-dhcp7941.cisco.com [10.61.95.4]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6TNj0EA008311; Thu, 30 Jul 2009 01:45:00 +0200 (CEST) Message-ID: <4A70DEFC.6090109@cisco.com> Date: Thu, 30 Jul 2009 01:45:00 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gerhard Muenz References: <4A1BE50E.6040407@net.in.tum.de> <4A6EB8AE.5000204@cisco.com> <4A6EC345.9060109@net.in.tum.de> <4A6EC4F4.8080005@cisco.com> In-Reply-To: <4A6EC4F4.8080005@cisco.com> Content-Type: multipart/alternative; boundary="------------080104070209050805060800" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 23:45:09 -0000 This is a multi-part message in MIME format. --------------080104070209050805060800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, I proposed this text. 6.8. Consideration for Aggregation Whether the aggregation is based on time or spatial composition, caution should be taken on how to aggregate non Flow Keys in a IPFIX Mediation. The IPFIX Information Model [RFC5102] is very clear about the content of a non Flow Key Information Element on the Original Exporter: its value is determined *by the first packet* observed for the corresponding Flow, unless the description of the Information Element explicitly specifies a different semantics. However, this rule might not apply in a Mediation Function. For example, if an IPFIX Mediator receives two Flow Records with identical Flow Keys values but with different DSCP values (the DSCP being a non Flow Key), what should be the DSCP value of the aggregated Flow Record? Potential solutions are: assign the value of the first received Flow Record within the aggregation time, assign a special value such as 0 (However, in this case, the value 0 is a valid DSCP value), remove the DSCP Information Element from the Data Record, change the DSCP Information Element from a non Flow Key to a Flow Key when re-exporting the aggregated Flow Record, etc... Furthermore, rules must be specify on how to aggregate the new Configured Selection Fraction an IPFIX Mediator should report when aggregating IPFIX Flow Records with different sampling rates. Finally, special care must be taken when aggregating Flow Records resulting from different Sampling techniques such as Systematic Count-Based Sampling and Random n-out-of-N Sampling for example. Feedback? Regards, Benoit. > Gerhard, >> Benoit, >> >> Benoit Claise wrote: >> >>> Gerhard, >>> >>> Thinking some more, I would like to come back to that point below. >>> >>> >>>>> 6.8. Consideration for Aggregation >>>>> >>>>> In case of Flow Key aggregation, Time Composition, and Spatial >>>>> Composition, there are the following considerations: >>>>> >>>>> o Aggregation rule for non Flow Keys >>>>> >>>> "non Flow Keys" => "non-key fields" >>>> >>>> >>>>> There are no obvious rules of non Flow Keys. For example, if an >>>>> >>>>> >>>> "non Flow Keys" => "non-key fields" >>>> >>>> >>>>> IPFIX Mediation receives two Flow Records with different DSCP >>>>> values, and this DSCP field is not a Flow Key, those two Flow >>>>> Records can be aggregated based on the Flow Keys value. However, >>>>> there is no rules for what the DSCP value should be for the >>>>> aggregated Data Record. Potential solutions are: the value of >>>>> >>>> Actually, there is a rule! >>>> Unless specified differently, the value of the first packet must be >>>> included in the record. Hence, as long as timestamps are present and >>>> allow to determine which one of the Flow Records includes the earliest >>>> packet, the decision is evident! >>>> >>>> >>> I agree with this rule on Exporter. >>> However, for a Mediator, it's not obvious that we should follow it. >>> Anyway, it should be specified in the mediation framework or protocol draft. >>> In the mean time, I would like to keep this issue in the problem statement. >>> >> >> RFC5102: >> >> If they do not serve as Flow Keys, their value may change from packet >> to packet within a single Flow. For Information Elements with values >> that are derived from fields of packets or from packet treatment and >> for which the value may change from packet to packet within a single >> Flow, the IPFIX information model defines that their value is >> determined *by the first packet* observed for the corresponding Flow, >> unless the description of the Information Element explicitly >> specifies a different semantics. >> >> So, if a Collector receives a Flow Record with non-key field >> ipDiffServCodePoint, it can assume that this is the DSCP value of the >> first packet of all packets in the Flow. >> >> Are you suggesting that RFC5102 is not valid for Mediator? >> > No. This rule is still fine. > However, in case of aggregation (this is the title for section 6.8 > Consideration for Aggregation), the question is: what should be > Mediator do? > If the Mediator receives two Flow Records from different Exporters: > one with DSCP=1 (non-key field) > one with DCSP=2 (non-key field) > What to put in the aggregated Flow Record is the question? And it's > not obvious to me that it should be the one of the Flow Record that > started the first... > That's all I want to say. >> I'm not sure if this is useful. >> >> If you want to keep this issue in the problem statement draft, the text >> should be changed. It should be clarified that RFC5102 specifies that a >> non-key field value is taken from the first packet. The issue I see is >> that a Mediator might have problems to determine which one of the >> original Flow Records contains the first packet. For example, the flow >> start timestamp might be missing or have equal values for multiple >> original Flow Records. If the router clocks are not very well >> synchronized, the timestamps may be biased. >> > Two good reasons why the rule you mentioned can't be applied as it is, > and why it's a real problem to be described in the problem statement. > > Regards, Benoit. >> Regards, >> Gerhard >> >> >>> Regards, Benoit. >>> >>> >>>> >>>> >>>>> single of the two DSCP, the value 0 (in this case, the value 0 is >>>>> a valid DSCP value), or removing a DSCP field in its Data Record. >>>>> >>>>> o Configured Selection Fraction on aggregation >>>>> >>>>> There is no obvious rules of how to compute Configured Selection >>>>> Fraction, and whether a Mediator should report Configured >>>>> >>>>> >>>> remove ", and whether....," >>>> It is obvious, that Configured or Attained Selection Fraction is >>>> necessary to interpret the Flow Records. >>>> >>>> >>>> >>>> >>>>> Selection Fraction, when aggregation resulting from Sampling. For >>>>> >>>>> >>>> "...when aggregating IPFIX Flow Records of sampled packets." >>>> >>>> >>>> >>>>> example, special care must be taken in the following: aggregation >>>>> resulting from the different Configured Selection Fraction, >>>>> aggregation resulting from different Sampling techniques, such as >>>>> Systematic Count-Based Sampling and Random n-out-of-N Sampling >>>>> etc. >>>>> >>>>> >>>> >>>> >>>>> 7. Summary and Conclusion >>>>> >>>>> This document described the problems that network administrators have >>>>> been facing, the applicability of IPFIX Mediation to these problems, >>>>> and the problems related to the implementation of IPFIX Mediators. >>>>> To assist the operations of the Exporters and Collectors, there are >>>>> various IPFIX Mediations from which the administrators may select. >>>>> Examples of the applicability of IPFIX Mediation are as follows. >>>>> >>>>> o Regarding large-scale measurement system, IPFIX Concentrators or >>>>> IPFIX Distributors help to achieve traffic analysis with high data >>>>> accuracy and fine flow granularity even as IP traffic grows. As >>>>> IPFIX Mediation capabilities, Flow selection Sampling, >>>>> >>>>> >>>> flow sampling? >>>> >>>> >>>> >>>>> aggregation, and composition are effective. >>>>> >>>>> o Regarding data retention, IPFIX Mediators enhance the export >>>>> reliability, and the storage of the measurement system. >>>>> >>>>> o Regarding the distribution of Data Records, IPFIX Distributors >>>>> help to achieve multipurpose traffic analysis for different >>>>> organizations, or help to achieve respective traffic analysis >>>>> based on Data Record types(IPv4, IPv6, MPLS, and VPN). >>>>> >>>>> o Regarding IPFIX Exporting across domains, IPFIX Masquerading >>>>> >>>>> >>>> exporting >>>> >>>> >>>> >>>>> Proxies help administrators to anonymize or filter Flow Records/ >>>>> >>>>> >>>> Data Records >>>> >>>> >>>> >>>>> Packet Reports, preventing privacy violations. >>>>> >>>>> o Regarding interoperability, IPFIX Proxies provide interoperability >>>>> between legacy protocols and IPFIX, even during the migration >>>>> period to IPFIX. >>>>> >>>>> As a result, the IPFIX Mediation benefits become apparent. However, >>>>> there are still some open issues with the use of IPFIX Mediators. >>>>> >>>>> o Both Observation Point and IPFIX Message 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 IPFIX Mediators are required to manage Transport Sessions, >>>>> Template IDs, and Observation Domain IDs. Otherwise, anomalous >>>>> IPFIX messages could be created. >>>>> >>>>> o Data advertised by Option Templates from the Original Exporter, >>>>> >>>>> >>>> _Options_ Templates >>>> >>>> better: >>>> "Options Data Records exported by the Original Exporter, such as those >>>> reporting the Sampling rate...." >>>> >>>> Maybe the term "Options Data Record" should be introduced to simplify >>>> things. BTW, we had the same problem in per-sctp-stream, and always >>>> wrote "Data Record defined by an Options Template Record", which is not >>>> very easy to read. >>>> >>>> >>>> >>>>> such as the Sampling rate and Sampling algorithm used, might be >>>>> lost. If a Collector is not informed of current Sampling rates, >>>>> traffic information might become worthless. >>>>> >>>>> These problems stem from the fact that no standards regarding IPFIX >>>>> Mediation have been set. In particular, the minimum set of >>>>> information that should be communicated between Original Exporters >>>>> and Collectors, the management between different IPFIX Transport >>>>> Sessions, and the internal components of IPFIX Mediators should be >>>>> standardized. >>>>> >>>>> >>>> >>>> >>>>> 8. Security Considerations >>>>> >>>>> A flow-based measurement system must prevent potential security >>>>> threats: the disclosure of confidential traffic data, injection of >>>>> incorrect data, and unauthorized access to traffic data. These >>>>> security threats of the IPFIX protocol are covered by the security >>>>> considerations section in [RFC5101] and are still valid for IPFIX >>>>> Mediators. >>>>> >>>>> And a measurement system must also prevent following security threats >>>>> >>>>> >>>> "...the following..." >>>> >>>> >>>> >>>>> related to IPFIX Mediation: >>>>> >>>>> o Attacks against IPFIX Mediator >>>>> >>>>> IPFIX Mediators can be considered as a prime target for attacks, >>>>> as an alternative to IPFIX Exporters and Collectors. IPFIX >>>>> Proxies or Masquerading Proxies need to prevent unauthorized >>>>> access or denial-of-service (DoS) attacks from untrusted public >>>>> networks. >>>>> >>>>> o Man-in-the-middle attack by untrusted IPFIX Mediator >>>>> >>>>> The Collector-Mediator-Exporter structure model would increase the >>>>> risk of the man-in-the-middle attack. >>>>> >>>>> o Configuration on IPFIX Mediation >>>>> >>>>> In the case of IPFIX Distributors and IPFIX Masquerading Proxies, >>>>> an accidental misconfiguration and unauthorized access to >>>>> configuration data could lead to the crucial problem of disclosure >>>>> of confidential traffic data. >>>>> >>>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>>> >>>> >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------080104070209050805060800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard,

I proposed this text.

6.8.  Consideration for Aggregation

Whether the aggregation is based on time or spatial composition, caution should be taken on how to aggregate non Flow Keys in a IPFIX Mediation.

The IPFIX Information Model [RFC5102] is very clear about the content of a non Flow Key Information Element on the Original Exporter: its value is determined *by the first packet* observed for the corresponding Flow, unless the description of the Information Element explicitly specifies a different semantics.

However, this rule might not apply in a Mediation Function. For example, if an IPFIX Mediator receives two Flow Records with identical Flow Keys values but with different DSCP values (the DSCP being a non Flow Key), what should be the DSCP value of the aggregated Flow Record? Potential solutions are: assign the value of the first received Flow Record within the aggregation time, assign a special value such as 0 (However, in this case, the value 0 is a valid DSCP value), remove the DSCP Information Element from the Data Record, change the DSCP Information Element from a non Flow Key to a Flow Key when re-exporting the aggregated Flow Record, etc...

Furthermore, rules must be specify on how to aggregate the new Configured Selection Fraction an IPFIX Mediator should report when aggregating IPFIX Flow Records with different sampling rates. Finally, special care must be taken when aggregating Flow Records resulting from different Sampling techniques such as Systematic Count-Based Sampling and Random n-out-of-N Sampling for example.


Feedback?

Regards, Benoit.

Gerhard, 
Benoit,

Benoit Claise wrote:
  
Gerhard,

Thinking some more, I would like to come back to that point below.

    
6.8.  Consideration for Aggregation

   In case of Flow Key aggregation, Time Composition, and Spatial
   Composition, there are the following considerations:

   o  Aggregation rule for non Flow Keys
        
"non Flow Keys" => "non-key fields"

      
      There are no obvious rules of non Flow Keys.  For example, if an
    
        
"non Flow Keys" => "non-key fields"
  
      
      IPFIX Mediation receives two Flow Records with different DSCP
      values, and this DSCP field is not a Flow Key, those two Flow
      Records can be aggregated based on the Flow Keys value.  However,
      there is no rules for what the DSCP value should be for the
      aggregated Data Record.  Potential solutions are: the value of
        
Actually, there is a rule!
Unless specified differently, the value of the first packet must be
included in the record. Hence, as long as timestamps are present and
allow to determine which one of the Flow Records includes the earliest
packet, the decision is evident!
  
      
I agree with this rule on Exporter.
However, for a Mediator, it's not obvious that we should follow it.
Anyway, it should be specified in the mediation framework or protocol draft.
In the mean time, I would like to keep this issue in the problem statement.
    

RFC5102:

   If they do not serve as Flow Keys, their value may change from packet
   to packet within a single Flow.  For Information Elements with values
   that are derived from fields of packets or from packet treatment and
   for which the value may change from packet to packet within a single
   Flow, the IPFIX information model defines that their value is
   determined *by the first packet* observed for the corresponding Flow,
   unless the description of the Information Element explicitly
   specifies a different semantics.

So, if a Collector receives a Flow Record with non-key field
ipDiffServCodePoint, it can assume that this is the DSCP value of the
first packet of all packets in the Flow.

Are you suggesting that RFC5102 is not valid for Mediator?
No. This rule is still fine.
However, in case of aggregation (this is the title for section 6.8 Consideration for Aggregation), the question is: what should be Mediator do?
If the Mediator receives two Flow Records from different Exporters:
    one with DSCP=1 (non-key field)
    one with DCSP=2 (non-key field)
What to put in the aggregated Flow Record is the question? And it's not obvious to me that it should be the one of the Flow Record that started the first...
That's all I want to say.
I'm not sure if this is useful.

If you want to keep this issue in the problem statement draft, the text
should be changed. It should be clarified that RFC5102 specifies that a
non-key field value is taken from the first packet. The issue I see is
that a Mediator might have problems to determine which one of the
original Flow Records contains the first packet. For example, the flow
start timestamp might be missing or have equal values for multiple
original Flow Records. If the router clocks are not very well
synchronized, the timestamps may be biased.
Two good reasons why the rule you mentioned can't be applied as it is, and why it's a real problem to be described in the problem statement.

Regards, Benoit.
Regards,
Gerhard

  
Regards, Benoit.

    
  
      
      single of the two DSCP, the value 0 (in this case, the value 0 is
      a valid DSCP value), or removing a DSCP field in its Data Record.

   o  Configured Selection Fraction on aggregation

      There is no obvious rules of how to compute Configured Selection
      Fraction, and whether a Mediator should report Configured
    
        
remove ", and whether....,"
It is obvious, that Configured or Attained Selection Fraction is
necessary to interpret the Flow Records.


  
      
      Selection Fraction, when aggregation resulting from Sampling.  For
    
        
"...when aggregating IPFIX Flow Records of sampled packets."

  
      
      example, special care must be taken in the following: aggregation
      resulting from the different Configured Selection Fraction,
      aggregation resulting from different Sampling techniques, such as
      Systematic Count-Based Sampling and Random n-out-of-N Sampling
      etc.
    
        
  
      
7.  Summary and Conclusion

   This document described the problems that network administrators have
   been facing, the applicability of IPFIX Mediation to these problems,
   and the problems related to the implementation of IPFIX Mediators.
   To assist the operations of the Exporters and Collectors, there are
   various IPFIX Mediations from which the administrators may select.
   Examples of the applicability of IPFIX Mediation are as follows.

   o  Regarding large-scale measurement system, IPFIX Concentrators or
      IPFIX Distributors help to achieve traffic analysis with high data
      accuracy and fine flow granularity even as IP traffic grows.  As
      IPFIX Mediation capabilities, Flow selection Sampling,
    
        
flow sampling?

  
      
      aggregation, and composition are effective.

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

   o  Regarding the distribution of Data Records, IPFIX Distributors
      help to achieve multipurpose traffic analysis for different
      organizations, or help to achieve respective traffic analysis
      based on Data Record types(IPv4, IPv6, MPLS, and VPN).

   o  Regarding IPFIX Exporting across domains, IPFIX Masquerading
    
        
exporting

  
      
      Proxies help administrators to anonymize or filter Flow Records/
    
        
Data Records

  
      
      Packet Reports, preventing privacy violations.

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

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

   o  Both Observation Point and IPFIX Message 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  IPFIX Mediators are required to manage Transport Sessions,
      Template IDs, and Observation Domain IDs.  Otherwise, anomalous
      IPFIX messages could be created.

   o  Data advertised by Option Templates from the Original Exporter,
    
        
_Options_ Templates

better:
"Options Data Records exported by the Original Exporter, such as those
reporting the Sampling rate...."

Maybe the term "Options Data Record" should be introduced to simplify
things. BTW, we had the same problem in per-sctp-stream, and always
wrote "Data Record defined by an Options Template Record", which is not
very easy to read.

  
      
      such as the Sampling rate and Sampling algorithm used, might be
      lost.  If a Collector is not informed of current Sampling rates,
      traffic information might become worthless.

   These problems stem from the fact that no standards regarding IPFIX
   Mediation have been set.  In particular, the minimum set of
   information that should be communicated between Original Exporters
   and Collectors, the management between different IPFIX Transport
   Sessions, and the internal components of IPFIX Mediators should be
   standardized.
    
        
  
      
8.  Security Considerations

   A flow-based measurement system must prevent potential security
   threats: the disclosure of confidential traffic data, injection of
   incorrect data, and unauthorized access to traffic data.  These
   security threats of the IPFIX protocol are covered by the security
   considerations section in [RFC5101] and are still valid for IPFIX
   Mediators.

   And a measurement system must also prevent following security threats
    
        
"...the following..."

  
      
   related to IPFIX Mediation:

   o  Attacks against IPFIX Mediator

      IPFIX Mediators can be considered as a prime target for attacks,
      as an alternative to IPFIX Exporters and Collectors.  IPFIX
      Proxies or Masquerading Proxies need to prevent unauthorized
      access or denial-of-service (DoS) attacks from untrusted public
      networks.

   o  Man-in-the-middle attack by untrusted IPFIX Mediator

      The Collector-Mediator-Exporter structure model would increase the
      risk of the man-in-the-middle attack.

   o  Configuration on IPFIX Mediation

      In the case of IPFIX Distributors and IPFIX Masquerading Proxies,
      an accidental misconfiguration and unauthorized access to
      configuration data could lead to the crucial problem of disclosure
      of confidential traffic data.
    
        
  
------------------------------------------------------------------------

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
  
      

  


_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------080104070209050805060800-- From muenz@net.in.tum.de Thu Jul 30 01:14:34 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 561FA28C15C for ; Thu, 30 Jul 2009 01:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pHVvbuqHFd3 for ; Thu, 30 Jul 2009 01:14:32 -0700 (PDT) Received: from customer-relay.songnetworks.se (customer-relay.songnetworks.se [195.42.210.9]) by core3.amsl.com (Postfix) with ESMTP id B6AC43A69A0 for ; Thu, 30 Jul 2009 01:13:38 -0700 (PDT) Received: from [10.59.1.175] (95.78.227.87.static.s-cy.siw.siwnet.net [87.227.78.95]) by customer-relay.songnetworks.se (Postfix) with ESMTP id 9441A24146; Thu, 30 Jul 2009 10:13:39 +0200 (CEST) Message-ID: <4A715635.4010308@net.in.tum.de> Date: Thu, 30 Jul 2009 10:13:41 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Benoit Claise References: <4A1BE50E.6040407@net.in.tum.de> <4A6EB8AE.5000204@cisco.com> <4A6EC345.9060109@net.in.tum.de> <4A6EC4F4.8080005@cisco.com> <4A70DEFC.6090109@cisco.com> In-Reply-To: <4A70DEFC.6090109@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090807010704040602030200" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 08:14:34 -0000 This is a cryptographically signed message in MIME format. --------------ms090807010704040602030200 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit Claise wrote: > Gerhard, >=20 > I proposed this text. >=20 > 6.8. Consideration for Aggregation >=20 > Whether the aggregation is based on time or spatial composition, cautio= n > should be taken on how to aggregate non Flow Keys in a IPFIX Mediation.= non Flow Keys =3D> non-key fields I was told to do so in ipfix configuration (by Paul, I think). either in a IPFIX Mediation =3D> in IPFIX Mediation or in a IPFIX Mediation =3D> in an IPFIX Mediator > The IPFIX Information Model [RFC5102] is very clear about the content o= f not sure if "information model" should be capitalized > a non Flow Key Information Element on the Original Exporter: its value > is determined *by the first packet* observed for the corresponding Flow= , > unless the description of the Information Element explicitly specifies = a > different semantics. RFC5102 does not talk about Original Exporter yet. What about: "The IPFIX information model [RFC5102] specifies that the value of non-key fields, which are derived from fields of packets or from packet treatment and for which the value may change from packet to packet within a single Flow, is determined by the first packet observed for the corresponding Flow, unless the description of the Information Element explicitly specifies a different semantics." > However, this rule might not apply in a Mediation Function. For example= , > if an IPFIX Mediator receives two Flow Records with identical Flow Keys= > values but with different DSCP values (the DSCP being a non Flow Key), > what should be the DSCP value of the aggregated Flow Record? Potential > solutions are: assign the value of the first received Flow Record withi= n > the aggregation time, assign a special value such as 0 (However, in thi= s > case, the value 0 is a valid DSCP value), remove the DSCP Information > Element from the Data Record, change the DSCP Information Element from = a > non Flow Key to a Flow Key when re-exporting the aggregated Flow Record= , > etc... What about: "However, this simple rule might not be appropriate when aggregating Flow Records which have different values in a non-key field. For example, if two Flows with identical Flow Key values are measured at different Observation Points, they may contain identical packets observed at different locations in the network and at different points in time. On their way from the first to the second Observation Point, some of the packet fields, such as the DSCP, may have changed. Hence, if the Information Element ipDiffServCodePoint is included as a non-key field, it can be useful to include the DSCP value observed at either the first or the second Observation Point in the resulting Flow Record, depending on the application." I'm sure that there are more examples. This is just one where it seems to be obvious to me that just looking at "the first packet" with respect to time does not make sense. Regards, Gerhard > Furthermore, rules must be specify on how to aggregate the new > Configured Selection Fraction an IPFIX Mediator should report when > aggregating IPFIX Flow Records with different sampling rates. Finally, > special care must be taken when aggregating Flow Records resulting from= > different Sampling techniques such as Systematic Count-Based Sampling > and Random n-out-of-N Sampling for example. >=20 >=20 > Feedback? >=20 > Regards, Benoit. >=20 >> Gerhard, >>> Benoit, >>> >>> Benoit Claise wrote: >>> =20 >>>> Gerhard, >>>> >>>> Thinking some more, I would like to come back to that point below. >>>> >>>> =20 >>>>>> 6.8. Consideration for Aggregation >>>>>> >>>>>> In case of Flow Key aggregation, Time Composition, and Spatial >>>>>> Composition, there are the following considerations: >>>>>> >>>>>> o Aggregation rule for non Flow Keys >>>>>> =20 >>>>> "non Flow Keys" =3D> "non-key fields" >>>>> >>>>> =20 >>>>>> There are no obvious rules of non Flow Keys. For example, i= f an >>>>>> =20 >>>>>> =20 >>>>> "non Flow Keys" =3D> "non-key fields" >>>>> =20 >>>>> =20 >>>>>> IPFIX Mediation receives two Flow Records with different DSC= P >>>>>> values, and this DSCP field is not a Flow Key, those two Flo= w >>>>>> Records can be aggregated based on the Flow Keys value. How= ever, >>>>>> there is no rules for what the DSCP value should be for the >>>>>> aggregated Data Record. Potential solutions are: the value = of >>>>>> =20 >>>>> Actually, there is a rule! >>>>> Unless specified differently, the value of the first packet must be= >>>>> included in the record. Hence, as long as timestamps are present an= d >>>>> allow to determine which one of the Flow Records includes the earli= est >>>>> packet, the decision is evident! >>>>> =20 >>>>> =20 >>>> I agree with this rule on Exporter. >>>> However, for a Mediator, it's not obvious that we should follow it. >>>> Anyway, it should be specified in the mediation framework or protoco= l draft. >>>> In the mean time, I would like to keep this issue in the problem sta= tement. >>>> =20 >>> >>> RFC5102: >>> >>> If they do not serve as Flow Keys, their value may change from pac= ket >>> to packet within a single Flow. For Information Elements with val= ues >>> that are derived from fields of packets or from packet treatment a= nd >>> for which the value may change from packet to packet within a sing= le >>> Flow, the IPFIX information model defines that their value is >>> determined *by the first packet* observed for the corresponding Fl= ow, >>> unless the description of the Information Element explicitly >>> specifies a different semantics. >>> >>> So, if a Collector receives a Flow Record with non-key field >>> ipDiffServCodePoint, it can assume that this is the DSCP value of the= >>> first packet of all packets in the Flow. >>> >>> Are you suggesting that RFC5102 is not valid for Mediator? >>> =20 >> No. This rule is still fine. >> However, in case of aggregation (this is the title for section 6.8 >> Consideration for Aggregation), the question is: what should be >> Mediator do? >> If the Mediator receives two Flow Records from different Exporters: >> one with DSCP=3D1 (non-key field) >> one with DCSP=3D2 (non-key field) >> What to put in the aggregated Flow Record is the question? And it's >> not obvious to me that it should be the one of the Flow Record that >> started the first... >> That's all I want to say. >>> I'm not sure if this is useful. >>> >>> If you want to keep this issue in the problem statement draft, the te= xt >>> should be changed. It should be clarified that RFC5102 specifies that= a >>> non-key field value is taken from the first packet. The issue I see i= s >>> that a Mediator might have problems to determine which one of the >>> original Flow Records contains the first packet. For example, the flo= w >>> start timestamp might be missing or have equal values for multiple >>> original Flow Records. If the router clocks are not very well >>> synchronized, the timestamps may be biased. >>> =20 >> Two good reasons why the rule you mentioned can't be applied as it is,= >> and why it's a real problem to be described in the problem statement. >> >> Regards, Benoit. >>> Regards, >>> Gerhard >>> >>> =20 >>>> Regards, Benoit. >>>> >>>> =20 >>>>> =20 >>>>> =20 >>>>>> single of the two DSCP, the value 0 (in this case, the value= 0 is >>>>>> a valid DSCP value), or removing a DSCP field in its Data Re= cord. >>>>>> >>>>>> o Configured Selection Fraction on aggregation >>>>>> >>>>>> There is no obvious rules of how to compute Configured Selec= tion >>>>>> Fraction, and whether a Mediator should report Configured >>>>>> =20 >>>>>> =20 >>>>> remove ", and whether....," >>>>> It is obvious, that Configured or Attained Selection Fraction is >>>>> necessary to interpret the Flow Records. >>>>> >>>>> >>>>> =20 >>>>> =20 >>>>>> Selection Fraction, when aggregation resulting from Sampling= =2E For >>>>>> =20 >>>>>> =20 >>>>> "...when aggregating IPFIX Flow Records of sampled packets." >>>>> >>>>> =20 >>>>> =20 >>>>>> example, special care must be taken in the following: aggreg= ation >>>>>> resulting from the different Configured Selection Fraction, >>>>>> aggregation resulting from different Sampling techniques, su= ch as >>>>>> Systematic Count-Based Sampling and Random n-out-of-N Sampli= ng >>>>>> etc. >>>>>> =20 >>>>>> =20 >>>>> =20 >>>>> =20 >>>>>> 7. Summary and Conclusion >>>>>> >>>>>> This document described the problems that network administrator= s have >>>>>> been facing, the applicability of IPFIX Mediation to these prob= lems, >>>>>> and the problems related to the implementation of IPFIX Mediato= rs. >>>>>> To assist the operations of the Exporters and Collectors, there= are >>>>>> various IPFIX Mediations from which the administrators may sele= ct. >>>>>> Examples of the applicability of IPFIX Mediation are as follows= =2E >>>>>> >>>>>> o Regarding large-scale measurement system, IPFIX Concentrator= s or >>>>>> IPFIX Distributors help to achieve traffic analysis with hig= h data >>>>>> accuracy and fine flow granularity even as IP traffic grows.= As >>>>>> IPFIX Mediation capabilities, Flow selection Sampling, >>>>>> =20 >>>>>> =20 >>>>> flow sampling? >>>>> >>>>> =20 >>>>> =20 >>>>>> aggregation, and composition are effective. >>>>>> >>>>>> o Regarding data retention, IPFIX Mediators enhance the export= >>>>>> reliability, and the storage of the measurement system. >>>>>> >>>>>> o Regarding the distribution of Data Records, IPFIX Distributo= rs >>>>>> help to achieve multipurpose traffic analysis for different >>>>>> organizations, or help to achieve respective traffic analysi= s >>>>>> based on Data Record types(IPv4, IPv6, MPLS, and VPN). >>>>>> >>>>>> o Regarding IPFIX Exporting across domains, IPFIX Masquerading= >>>>>> =20 >>>>>> =20 >>>>> exporting >>>>> >>>>> =20 >>>>> =20 >>>>>> Proxies help administrators to anonymize or filter Flow Reco= rds/ >>>>>> =20 >>>>>> =20 >>>>> Data Records >>>>> >>>>> =20 >>>>> =20 >>>>>> Packet Reports, preventing privacy violations. >>>>>> >>>>>> o Regarding interoperability, IPFIX Proxies provide interopera= bility >>>>>> between legacy protocols and IPFIX, even during the migratio= n >>>>>> period to IPFIX. >>>>>> >>>>>> As a result, the IPFIX Mediation benefits become apparent. How= ever, >>>>>> there are still some open issues with the use of IPFIX Mediator= s. >>>>>> >>>>>> o Both Observation Point and IPFIX Message header information,= such >>>>>> as the Exporter IP address, Observation Domain ID, and Expor= t Time >>>>>> field, might be lost. This data should therefore be communi= cated >>>>>> between the Original Exporter and Collector via the IPFIX >>>>>> Mediator. >>>>>> >>>>>> o IPFIX Mediators are required to manage Transport Sessions, >>>>>> Template IDs, and Observation Domain IDs. Otherwise, anomal= ous >>>>>> IPFIX messages could be created. >>>>>> >>>>>> o Data advertised by Option Templates from the Original Export= er, >>>>>> =20 >>>>>> =20 >>>>> _Options_ Templates >>>>> >>>>> better: >>>>> "Options Data Records exported by the Original Exporter, such as th= ose >>>>> reporting the Sampling rate...." >>>>> >>>>> Maybe the term "Options Data Record" should be introduced to simpli= fy >>>>> things. BTW, we had the same problem in per-sctp-stream, and always= >>>>> wrote "Data Record defined by an Options Template Record", which is= not >>>>> very easy to read. >>>>> >>>>> =20 >>>>> =20 >>>>>> such as the Sampling rate and Sampling algorithm used, might= be >>>>>> lost. If a Collector is not informed of current Sampling ra= tes, >>>>>> traffic information might become worthless. >>>>>> >>>>>> These problems stem from the fact that no standards regarding I= PFIX >>>>>> Mediation have been set. In particular, the minimum set of >>>>>> information that should be communicated between Original Export= ers >>>>>> and Collectors, the management between different IPFIX Transpor= t >>>>>> Sessions, and the internal components of IPFIX Mediators should= be >>>>>> standardized. >>>>>> =20 >>>>>> =20 >>>>> =20 >>>>> =20 >>>>>> 8. Security Considerations >>>>>> >>>>>> A flow-based measurement system must prevent potential security= >>>>>> threats: the disclosure of confidential traffic data, injection= of >>>>>> incorrect data, and unauthorized access to traffic data. These= >>>>>> security threats of the IPFIX protocol are covered by the secur= ity >>>>>> considerations section in [RFC5101] and are still valid for IPF= IX >>>>>> Mediators. >>>>>> >>>>>> And a measurement system must also prevent following security t= hreats >>>>>> =20 >>>>>> =20 >>>>> "...the following..." >>>>> >>>>> =20 >>>>> =20 >>>>>> related to IPFIX Mediation: >>>>>> >>>>>> o Attacks against IPFIX Mediator >>>>>> >>>>>> IPFIX Mediators can be considered as a prime target for atta= cks, >>>>>> as an alternative to IPFIX Exporters and Collectors. IPFIX >>>>>> Proxies or Masquerading Proxies need to prevent unauthorized= >>>>>> access or denial-of-service (DoS) attacks from untrusted pub= lic >>>>>> networks. >>>>>> >>>>>> o Man-in-the-middle attack by untrusted IPFIX Mediator >>>>>> >>>>>> The Collector-Mediator-Exporter structure model would increa= se the >>>>>> risk of the man-in-the-middle attack. >>>>>> >>>>>> o Configuration on IPFIX Mediation >>>>>> >>>>>> In the case of IPFIX Distributors and IPFIX Masquerading Pro= xies, >>>>>> an accidental misconfiguration and unauthorized access to >>>>>> configuration data could lead to the crucial problem of disc= losure >>>>>> of confidential traffic data. >>>>>> =20 >>>>>> =20 >>>>> =20 >>>>> -------------------------------------------------------------------= ----- >>>>> >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>> =20 >>>>> =20 >>> >>> =20 >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> =20 >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms090807010704040602030200 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzMwMDgxMzQxWjAjBgkqhkiG9w0BCQQxFgQU Eh7RvYBJbQQLs1nRpKXkmcG7NUEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBADfoNUeK1iUbW5MGEmYEgN2xpsF+C0tcQkJ4KMJz1ZaMOQ1+ XdNx9UQAcwND5Jf/lT9GHEQ/CaAY4K2c16G5ilOiFkz6CdhGLBDFFapKQB+IyDl9Q+OBlv9T znKUSH6NduI6DfF+X5H15df+9CGMURBXsTQL+9S5oBnfKcVcYCEZnNvJ5mRgtjMnKibNGZ1O frH1SMGWxKreLpg5ggspIi9BT/4B+5/buIo/ApX6pEg/nnQAVD2x9IolOyiUaqP2ZG0bXdo0 PDNzS3tQE12huzRgJg3oLpdvVWc0RUwvOYXG7Te6p4BQJupEDuXCFGV/a51hBFGfNyuLtGQX VTFQIswAAAAAAAA= --------------ms090807010704040602030200-- From bclaise@cisco.com Thu Jul 30 02:45:35 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7AD53A6AB1 for ; Thu, 30 Jul 2009 02:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMVyjoxPGvCm for ; Thu, 30 Jul 2009 02:45:33 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id EEF5B3A68D7 for ; Thu, 30 Jul 2009 02:45:32 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6U9jXqr010406; Thu, 30 Jul 2009 11:45:33 +0200 (CEST) Received: from [10.61.104.72] (dhcp-10-61-104-72.cisco.com [10.61.104.72]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6U9jVa5001449; Thu, 30 Jul 2009 11:45:31 +0200 (CEST) Message-ID: <4A716BBB.9020100@cisco.com> Date: Thu, 30 Jul 2009 11:45:31 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gerhard Muenz References: <4A1BE50E.6040407@net.in.tum.de> <4A6EB8AE.5000204@cisco.com> <4A6EC345.9060109@net.in.tum.de> <4A6EC4F4.8080005@cisco.com> <4A70DEFC.6090109@cisco.com> <4A715635.4010308@net.in.tum.de> In-Reply-To: <4A715635.4010308@net.in.tum.de> Content-Type: multipart/alternative; boundary="------------060509030606090204020206" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 09:45:36 -0000 This is a multi-part message in MIME format. --------------060509030606090204020206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, Thanks. Kobayashi-san and I came with the following proposal, strongly based on your proposal. Whether the aggregation is based on time or spatial composition, caution should be taken on how to aggregate non-key fields in IPFIX Mediation. The IPFIX information model [RFC5102] specifies that the value of non-key fields, which are derived from fields of packets or from packet treatment and for which the value may change from packet to packet within a single Flow, is determined by the first packet observed for the corresponding Flow, unless the description of the Information Element explicitly specifies a different semantics. However, this simple rule might not be appropriate when aggregating Flow Records which have different values in a non-key field. For example, if two Flows with identical Flow Key values are measured at different Observation Points, they may contain identical packets observed at different locations in the network and at different points in time. On their way from the first to the second Observation Point, some of the packet fields, such as the DSCP, may have changed. Hence, if the Information Element ipDiffServCodePoint is included as a non-key field, it can be useful to include the DSCP value observed at either the first or the second Observation Point in the resulting Flow Record, depending on the application. Other potential solutions include: removing the Information Element ipDiffServCodePoint from the Data Record when re-exporting the aggregate Flow Record, changing the Information Element ipDiffServCodePoint from a non key-field to a Flow Key when re-exporting the aggregated Flow Record, or assigning a non valid value for the Information Element to express to the Collector that this Information Element is meaningless. Fine? Regards, Benoit. > Benoit Claise wrote: > >> Gerhard, >> >> I proposed this text. >> >> 6.8. Consideration for Aggregation >> >> Whether the aggregation is based on time or spatial composition, caution >> should be taken on how to aggregate non Flow Keys in a IPFIX Mediation. >> > > non Flow Keys => non-key fields > I was told to do so in ipfix configuration (by Paul, I think). > > either > in a IPFIX Mediation => in IPFIX Mediation > or > in a IPFIX Mediation => in an IPFIX Mediator > > >> The IPFIX Information Model [RFC5102] is very clear about the content of >> > > not sure if "information model" should be capitalized > > >> a non Flow Key Information Element on the Original Exporter: its value >> is determined *by the first packet* observed for the corresponding Flow, >> unless the description of the Information Element explicitly specifies a >> different semantics. >> > > RFC5102 does not talk about Original Exporter yet. > > What about: > "The IPFIX information model [RFC5102] specifies that the value of > non-key fields, which are derived from fields of packets or from packet > treatment and for which the value may change from packet to packet > within a single Flow, is determined by the first packet observed for the > corresponding Flow, unless the description of the Information Element > explicitly specifies a different semantics." > > >> However, this rule might not apply in a Mediation Function. For example, >> if an IPFIX Mediator receives two Flow Records with identical Flow Keys >> values but with different DSCP values (the DSCP being a non Flow Key), >> what should be the DSCP value of the aggregated Flow Record? Potential >> solutions are: assign the value of the first received Flow Record within >> the aggregation time, assign a special value such as 0 (However, in this >> case, the value 0 is a valid DSCP value), remove the DSCP Information >> Element from the Data Record, change the DSCP Information Element from a >> non Flow Key to a Flow Key when re-exporting the aggregated Flow Record, >> etc... >> > > What about: > "However, this simple rule might not be appropriate when aggregating > Flow Records which have different values in a non-key field. For > example, if two Flows with identical Flow Key values are measured at > different Observation Points, they may contain identical packets > observed at different locations in the network and at different points > in time. On their way from the first to the second Observation Point, > some of the packet fields, such as the DSCP, may have changed. Hence, if > the Information Element ipDiffServCodePoint is included as a non-key > field, it can be useful to include the DSCP value observed at either the > first or the second Observation Point in the resulting Flow Record, > depending on the application." > > I'm sure that there are more examples. This is just one where it seems > to be obvious to me that just looking at "the first packet" with respect > to time does not make sense. > > Regards, > Gerhard > > > >> Furthermore, rules must be specify on how to aggregate the new >> Configured Selection Fraction an IPFIX Mediator should report when >> aggregating IPFIX Flow Records with different sampling rates. Finally, >> special care must be taken when aggregating Flow Records resulting from >> different Sampling techniques such as Systematic Count-Based Sampling >> and Random n-out-of-N Sampling for example. >> >> >> Feedback? >> >> Regards, Benoit. >> >> >>> Gerhard, >>> >>>> Benoit, >>>> >>>> Benoit Claise wrote: >>>> >>>> >>>>> Gerhard, >>>>> >>>>> Thinking some more, I would like to come back to that point below. >>>>> >>>>> >>>>> >>>>>>> 6.8. Consideration for Aggregation >>>>>>> >>>>>>> In case of Flow Key aggregation, Time Composition, and Spatial >>>>>>> Composition, there are the following considerations: >>>>>>> >>>>>>> o Aggregation rule for non Flow Keys >>>>>>> >>>>>>> >>>>>> "non Flow Keys" => "non-key fields" >>>>>> >>>>>> >>>>>> >>>>>>> There are no obvious rules of non Flow Keys. For example, if an >>>>>>> >>>>>>> >>>>>>> >>>>>> "non Flow Keys" => "non-key fields" >>>>>> >>>>>> >>>>>> >>>>>>> IPFIX Mediation receives two Flow Records with different DSCP >>>>>>> values, and this DSCP field is not a Flow Key, those two Flow >>>>>>> Records can be aggregated based on the Flow Keys value. However, >>>>>>> there is no rules for what the DSCP value should be for the >>>>>>> aggregated Data Record. Potential solutions are: the value of >>>>>>> >>>>>>> >>>>>> Actually, there is a rule! >>>>>> Unless specified differently, the value of the first packet must be >>>>>> included in the record. Hence, as long as timestamps are present and >>>>>> allow to determine which one of the Flow Records includes the earliest >>>>>> packet, the decision is evident! >>>>>> >>>>>> >>>>>> >>>>> I agree with this rule on Exporter. >>>>> However, for a Mediator, it's not obvious that we should follow it. >>>>> Anyway, it should be specified in the mediation framework or protocol draft. >>>>> In the mean time, I would like to keep this issue in the problem statement. >>>>> >>>>> >>>> RFC5102: >>>> >>>> If they do not serve as Flow Keys, their value may change from packet >>>> to packet within a single Flow. For Information Elements with values >>>> that are derived from fields of packets or from packet treatment and >>>> for which the value may change from packet to packet within a single >>>> Flow, the IPFIX information model defines that their value is >>>> determined *by the first packet* observed for the corresponding Flow, >>>> unless the description of the Information Element explicitly >>>> specifies a different semantics. >>>> >>>> So, if a Collector receives a Flow Record with non-key field >>>> ipDiffServCodePoint, it can assume that this is the DSCP value of the >>>> first packet of all packets in the Flow. >>>> >>>> Are you suggesting that RFC5102 is not valid for Mediator? >>>> >>>> >>> No. This rule is still fine. >>> However, in case of aggregation (this is the title for section 6.8 >>> Consideration for Aggregation), the question is: what should be >>> Mediator do? >>> If the Mediator receives two Flow Records from different Exporters: >>> one with DSCP=1 (non-key field) >>> one with DCSP=2 (non-key field) >>> What to put in the aggregated Flow Record is the question? And it's >>> not obvious to me that it should be the one of the Flow Record that >>> started the first... >>> That's all I want to say. >>> >>>> I'm not sure if this is useful. >>>> >>>> If you want to keep this issue in the problem statement draft, the text >>>> should be changed. It should be clarified that RFC5102 specifies that a >>>> non-key field value is taken from the first packet. The issue I see is >>>> that a Mediator might have problems to determine which one of the >>>> original Flow Records contains the first packet. For example, the flow >>>> start timestamp might be missing or have equal values for multiple >>>> original Flow Records. If the router clocks are not very well >>>> synchronized, the timestamps may be biased. >>>> >>>> >>> Two good reasons why the rule you mentioned can't be applied as it is, >>> and why it's a real problem to be described in the problem statement. >>> >>> Regards, Benoit. >>> >>>> Regards, >>>> Gerhard >>>> >>>> >>>> >>>>> Regards, Benoit. >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>>> single of the two DSCP, the value 0 (in this case, the value 0 is >>>>>>> a valid DSCP value), or removing a DSCP field in its Data Record. >>>>>>> >>>>>>> o Configured Selection Fraction on aggregation >>>>>>> >>>>>>> There is no obvious rules of how to compute Configured Selection >>>>>>> Fraction, and whether a Mediator should report Configured >>>>>>> >>>>>>> >>>>>>> >>>>>> remove ", and whether....," >>>>>> It is obvious, that Configured or Attained Selection Fraction is >>>>>> necessary to interpret the Flow Records. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Selection Fraction, when aggregation resulting from Sampling. For >>>>>>> >>>>>>> >>>>>>> >>>>>> "...when aggregating IPFIX Flow Records of sampled packets." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> example, special care must be taken in the following: aggregation >>>>>>> resulting from the different Configured Selection Fraction, >>>>>>> aggregation resulting from different Sampling techniques, such as >>>>>>> Systematic Count-Based Sampling and Random n-out-of-N Sampling >>>>>>> etc. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> 7. Summary and Conclusion >>>>>>> >>>>>>> This document described the problems that network administrators have >>>>>>> been facing, the applicability of IPFIX Mediation to these problems, >>>>>>> and the problems related to the implementation of IPFIX Mediators. >>>>>>> To assist the operations of the Exporters and Collectors, there are >>>>>>> various IPFIX Mediations from which the administrators may select. >>>>>>> Examples of the applicability of IPFIX Mediation are as follows. >>>>>>> >>>>>>> o Regarding large-scale measurement system, IPFIX Concentrators or >>>>>>> IPFIX Distributors help to achieve traffic analysis with high data >>>>>>> accuracy and fine flow granularity even as IP traffic grows. As >>>>>>> IPFIX Mediation capabilities, Flow selection Sampling, >>>>>>> >>>>>>> >>>>>>> >>>>>> flow sampling? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> aggregation, and composition are effective. >>>>>>> >>>>>>> o Regarding data retention, IPFIX Mediators enhance the export >>>>>>> reliability, and the storage of the measurement system. >>>>>>> >>>>>>> o Regarding the distribution of Data Records, IPFIX Distributors >>>>>>> help to achieve multipurpose traffic analysis for different >>>>>>> organizations, or help to achieve respective traffic analysis >>>>>>> based on Data Record types(IPv4, IPv6, MPLS, and VPN). >>>>>>> >>>>>>> o Regarding IPFIX Exporting across domains, IPFIX Masquerading >>>>>>> >>>>>>> >>>>>>> >>>>>> exporting >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Proxies help administrators to anonymize or filter Flow Records/ >>>>>>> >>>>>>> >>>>>>> >>>>>> Data Records >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Packet Reports, preventing privacy violations. >>>>>>> >>>>>>> o Regarding interoperability, IPFIX Proxies provide interoperability >>>>>>> between legacy protocols and IPFIX, even during the migration >>>>>>> period to IPFIX. >>>>>>> >>>>>>> As a result, the IPFIX Mediation benefits become apparent. However, >>>>>>> there are still some open issues with the use of IPFIX Mediators. >>>>>>> >>>>>>> o Both Observation Point and IPFIX Message 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 IPFIX Mediators are required to manage Transport Sessions, >>>>>>> Template IDs, and Observation Domain IDs. Otherwise, anomalous >>>>>>> IPFIX messages could be created. >>>>>>> >>>>>>> o Data advertised by Option Templates from the Original Exporter, >>>>>>> >>>>>>> >>>>>>> >>>>>> _Options_ Templates >>>>>> >>>>>> better: >>>>>> "Options Data Records exported by the Original Exporter, such as those >>>>>> reporting the Sampling rate...." >>>>>> >>>>>> Maybe the term "Options Data Record" should be introduced to simplify >>>>>> things. BTW, we had the same problem in per-sctp-stream, and always >>>>>> wrote "Data Record defined by an Options Template Record", which is not >>>>>> very easy to read. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> such as the Sampling rate and Sampling algorithm used, might be >>>>>>> lost. If a Collector is not informed of current Sampling rates, >>>>>>> traffic information might become worthless. >>>>>>> >>>>>>> These problems stem from the fact that no standards regarding IPFIX >>>>>>> Mediation have been set. In particular, the minimum set of >>>>>>> information that should be communicated between Original Exporters >>>>>>> and Collectors, the management between different IPFIX Transport >>>>>>> Sessions, and the internal components of IPFIX Mediators should be >>>>>>> standardized. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> 8. Security Considerations >>>>>>> >>>>>>> A flow-based measurement system must prevent potential security >>>>>>> threats: the disclosure of confidential traffic data, injection of >>>>>>> incorrect data, and unauthorized access to traffic data. These >>>>>>> security threats of the IPFIX protocol are covered by the security >>>>>>> considerations section in [RFC5101] and are still valid for IPFIX >>>>>>> Mediators. >>>>>>> >>>>>>> And a measurement system must also prevent following security threats >>>>>>> >>>>>>> >>>>>>> >>>>>> "...the following..." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> related to IPFIX Mediation: >>>>>>> >>>>>>> o Attacks against IPFIX Mediator >>>>>>> >>>>>>> IPFIX Mediators can be considered as a prime target for attacks, >>>>>>> as an alternative to IPFIX Exporters and Collectors. IPFIX >>>>>>> Proxies or Masquerading Proxies need to prevent unauthorized >>>>>>> access or denial-of-service (DoS) attacks from untrusted public >>>>>>> networks. >>>>>>> >>>>>>> o Man-in-the-middle attack by untrusted IPFIX Mediator >>>>>>> >>>>>>> The Collector-Mediator-Exporter structure model would increase the >>>>>>> risk of the man-in-the-middle attack. >>>>>>> >>>>>>> o Configuration on IPFIX Mediation >>>>>>> >>>>>>> In the case of IPFIX Distributors and IPFIX Masquerading Proxies, >>>>>>> an accidental misconfiguration and unauthorized access to >>>>>>> configuration data could lead to the crucial problem of disclosure >>>>>>> of confidential traffic data. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> _______________________________________________ >>>>>> IPFIX mailing list >>>>>> IPFIX@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>> >>>>>> >>>>>> >>>> >>>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>> >>> > > --------------060509030606090204020206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard,

Thanks. Kobayashi-san and I came with the following proposal, strongly based on your proposal.

Whether the aggregation is based on time or spatial composition, caution should be taken on how to aggregate non-key fields in IPFIX Mediation. The IPFIX information model [RFC5102] specifies that the value of non-key fields, which are derived from fields of packets or from packet treatment and for which the value may change from packet to packet within a single Flow, is determined by the first packet observed for the corresponding Flow, unless the description of the Information Element explicitly specifies a different semantics.

However, this simple rule might not be appropriate when aggregating Flow Records which have different values in a non-key field. For
example, if two Flows with identical Flow Key values are measured at different Observation Points, they may contain identical packets observed at different locations in the network and at different points in time. On their way from the first to the second Observation Point, some of the packet fields, such as the DSCP, may have changed. Hence, if the Information Element ipDiffServCodePoint is included as a non-key field, it can be useful to include the DSCP value observed at either the first or the second Observation Point in the resulting Flow Record, depending on the application.

Other potential solutions include: removing the Information Element ipDiffServCodePoint from the Data Record
when re-exporting the aggregate Flow Record, changing the Information Element ipDiffServCodePoint from a non key-field to a Flow Key when re-exporting the aggregated Flow Record, or assigning a non valid value for the Information Element to express to the Collector that this Information Element is meaningless.

Fine?

Regards, Benoit.

Benoit Claise wrote:
  
Gerhard,

I proposed this text.

6.8.  Consideration for Aggregation

Whether the aggregation is based on time or spatial composition, caution
should be taken on how to aggregate non Flow Keys in a IPFIX Mediation.
    

non Flow Keys => non-key fields
I was told to do so in ipfix configuration (by Paul, I think).

either
in a IPFIX Mediation => in IPFIX Mediation
or
in a IPFIX Mediation => in an IPFIX Mediator

  
The IPFIX Information Model [RFC5102] is very clear about the content of
    

not sure if "information model" should be capitalized

  
a non Flow Key Information Element on the Original Exporter: its value
is determined *by the first packet* observed for the corresponding Flow,
unless the description of the Information Element explicitly specifies a
different semantics.
    

RFC5102 does not talk about Original Exporter yet.

What about:
"The IPFIX information model [RFC5102] specifies that the value of
non-key fields, which are derived from fields of packets or from packet
treatment and for which the value may change from packet to packet
within a single Flow, is determined by the first packet observed for the
corresponding Flow, unless the description of the Information Element
explicitly specifies a different semantics."

  
However, this rule might not apply in a Mediation Function. For example,
if an IPFIX Mediator receives two Flow Records with identical Flow Keys
values but with different DSCP values (the DSCP being a non Flow Key),
what should be the DSCP value of the aggregated Flow Record? Potential
solutions are: assign the value of the first received Flow Record within
the aggregation time, assign a special value such as 0 (However, in this
case, the value 0 is a valid DSCP value), remove the DSCP Information
Element from the Data Record, change the DSCP Information Element from a
non Flow Key to a Flow Key when re-exporting the aggregated Flow Record,
etc...
    

What about:
"However, this simple rule might not be appropriate when aggregating
Flow Records which have different values in a non-key field. For
example, if two Flows with identical Flow Key values are measured at
different Observation Points, they may contain identical packets
observed at different locations in the network and at different points
in time. On their way from the first to the second Observation Point,
some of the packet fields, such as the DSCP, may have changed. Hence, if
the Information Element ipDiffServCodePoint is included as a non-key
field, it can be useful to include the DSCP value observed at either the
first or the second Observation Point in the resulting Flow Record,
depending on the application."

I'm sure that there are more examples. This is just one where it seems
to be obvious to me that just looking at "the first packet" with respect
to time does not make sense.

Regards,
Gerhard


  
Furthermore, rules must be specify on how to aggregate the new
Configured Selection Fraction an IPFIX Mediator should report when
aggregating IPFIX Flow Records with different sampling rates. Finally,
special care must be taken when aggregating Flow Records resulting from
different Sampling techniques such as Systematic Count-Based Sampling
and Random n-out-of-N Sampling for example.


Feedback?

Regards, Benoit.

    
Gerhard,
      
Benoit,

Benoit Claise wrote:
  
        
Gerhard,

Thinking some more, I would like to come back to that point below.

    
          
6.8.  Consideration for Aggregation

   In case of Flow Key aggregation, Time Composition, and Spatial
   Composition, there are the following considerations:

   o  Aggregation rule for non Flow Keys
        
              
"non Flow Keys" => "non-key fields"

      
            
      There are no obvious rules of non Flow Keys.  For example, if an
    
        
              
"non Flow Keys" => "non-key fields"
  
      
            
      IPFIX Mediation receives two Flow Records with different DSCP
      values, and this DSCP field is not a Flow Key, those two Flow
      Records can be aggregated based on the Flow Keys value.  However,
      there is no rules for what the DSCP value should be for the
      aggregated Data Record.  Potential solutions are: the value of
        
              
Actually, there is a rule!
Unless specified differently, the value of the first packet must be
included in the record. Hence, as long as timestamps are present and
allow to determine which one of the Flow Records includes the earliest
packet, the decision is evident!
  
      
            
I agree with this rule on Exporter.
However, for a Mediator, it's not obvious that we should follow it.
Anyway, it should be specified in the mediation framework or protocol draft.
In the mean time, I would like to keep this issue in the problem statement.
    
          
RFC5102:

   If they do not serve as Flow Keys, their value may change from packet
   to packet within a single Flow.  For Information Elements with values
   that are derived from fields of packets or from packet treatment and
   for which the value may change from packet to packet within a single
   Flow, the IPFIX information model defines that their value is
   determined *by the first packet* observed for the corresponding Flow,
   unless the description of the Information Element explicitly
   specifies a different semantics.

So, if a Collector receives a Flow Record with non-key field
ipDiffServCodePoint, it can assume that this is the DSCP value of the
first packet of all packets in the Flow.

Are you suggesting that RFC5102 is not valid for Mediator?
  
        
No. This rule is still fine.
However, in case of aggregation (this is the title for section 6.8
Consideration for Aggregation), the question is: what should be
Mediator do?
If the Mediator receives two Flow Records from different Exporters:
    one with DSCP=1 (non-key field)
    one with DCSP=2 (non-key field)
What to put in the aggregated Flow Record is the question? And it's
not obvious to me that it should be the one of the Flow Record that
started the first...
That's all I want to say.
      
I'm not sure if this is useful.

If you want to keep this issue in the problem statement draft, the text
should be changed. It should be clarified that RFC5102 specifies that a
non-key field value is taken from the first packet. The issue I see is
that a Mediator might have problems to determine which one of the
original Flow Records contains the first packet. For example, the flow
start timestamp might be missing or have equal values for multiple
original Flow Records. If the router clocks are not very well
synchronized, the timestamps may be biased.
  
        
Two good reasons why the rule you mentioned can't be applied as it is,
and why it's a real problem to be described in the problem statement.

Regards, Benoit.
      
Regards,
Gerhard

  
        
Regards, Benoit.

    
          
  
      
            
      single of the two DSCP, the value 0 (in this case, the value 0 is
      a valid DSCP value), or removing a DSCP field in its Data Record.

   o  Configured Selection Fraction on aggregation

      There is no obvious rules of how to compute Configured Selection
      Fraction, and whether a Mediator should report Configured
    
        
              
remove ", and whether....,"
It is obvious, that Configured or Attained Selection Fraction is
necessary to interpret the Flow Records.


  
      
            
      Selection Fraction, when aggregation resulting from Sampling.  For
    
        
              
"...when aggregating IPFIX Flow Records of sampled packets."

  
      
            
      example, special care must be taken in the following: aggregation
      resulting from the different Configured Selection Fraction,
      aggregation resulting from different Sampling techniques, such as
      Systematic Count-Based Sampling and Random n-out-of-N Sampling
      etc.
    
        
              
  
      
            
7.  Summary and Conclusion

   This document described the problems that network administrators have
   been facing, the applicability of IPFIX Mediation to these problems,
   and the problems related to the implementation of IPFIX Mediators.
   To assist the operations of the Exporters and Collectors, there are
   various IPFIX Mediations from which the administrators may select.
   Examples of the applicability of IPFIX Mediation are as follows.

   o  Regarding large-scale measurement system, IPFIX Concentrators or
      IPFIX Distributors help to achieve traffic analysis with high data
      accuracy and fine flow granularity even as IP traffic grows.  As
      IPFIX Mediation capabilities, Flow selection Sampling,
    
        
              
flow sampling?

  
      
            
      aggregation, and composition are effective.

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

   o  Regarding the distribution of Data Records, IPFIX Distributors
      help to achieve multipurpose traffic analysis for different
      organizations, or help to achieve respective traffic analysis
      based on Data Record types(IPv4, IPv6, MPLS, and VPN).

   o  Regarding IPFIX Exporting across domains, IPFIX Masquerading
    
        
              
exporting

  
      
            
      Proxies help administrators to anonymize or filter Flow Records/
    
        
              
Data Records

  
      
            
      Packet Reports, preventing privacy violations.

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

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

   o  Both Observation Point and IPFIX Message 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  IPFIX Mediators are required to manage Transport Sessions,
      Template IDs, and Observation Domain IDs.  Otherwise, anomalous
      IPFIX messages could be created.

   o  Data advertised by Option Templates from the Original Exporter,
    
        
              
_Options_ Templates

better:
"Options Data Records exported by the Original Exporter, such as those
reporting the Sampling rate...."

Maybe the term "Options Data Record" should be introduced to simplify
things. BTW, we had the same problem in per-sctp-stream, and always
wrote "Data Record defined by an Options Template Record", which is not
very easy to read.

  
      
            
      such as the Sampling rate and Sampling algorithm used, might be
      lost.  If a Collector is not informed of current Sampling rates,
      traffic information might become worthless.

   These problems stem from the fact that no standards regarding IPFIX
   Mediation have been set.  In particular, the minimum set of
   information that should be communicated between Original Exporters
   and Collectors, the management between different IPFIX Transport
   Sessions, and the internal components of IPFIX Mediators should be
   standardized.
    
        
              
  
      
            
8.  Security Considerations

   A flow-based measurement system must prevent potential security
   threats: the disclosure of confidential traffic data, injection of
   incorrect data, and unauthorized access to traffic data.  These
   security threats of the IPFIX protocol are covered by the security
   considerations section in [RFC5101] and are still valid for IPFIX
   Mediators.

   And a measurement system must also prevent following security threats
    
        
              
"...the following..."

  
      
            
   related to IPFIX Mediation:

   o  Attacks against IPFIX Mediator

      IPFIX Mediators can be considered as a prime target for attacks,
      as an alternative to IPFIX Exporters and Collectors.  IPFIX
      Proxies or Masquerading Proxies need to prevent unauthorized
      access or denial-of-service (DoS) attacks from untrusted public
      networks.

   o  Man-in-the-middle attack by untrusted IPFIX Mediator

      The Collector-Mediator-Exporter structure model would increase the
      risk of the man-in-the-middle attack.

   o  Configuration on IPFIX Mediation

      In the case of IPFIX Distributors and IPFIX Masquerading Proxies,
      an accidental misconfiguration and unauthorized access to
      configuration data could lead to the crucial problem of disclosure
      of confidential traffic data.
    
        
              
  
------------------------------------------------------------------------

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
  
      
            
  
        
------------------------------------------------------------------------

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------060509030606090204020206-- From muenz@net.in.tum.de Thu Jul 30 03:32:02 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24C3128C133 for ; Thu, 30 Jul 2009 03:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFblcxzkQJsE for ; Thu, 30 Jul 2009 03:32:00 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) by core3.amsl.com (Postfix) with ESMTP id DE4543A69AD for ; Thu, 30 Jul 2009 03:31:59 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 972D948317; Thu, 30 Jul 2009 12:31:59 +0200 (CEST) Received: from [131.159.20.251] (vpn-1.net.in.tum.de [131.159.20.251]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 1208F540F; Thu, 30 Jul 2009 12:31:58 +0200 (CEST) Message-ID: <4A7176A1.7020400@net.in.tum.de> Date: Thu, 30 Jul 2009 12:32:01 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Benoit Claise References: <4A1BE50E.6040407@net.in.tum.de> <4A6EB8AE.5000204@cisco.com> <4A6EC345.9060109@net.in.tum.de> <4A6EC4F4.8080005@cisco.com> <4A70DEFC.6090109@cisco.com> <4A715635.4010308@net.in.tum.de> <4A716BBB.9020100@cisco.com> In-Reply-To: <4A716BBB.9020100@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010705070102010409050905" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 10:32:02 -0000 This is a cryptographically signed message in MIME format. --------------ms010705070102010409050905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit, I do not like "assigning a non valid value for the Information Element to express to the Collector that this Information Element is meaningless" - this should only be considered as a work-around for devices which are not able to handle Templates appropriately. But if you want to keep this option, leave it in. Gerhard Benoit Claise wrote: > Gerhard, >=20 > Thanks. Kobayashi-san and I came with the following proposal, strongly > based on your proposal. >=20 > Whether the aggregation is based on time or spatial composition, cautio= n > should be taken on how to aggregate non-key fields in IPFIX Mediation. > The IPFIX information model [RFC5102] specifies that the value of > non-key fields, which are derived from fields of packets or from packet= > treatment and for which the value may change from packet to packet > within a single Flow, is determined by the first packet observed for th= e > corresponding Flow, unless the description of the Information Element > explicitly specifies a different semantics. >=20 > However, this simple rule might not be appropriate when aggregating Flo= w > Records which have different values in a non-key field. For > example, if two Flows with identical Flow Key values are measured at > different Observation Points, they may contain identical packets > observed at different locations in the network and at different points > in time. On their way from the first to the second Observation Point, > some of the packet fields, such as the DSCP, may have changed. Hence, i= f > the Information Element ipDiffServCodePoint is included as a non-key > field, it can be useful to include the DSCP value observed at either th= e > first or the second Observation Point in the resulting Flow Record, > depending on the application. >=20 > Other potential solutions include: removing the Information Element > ipDiffServCodePoint from the Data Record > when re-exporting the aggregate Flow Record, changing the Information > Element ipDiffServCodePoint from a non key-field to a Flow Key when > re-exporting the aggregated Flow Record, or assigning a non valid value= > for the Information Element to express to the Collector that this > Information Element is meaningless. >=20 > Fine? >=20 > Regards, Benoit. >=20 >> Benoit Claise wrote: >> =20 >>> Gerhard, >>> >>> I proposed this text. >>> >>> 6.8. Consideration for Aggregation >>> >>> Whether the aggregation is based on time or spatial composition, caut= ion >>> should be taken on how to aggregate non Flow Keys in a IPFIX Mediatio= n. >>> =20 >> >> non Flow Keys =3D> non-key fields >> I was told to do so in ipfix configuration (by Paul, I think). >> >> either >> in a IPFIX Mediation =3D> in IPFIX Mediation >> or >> in a IPFIX Mediation =3D> in an IPFIX Mediator >> >> =20 >>> The IPFIX Information Model [RFC5102] is very clear about the content= of >>> =20 >> >> not sure if "information model" should be capitalized >> >> =20 >>> a non Flow Key Information Element on the Original Exporter: its valu= e >>> is determined *by the first packet* observed for the corresponding Fl= ow, >>> unless the description of the Information Element explicitly specifie= s a >>> different semantics. >>> =20 >> >> RFC5102 does not talk about Original Exporter yet. >> >> What about: >> "The IPFIX information model [RFC5102] specifies that the value of >> non-key fields, which are derived from fields of packets or from packe= t >> treatment and for which the value may change from packet to packet >> within a single Flow, is determined by the first packet observed for t= he >> corresponding Flow, unless the description of the Information Element >> explicitly specifies a different semantics." >> >> =20 >>> However, this rule might not apply in a Mediation Function. For examp= le, >>> if an IPFIX Mediator receives two Flow Records with identical Flow Ke= ys >>> values but with different DSCP values (the DSCP being a non Flow Key)= , >>> what should be the DSCP value of the aggregated Flow Record? Potentia= l >>> solutions are: assign the value of the first received Flow Record wit= hin >>> the aggregation time, assign a special value such as 0 (However, in t= his >>> case, the value 0 is a valid DSCP value), remove the DSCP Information= >>> Element from the Data Record, change the DSCP Information Element fro= m a >>> non Flow Key to a Flow Key when re-exporting the aggregated Flow Reco= rd, >>> etc... >>> =20 >> >> What about: >> "However, this simple rule might not be appropriate when aggregating >> Flow Records which have different values in a non-key field. For >> example, if two Flows with identical Flow Key values are measured at >> different Observation Points, they may contain identical packets >> observed at different locations in the network and at different points= >> in time. On their way from the first to the second Observation Point, >> some of the packet fields, such as the DSCP, may have changed. Hence, = if >> the Information Element ipDiffServCodePoint is included as a non-key >> field, it can be useful to include the DSCP value observed at either t= he >> first or the second Observation Point in the resulting Flow Record, >> depending on the application." >> >> I'm sure that there are more examples. This is just one where it seems= >> to be obvious to me that just looking at "the first packet" with respe= ct >> to time does not make sense. >> >> Regards, >> Gerhard >> >> >> =20 >>> Furthermore, rules must be specify on how to aggregate the new >>> Configured Selection Fraction an IPFIX Mediator should report when >>> aggregating IPFIX Flow Records with different sampling rates. Finally= , >>> special care must be taken when aggregating Flow Records resulting fr= om >>> different Sampling techniques such as Systematic Count-Based Sampling= >>> and Random n-out-of-N Sampling for example. >>> >>> >>> Feedback? >>> >>> Regards, Benoit. >>> >>> =20 >>>> Gerhard, >>>> =20 >>>>> Benoit, >>>>> >>>>> Benoit Claise wrote: >>>>> =20 >>>>> =20 >>>>>> Gerhard, >>>>>> >>>>>> Thinking some more, I would like to come back to that point below.= >>>>>> >>>>>> =20 >>>>>> =20 >>>>>>>> 6.8. Consideration for Aggregation >>>>>>>> >>>>>>>> In case of Flow Key aggregation, Time Composition, and Spatia= l >>>>>>>> Composition, there are the following considerations: >>>>>>>> >>>>>>>> o Aggregation rule for non Flow Keys >>>>>>>> =20 >>>>>>>> =20 >>>>>>> "non Flow Keys" =3D> "non-key fields" >>>>>>> >>>>>>> =20 >>>>>>> =20 >>>>>>>> There are no obvious rules of non Flow Keys. For example,= if an >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> "non Flow Keys" =3D> "non-key fields" >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> IPFIX Mediation receives two Flow Records with different D= SCP >>>>>>>> values, and this DSCP field is not a Flow Key, those two F= low >>>>>>>> Records can be aggregated based on the Flow Keys value. H= owever, >>>>>>>> there is no rules for what the DSCP value should be for th= e >>>>>>>> aggregated Data Record. Potential solutions are: the valu= e of >>>>>>>> =20 >>>>>>>> =20 >>>>>>> Actually, there is a rule! >>>>>>> Unless specified differently, the value of the first packet must = be >>>>>>> included in the record. Hence, as long as timestamps are present = and >>>>>>> allow to determine which one of the Flow Records includes the ear= liest >>>>>>> packet, the decision is evident! >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>> I agree with this rule on Exporter. >>>>>> However, for a Mediator, it's not obvious that we should follow it= =2E >>>>>> Anyway, it should be specified in the mediation framework or proto= col draft. >>>>>> In the mean time, I would like to keep this issue in the problem s= tatement. >>>>>> =20 >>>>>> =20 >>>>> RFC5102: >>>>> >>>>> If they do not serve as Flow Keys, their value may change from p= acket >>>>> to packet within a single Flow. For Information Elements with v= alues >>>>> that are derived from fields of packets or from packet treatment= and >>>>> for which the value may change from packet to packet within a si= ngle >>>>> Flow, the IPFIX information model defines that their value is >>>>> determined *by the first packet* observed for the corresponding = Flow, >>>>> unless the description of the Information Element explicitly >>>>> specifies a different semantics. >>>>> >>>>> So, if a Collector receives a Flow Record with non-key field >>>>> ipDiffServCodePoint, it can assume that this is the DSCP value of t= he >>>>> first packet of all packets in the Flow. >>>>> >>>>> Are you suggesting that RFC5102 is not valid for Mediator? >>>>> =20 >>>>> =20 >>>> No. This rule is still fine. >>>> However, in case of aggregation (this is the title for section 6.8 >>>> Consideration for Aggregation), the question is: what should be >>>> Mediator do? >>>> If the Mediator receives two Flow Records from different Exporters: >>>> one with DSCP=3D1 (non-key field) >>>> one with DCSP=3D2 (non-key field) >>>> What to put in the aggregated Flow Record is the question? And it's >>>> not obvious to me that it should be the one of the Flow Record that >>>> started the first... >>>> That's all I want to say. >>>> =20 >>>>> I'm not sure if this is useful. >>>>> >>>>> If you want to keep this issue in the problem statement draft, the = text >>>>> should be changed. It should be clarified that RFC5102 specifies th= at a >>>>> non-key field value is taken from the first packet. The issue I see= is >>>>> that a Mediator might have problems to determine which one of the >>>>> original Flow Records contains the first packet. For example, the f= low >>>>> start timestamp might be missing or have equal values for multiple >>>>> original Flow Records. If the router clocks are not very well >>>>> synchronized, the timestamps may be biased. >>>>> =20 >>>>> =20 >>>> Two good reasons why the rule you mentioned can't be applied as it i= s, >>>> and why it's a real problem to be described in the problem statement= =2E >>>> >>>> Regards, Benoit. >>>> =20 >>>>> Regards, >>>>> Gerhard >>>>> >>>>> =20 >>>>> =20 >>>>>> Regards, Benoit. >>>>>> >>>>>> =20 >>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> single of the two DSCP, the value 0 (in this case, the val= ue 0 is >>>>>>>> a valid DSCP value), or removing a DSCP field in its Data = Record. >>>>>>>> >>>>>>>> o Configured Selection Fraction on aggregation >>>>>>>> >>>>>>>> There is no obvious rules of how to compute Configured Sel= ection >>>>>>>> Fraction, and whether a Mediator should report Configured >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> remove ", and whether....," >>>>>>> It is obvious, that Configured or Attained Selection Fraction is >>>>>>> necessary to interpret the Flow Records. >>>>>>> >>>>>>> >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> Selection Fraction, when aggregation resulting from Sampli= ng. For >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> "...when aggregating IPFIX Flow Records of sampled packets." >>>>>>> >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> example, special care must be taken in the following: aggr= egation >>>>>>>> resulting from the different Configured Selection Fraction= , >>>>>>>> aggregation resulting from different Sampling techniques, = such as >>>>>>>> Systematic Count-Based Sampling and Random n-out-of-N Samp= ling >>>>>>>> etc. >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> 7. Summary and Conclusion >>>>>>>> >>>>>>>> This document described the problems that network administrat= ors have >>>>>>>> been facing, the applicability of IPFIX Mediation to these pr= oblems, >>>>>>>> and the problems related to the implementation of IPFIX Media= tors. >>>>>>>> To assist the operations of the Exporters and Collectors, the= re are >>>>>>>> various IPFIX Mediations from which the administrators may se= lect. >>>>>>>> Examples of the applicability of IPFIX Mediation are as follo= ws. >>>>>>>> >>>>>>>> o Regarding large-scale measurement system, IPFIX Concentrat= ors or >>>>>>>> IPFIX Distributors help to achieve traffic analysis with h= igh data >>>>>>>> accuracy and fine flow granularity even as IP traffic grow= s. As >>>>>>>> IPFIX Mediation capabilities, Flow selection Sampling, >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> flow sampling? >>>>>>> >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> aggregation, and composition are effective. >>>>>>>> >>>>>>>> o Regarding data retention, IPFIX Mediators enhance the expo= rt >>>>>>>> reliability, and the storage of the measurement system. >>>>>>>> >>>>>>>> o Regarding the distribution of Data Records, IPFIX Distribu= tors >>>>>>>> help to achieve multipurpose traffic analysis for differen= t >>>>>>>> organizations, or help to achieve respective traffic analy= sis >>>>>>>> based on Data Record types(IPv4, IPv6, MPLS, and VPN). >>>>>>>> >>>>>>>> o Regarding IPFIX Exporting across domains, IPFIX Masqueradi= ng >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> exporting >>>>>>> >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> Proxies help administrators to anonymize or filter Flow Re= cords/ >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> Data Records >>>>>>> >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> Packet Reports, preventing privacy violations. >>>>>>>> >>>>>>>> o Regarding interoperability, IPFIX Proxies provide interope= rability >>>>>>>> between legacy protocols and IPFIX, even during the migrat= ion >>>>>>>> period to IPFIX. >>>>>>>> >>>>>>>> As a result, the IPFIX Mediation benefits become apparent. H= owever, >>>>>>>> there are still some open issues with the use of IPFIX Mediat= ors. >>>>>>>> >>>>>>>> o Both Observation Point and IPFIX Message header informatio= n, such >>>>>>>> as the Exporter IP address, Observation Domain ID, and Exp= ort Time >>>>>>>> field, might be lost. This data should therefore be commu= nicated >>>>>>>> between the Original Exporter and Collector via the IPFIX >>>>>>>> Mediator. >>>>>>>> >>>>>>>> o IPFIX Mediators are required to manage Transport Sessions,= >>>>>>>> Template IDs, and Observation Domain IDs. Otherwise, anom= alous >>>>>>>> IPFIX messages could be created. >>>>>>>> >>>>>>>> o Data advertised by Option Templates from the Original Expo= rter, >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> _Options_ Templates >>>>>>> >>>>>>> better: >>>>>>> "Options Data Records exported by the Original Exporter, such as = those >>>>>>> reporting the Sampling rate...." >>>>>>> >>>>>>> Maybe the term "Options Data Record" should be introduced to simp= lify >>>>>>> things. BTW, we had the same problem in per-sctp-stream, and alwa= ys >>>>>>> wrote "Data Record defined by an Options Template Record", which = is not >>>>>>> very easy to read. >>>>>>> >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> such as the Sampling rate and Sampling algorithm used, mig= ht be >>>>>>>> lost. If a Collector is not informed of current Sampling = rates, >>>>>>>> traffic information might become worthless. >>>>>>>> >>>>>>>> These problems stem from the fact that no standards regarding= IPFIX >>>>>>>> Mediation have been set. In particular, the minimum set of >>>>>>>> information that should be communicated between Original Expo= rters >>>>>>>> and Collectors, the management between different IPFIX Transp= ort >>>>>>>> Sessions, and the internal components of IPFIX Mediators shou= ld be >>>>>>>> standardized. >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> 8. Security Considerations >>>>>>>> >>>>>>>> A flow-based measurement system must prevent potential securi= ty >>>>>>>> threats: the disclosure of confidential traffic data, injecti= on of >>>>>>>> incorrect data, and unauthorized access to traffic data. The= se >>>>>>>> security threats of the IPFIX protocol are covered by the sec= urity >>>>>>>> considerations section in [RFC5101] and are still valid for I= PFIX >>>>>>>> Mediators. >>>>>>>> >>>>>>>> And a measurement system must also prevent following security= threats >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> "...the following..." >>>>>>> >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> related to IPFIX Mediation: >>>>>>>> >>>>>>>> o Attacks against IPFIX Mediator >>>>>>>> >>>>>>>> IPFIX Mediators can be considered as a prime target for at= tacks, >>>>>>>> as an alternative to IPFIX Exporters and Collectors. IPFI= X >>>>>>>> Proxies or Masquerading Proxies need to prevent unauthoriz= ed >>>>>>>> access or denial-of-service (DoS) attacks from untrusted p= ublic >>>>>>>> networks. >>>>>>>> >>>>>>>> o Man-in-the-middle attack by untrusted IPFIX Mediator >>>>>>>> >>>>>>>> The Collector-Mediator-Exporter structure model would incr= ease the >>>>>>>> risk of the man-in-the-middle attack. >>>>>>>> >>>>>>>> o Configuration on IPFIX Mediation >>>>>>>> >>>>>>>> In the case of IPFIX Distributors and IPFIX Masquerading P= roxies, >>>>>>>> an accidental misconfiguration and unauthorized access to >>>>>>>> configuration data could lead to the crucial problem of di= sclosure >>>>>>>> of confidential traffic data. >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> =20 >>>>>>> -----------------------------------------------------------------= ------- >>>>>>> >>>>>>> _______________________________________________ >>>>>>> IPFIX mailing list >>>>>>> IPFIX@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>> =20 >>>>> =20 >>>> --------------------------------------------------------------------= ---- >>>> >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>>> =20 >>>> =20 >> >> =20 >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms010705070102010409050905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNzMwMTAzMjAxWjAjBgkqhkiG9w0BCQQxFgQU PUBcod48WKdeydXPtaONgf2oJ2IwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBADOz78Pcjt2GYzWIrgCAiNzAJvfV/s71oovqntkQCrB95vfr IlXBZE8tzdxYL280kjctWocbNX3+4p6uh/WJxy8xO7mbHti05kFvQKoujESTF6HbCI5SiS8s 2xALU+MZMg6Pvd6A7jPD7kp3zwUgoj8v2w62I94xAKqbqMPV1+keKcEkov8axYUtexORUlsd s8ZRq1Grz9Igg9I1Xla2hNLFvNB6x5H7i8nWQDQeW3FB5bzCPdTFTJFunZIJOr/s2Hnsb/w4 6FLuZ3fc+RsiiRoBLx8CXFro+0QhqfR6kS8M+uVQBoY/OlCt7rMCPr/JV8qVO3RKqvaspY9t NUYnPb8AAAAAAAA= --------------ms010705070102010409050905-- From Quittek@nw.neclab.eu Thu Jul 30 05:41:23 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7693A682C for ; Thu, 30 Jul 2009 05:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8lxtu54zOLu for ; Thu, 30 Jul 2009 05:41:22 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0A19F28C286 for ; Thu, 30 Jul 2009 05:41:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 8431B2C0012C6 for ; Thu, 30 Jul 2009 14:41:23 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlmiAgei1Lob for ; Thu, 30 Jul 2009 14:41:23 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 4DCC72C0012C4 for ; Thu, 30 Jul 2009 14:41:18 +0200 (CEST) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jul 2009 12:41:18 +0000 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Type: multipart/signed; boundary="B_3331809615_10255280"; protocol="application/pkcs7-signature"; micalg=sha1 Content-class: urn:content-classes:message Date: Thu, 30 Jul 2009 14:40:15 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: new work items for the IPFIX charter Thread-Index: AcoREuMPI1q++yG27keilphWGxsLQw== From: "Juergen Quittek" To: "IETF IPFIX Working Group" Subject: [IPFIX] new work items for the IPFIX charter X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 12:41:23 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3331809615_10255280 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, At our session on Monday there were three drafts presented for which there was a consensus to accept them as working group documents. Now we need confirmation on this list. The drafts are - Export of Structured Data in IPFIX http://tools.ietf.org/html/draft-claise-structured-data-in-ipfix - IP Flow Anonymisation Support http://tools.ietf.org/html/draft-boschi-ipfix-anon - Flow Selection Techniques http://tools.ietf.org/html/draft-peluso-flowselection-tech If you see any problem with adding these three items to the IPFIX agenda, please make your point on this list within the next two weeks. Thanks, Juergen --B_3331809615_10255280 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSa5Gn9jgj36+Cfnihl x21BdEtTiDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA3 MzAxMjQwMTVaMA0GCSqGSIb3DQEBAQUABIIBAHpDOalj5M/5WSc4vvy0SD+ykL5HBhMQTIZ+ szG6iBfAApjUbv+CuWZtVCdRdqKIeFJHKAhN4krlH7745+OpTa081hAQBWbYTeFzh5q09sqy V9rnI+4vDgvjgXe3mApKMXgl+8gvRSf99XdkQI0XNpZ4xAjW1q/hG/MMpXZH/tzjp7l1cKHK wIHMyamomNMTNWEwXQ3YzhFEKcaNDg8Asd2ElpbAvQi/QGpl6CbxkrTmzEguVc2zNYReRzK+ cQ53cKYaEn3JJdlsEApIXJGGGlBqkt0GSqYIYgPGmsIr7DelufoPKP9d1MgNRmM+6pDNhSco upW1jh0rQHq52RmDCZw= --B_3331809615_10255280-- From bclaise@cisco.com Thu Jul 30 05:43:10 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B07F28C293 for ; Thu, 30 Jul 2009 05:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz-4OF+HoBSX for ; Thu, 30 Jul 2009 05:43:07 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 37D8328C286 for ; Thu, 30 Jul 2009 05:43:07 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6UCh69W021216; Thu, 30 Jul 2009 14:43:07 +0200 (CEST) Received: from [10.61.94.150] (ams3-vpn-dhcp7831.cisco.com [10.61.94.150]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6UCh6SA016827; Thu, 30 Jul 2009 14:43:06 +0200 (CEST) Message-ID: <4A71955A.4000606@cisco.com> Date: Thu, 30 Jul 2009 14:43:06 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gerhard Muenz References: <4A1BE50E.6040407@net.in.tum.de> <4A6EB8AE.5000204@cisco.com> <4A6EC345.9060109@net.in.tum.de> <4A6EC4F4.8080005@cisco.com> <4A70DEFC.6090109@cisco.com> <4A715635.4010308@net.in.tum.de> <4A716BBB.9020100@cisco.com> <4A7176A1.7020400@net.in.tum.de> In-Reply-To: <4A7176A1.7020400@net.in.tum.de> Content-Type: multipart/alternative; boundary="------------060006040801070106040403" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 12:43:10 -0000 This is a multi-part message in MIME format. --------------060006040801070106040403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, > Benoit, > > I do not like "assigning a non valid value for the Information Element > to express to the Collector that this Information Element is > meaningless" - this should only be considered as a work-around for > devices which are not able to handle Templates appropriately. > But if you want to keep this option, leave it in. > I don't like this solution, and I don't propose it. However, the problem statement document is present: 1. to state the problem 2. to justify why we need to work on a framework/protocol... which will have to chose the right solution Regards, Benoit. > Gerhard > > Benoit Claise wrote: > >> Gerhard, >> >> Thanks. Kobayashi-san and I came with the following proposal, strongly >> based on your proposal. >> >> Whether the aggregation is based on time or spatial composition, caution >> should be taken on how to aggregate non-key fields in IPFIX Mediation. >> The IPFIX information model [RFC5102] specifies that the value of >> non-key fields, which are derived from fields of packets or from packet >> treatment and for which the value may change from packet to packet >> within a single Flow, is determined by the first packet observed for the >> corresponding Flow, unless the description of the Information Element >> explicitly specifies a different semantics. >> >> However, this simple rule might not be appropriate when aggregating Flow >> Records which have different values in a non-key field. For >> example, if two Flows with identical Flow Key values are measured at >> different Observation Points, they may contain identical packets >> observed at different locations in the network and at different points >> in time. On their way from the first to the second Observation Point, >> some of the packet fields, such as the DSCP, may have changed. Hence, if >> the Information Element ipDiffServCodePoint is included as a non-key >> field, it can be useful to include the DSCP value observed at either the >> first or the second Observation Point in the resulting Flow Record, >> depending on the application. >> >> Other potential solutions include: removing the Information Element >> ipDiffServCodePoint from the Data Record >> when re-exporting the aggregate Flow Record, changing the Information >> Element ipDiffServCodePoint from a non key-field to a Flow Key when >> re-exporting the aggregated Flow Record, or assigning a non valid value >> for the Information Element to express to the Collector that this >> Information Element is meaningless. >> >> Fine? >> >> Regards, Benoit. >> >> >>> Benoit Claise wrote: >>> >>> >>>> Gerhard, >>>> >>>> I proposed this text. >>>> >>>> 6.8. Consideration for Aggregation >>>> >>>> Whether the aggregation is based on time or spatial composition, caution >>>> should be taken on how to aggregate non Flow Keys in a IPFIX Mediation. >>>> >>>> >>> non Flow Keys => non-key fields >>> I was told to do so in ipfix configuration (by Paul, I think). >>> >>> either >>> in a IPFIX Mediation => in IPFIX Mediation >>> or >>> in a IPFIX Mediation => in an IPFIX Mediator >>> >>> >>> >>>> The IPFIX Information Model [RFC5102] is very clear about the content of >>>> >>>> >>> not sure if "information model" should be capitalized >>> >>> >>> >>>> a non Flow Key Information Element on the Original Exporter: its value >>>> is determined *by the first packet* observed for the corresponding Flow, >>>> unless the description of the Information Element explicitly specifies a >>>> different semantics. >>>> >>>> >>> RFC5102 does not talk about Original Exporter yet. >>> >>> What about: >>> "The IPFIX information model [RFC5102] specifies that the value of >>> non-key fields, which are derived from fields of packets or from packet >>> treatment and for which the value may change from packet to packet >>> within a single Flow, is determined by the first packet observed for the >>> corresponding Flow, unless the description of the Information Element >>> explicitly specifies a different semantics." >>> >>> >>> >>>> However, this rule might not apply in a Mediation Function. For example, >>>> if an IPFIX Mediator receives two Flow Records with identical Flow Keys >>>> values but with different DSCP values (the DSCP being a non Flow Key), >>>> what should be the DSCP value of the aggregated Flow Record? Potential >>>> solutions are: assign the value of the first received Flow Record within >>>> the aggregation time, assign a special value such as 0 (However, in this >>>> case, the value 0 is a valid DSCP value), remove the DSCP Information >>>> Element from the Data Record, change the DSCP Information Element from a >>>> non Flow Key to a Flow Key when re-exporting the aggregated Flow Record, >>>> etc... >>>> >>>> >>> What about: >>> "However, this simple rule might not be appropriate when aggregating >>> Flow Records which have different values in a non-key field. For >>> example, if two Flows with identical Flow Key values are measured at >>> different Observation Points, they may contain identical packets >>> observed at different locations in the network and at different points >>> in time. On their way from the first to the second Observation Point, >>> some of the packet fields, such as the DSCP, may have changed. Hence, if >>> the Information Element ipDiffServCodePoint is included as a non-key >>> field, it can be useful to include the DSCP value observed at either the >>> first or the second Observation Point in the resulting Flow Record, >>> depending on the application." >>> >>> I'm sure that there are more examples. This is just one where it seems >>> to be obvious to me that just looking at "the first packet" with respect >>> to time does not make sense. >>> >>> Regards, >>> Gerhard >>> >>> >>> >>> >>>> Furthermore, rules must be specify on how to aggregate the new >>>> Configured Selection Fraction an IPFIX Mediator should report when >>>> aggregating IPFIX Flow Records with different sampling rates. Finally, >>>> special care must be taken when aggregating Flow Records resulting from >>>> different Sampling techniques such as Systematic Count-Based Sampling >>>> and Random n-out-of-N Sampling for example. >>>> >>>> >>>> Feedback? >>>> >>>> Regards, Benoit. >>>> >>>> >>>> >>>>> Gerhard, >>>>> >>>>> >>>>>> Benoit, >>>>>> >>>>>> Benoit Claise wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Gerhard, >>>>>>> >>>>>>> Thinking some more, I would like to come back to that point below. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> 6.8. Consideration for Aggregation >>>>>>>>> >>>>>>>>> In case of Flow Key aggregation, Time Composition, and Spatial >>>>>>>>> Composition, there are the following considerations: >>>>>>>>> >>>>>>>>> o Aggregation rule for non Flow Keys >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> "non Flow Keys" => "non-key fields" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> There are no obvious rules of non Flow Keys. For example, if an >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> "non Flow Keys" => "non-key fields" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> IPFIX Mediation receives two Flow Records with different DSCP >>>>>>>>> values, and this DSCP field is not a Flow Key, those two Flow >>>>>>>>> Records can be aggregated based on the Flow Keys value. However, >>>>>>>>> there is no rules for what the DSCP value should be for the >>>>>>>>> aggregated Data Record. Potential solutions are: the value of >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Actually, there is a rule! >>>>>>>> Unless specified differently, the value of the first packet must be >>>>>>>> included in the record. Hence, as long as timestamps are present and >>>>>>>> allow to determine which one of the Flow Records includes the earliest >>>>>>>> packet, the decision is evident! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I agree with this rule on Exporter. >>>>>>> However, for a Mediator, it's not obvious that we should follow it. >>>>>>> Anyway, it should be specified in the mediation framework or protocol draft. >>>>>>> In the mean time, I would like to keep this issue in the problem statement. >>>>>>> >>>>>>> >>>>>>> >>>>>> RFC5102: >>>>>> >>>>>> If they do not serve as Flow Keys, their value may change from packet >>>>>> to packet within a single Flow. For Information Elements with values >>>>>> that are derived from fields of packets or from packet treatment and >>>>>> for which the value may change from packet to packet within a single >>>>>> Flow, the IPFIX information model defines that their value is >>>>>> determined *by the first packet* observed for the corresponding Flow, >>>>>> unless the description of the Information Element explicitly >>>>>> specifies a different semantics. >>>>>> >>>>>> So, if a Collector receives a Flow Record with non-key field >>>>>> ipDiffServCodePoint, it can assume that this is the DSCP value of the >>>>>> first packet of all packets in the Flow. >>>>>> >>>>>> Are you suggesting that RFC5102 is not valid for Mediator? >>>>>> >>>>>> >>>>>> >>>>> No. This rule is still fine. >>>>> However, in case of aggregation (this is the title for section 6.8 >>>>> Consideration for Aggregation), the question is: what should be >>>>> Mediator do? >>>>> If the Mediator receives two Flow Records from different Exporters: >>>>> one with DSCP=1 (non-key field) >>>>> one with DCSP=2 (non-key field) >>>>> What to put in the aggregated Flow Record is the question? And it's >>>>> not obvious to me that it should be the one of the Flow Record that >>>>> started the first... >>>>> That's all I want to say. >>>>> >>>>> >>>>>> I'm not sure if this is useful. >>>>>> >>>>>> If you want to keep this issue in the problem statement draft, the text >>>>>> should be changed. It should be clarified that RFC5102 specifies that a >>>>>> non-key field value is taken from the first packet. The issue I see is >>>>>> that a Mediator might have problems to determine which one of the >>>>>> original Flow Records contains the first packet. For example, the flow >>>>>> start timestamp might be missing or have equal values for multiple >>>>>> original Flow Records. If the router clocks are not very well >>>>>> synchronized, the timestamps may be biased. >>>>>> >>>>>> >>>>>> >>>>> Two good reasons why the rule you mentioned can't be applied as it is, >>>>> and why it's a real problem to be described in the problem statement. >>>>> >>>>> Regards, Benoit. >>>>> >>>>> >>>>>> Regards, >>>>>> Gerhard >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Regards, Benoit. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> single of the two DSCP, the value 0 (in this case, the value 0 is >>>>>>>>> a valid DSCP value), or removing a DSCP field in its Data Record. >>>>>>>>> >>>>>>>>> o Configured Selection Fraction on aggregation >>>>>>>>> >>>>>>>>> There is no obvious rules of how to compute Configured Selection >>>>>>>>> Fraction, and whether a Mediator should report Configured >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> remove ", and whether....," >>>>>>>> It is obvious, that Configured or Attained Selection Fraction is >>>>>>>> necessary to interpret the Flow Records. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Selection Fraction, when aggregation resulting from Sampling. For >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> "...when aggregating IPFIX Flow Records of sampled packets." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> example, special care must be taken in the following: aggregation >>>>>>>>> resulting from the different Configured Selection Fraction, >>>>>>>>> aggregation resulting from different Sampling techniques, such as >>>>>>>>> Systematic Count-Based Sampling and Random n-out-of-N Sampling >>>>>>>>> etc. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 7. Summary and Conclusion >>>>>>>>> >>>>>>>>> This document described the problems that network administrators have >>>>>>>>> been facing, the applicability of IPFIX Mediation to these problems, >>>>>>>>> and the problems related to the implementation of IPFIX Mediators. >>>>>>>>> To assist the operations of the Exporters and Collectors, there are >>>>>>>>> various IPFIX Mediations from which the administrators may select. >>>>>>>>> Examples of the applicability of IPFIX Mediation are as follows. >>>>>>>>> >>>>>>>>> o Regarding large-scale measurement system, IPFIX Concentrators or >>>>>>>>> IPFIX Distributors help to achieve traffic analysis with high data >>>>>>>>> accuracy and fine flow granularity even as IP traffic grows. As >>>>>>>>> IPFIX Mediation capabilities, Flow selection Sampling, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> flow sampling? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> aggregation, and composition are effective. >>>>>>>>> >>>>>>>>> o Regarding data retention, IPFIX Mediators enhance the export >>>>>>>>> reliability, and the storage of the measurement system. >>>>>>>>> >>>>>>>>> o Regarding the distribution of Data Records, IPFIX Distributors >>>>>>>>> help to achieve multipurpose traffic analysis for different >>>>>>>>> organizations, or help to achieve respective traffic analysis >>>>>>>>> based on Data Record types(IPv4, IPv6, MPLS, and VPN). >>>>>>>>> >>>>>>>>> o Regarding IPFIX Exporting across domains, IPFIX Masquerading >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> exporting >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Proxies help administrators to anonymize or filter Flow Records/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Data Records >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Packet Reports, preventing privacy violations. >>>>>>>>> >>>>>>>>> o Regarding interoperability, IPFIX Proxies provide interoperability >>>>>>>>> between legacy protocols and IPFIX, even during the migration >>>>>>>>> period to IPFIX. >>>>>>>>> >>>>>>>>> As a result, the IPFIX Mediation benefits become apparent. However, >>>>>>>>> there are still some open issues with the use of IPFIX Mediators. >>>>>>>>> >>>>>>>>> o Both Observation Point and IPFIX Message 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 IPFIX Mediators are required to manage Transport Sessions, >>>>>>>>> Template IDs, and Observation Domain IDs. Otherwise, anomalous >>>>>>>>> IPFIX messages could be created. >>>>>>>>> >>>>>>>>> o Data advertised by Option Templates from the Original Exporter, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _Options_ Templates >>>>>>>> >>>>>>>> better: >>>>>>>> "Options Data Records exported by the Original Exporter, such as those >>>>>>>> reporting the Sampling rate...." >>>>>>>> >>>>>>>> Maybe the term "Options Data Record" should be introduced to simplify >>>>>>>> things. BTW, we had the same problem in per-sctp-stream, and always >>>>>>>> wrote "Data Record defined by an Options Template Record", which is not >>>>>>>> very easy to read. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> such as the Sampling rate and Sampling algorithm used, might be >>>>>>>>> lost. If a Collector is not informed of current Sampling rates, >>>>>>>>> traffic information might become worthless. >>>>>>>>> >>>>>>>>> These problems stem from the fact that no standards regarding IPFIX >>>>>>>>> Mediation have been set. In particular, the minimum set of >>>>>>>>> information that should be communicated between Original Exporters >>>>>>>>> and Collectors, the management between different IPFIX Transport >>>>>>>>> Sessions, and the internal components of IPFIX Mediators should be >>>>>>>>> standardized. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 8. Security Considerations >>>>>>>>> >>>>>>>>> A flow-based measurement system must prevent potential security >>>>>>>>> threats: the disclosure of confidential traffic data, injection of >>>>>>>>> incorrect data, and unauthorized access to traffic data. These >>>>>>>>> security threats of the IPFIX protocol are covered by the security >>>>>>>>> considerations section in [RFC5101] and are still valid for IPFIX >>>>>>>>> Mediators. >>>>>>>>> >>>>>>>>> And a measurement system must also prevent following security threats >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> "...the following..." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> related to IPFIX Mediation: >>>>>>>>> >>>>>>>>> o Attacks against IPFIX Mediator >>>>>>>>> >>>>>>>>> IPFIX Mediators can be considered as a prime target for attacks, >>>>>>>>> as an alternative to IPFIX Exporters and Collectors. IPFIX >>>>>>>>> Proxies or Masquerading Proxies need to prevent unauthorized >>>>>>>>> access or denial-of-service (DoS) attacks from untrusted public >>>>>>>>> networks. >>>>>>>>> >>>>>>>>> o Man-in-the-middle attack by untrusted IPFIX Mediator >>>>>>>>> >>>>>>>>> The Collector-Mediator-Exporter structure model would increase the >>>>>>>>> risk of the man-in-the-middle attack. >>>>>>>>> >>>>>>>>> o Configuration on IPFIX Mediation >>>>>>>>> >>>>>>>>> In the case of IPFIX Distributors and IPFIX Masquerading Proxies, >>>>>>>>> an accidental misconfiguration and unauthorized access to >>>>>>>>> configuration data could lead to the crucial problem of disclosure >>>>>>>>> of confidential traffic data. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> IPFIX mailing list >>>>>>>> IPFIX@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>> >>>>> >>>>> >>> >>> > > --------------060006040801070106040403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard, 
Benoit,

I do not like "assigning a non valid value for the Information Element
to express to the Collector that this Information Element is
meaningless" - this should only be considered as a work-around for
devices which are not able to handle Templates appropriately.
But if you want to keep this option, leave it in.
I don't like this solution, and I don't propose it.
However, the problem statement document is present:
    1. to state the problem
    2. to justify why we need to work on a framework/protocol...
        which will have to chose the right solution

Regards, Benoit.
Gerhard

Benoit Claise wrote:
  
Gerhard,

Thanks. Kobayashi-san and I came with the following proposal, strongly
based on your proposal.

Whether the aggregation is based on time or spatial composition, caution
should be taken on how to aggregate non-key fields in IPFIX Mediation.
The IPFIX information model [RFC5102] specifies that the value of
non-key fields, which are derived from fields of packets or from packet
treatment and for which the value may change from packet to packet
within a single Flow, is determined by the first packet observed for the
corresponding Flow, unless the description of the Information Element
explicitly specifies a different semantics.

However, this simple rule might not be appropriate when aggregating Flow
Records which have different values in a non-key field. For
example, if two Flows with identical Flow Key values are measured at
different Observation Points, they may contain identical packets
observed at different locations in the network and at different points
in time. On their way from the first to the second Observation Point,
some of the packet fields, such as the DSCP, may have changed. Hence, if
the Information Element ipDiffServCodePoint is included as a non-key
field, it can be useful to include the DSCP value observed at either the
first or the second Observation Point in the resulting Flow Record,
depending on the application.

Other potential solutions include: removing the Information Element
ipDiffServCodePoint from the Data Record
when re-exporting the aggregate Flow Record, changing the Information
Element ipDiffServCodePoint from a non key-field to a Flow Key when
re-exporting the aggregated Flow Record, or assigning a non valid value
for the Information Element to express to the Collector that this
Information Element is meaningless.

Fine?

Regards, Benoit.

    
Benoit Claise wrote:
  
      
Gerhard,

I proposed this text.

6.8.  Consideration for Aggregation

Whether the aggregation is based on time or spatial composition, caution
should be taken on how to aggregate non Flow Keys in a IPFIX Mediation.
    
        
non Flow Keys => non-key fields
I was told to do so in ipfix configuration (by Paul, I think).

either
in a IPFIX Mediation => in IPFIX Mediation
or
in a IPFIX Mediation => in an IPFIX Mediator

  
      
The IPFIX Information Model [RFC5102] is very clear about the content of
    
        
not sure if "information model" should be capitalized

  
      
a non Flow Key Information Element on the Original Exporter: its value
is determined *by the first packet* observed for the corresponding Flow,
unless the description of the Information Element explicitly specifies a
different semantics.
    
        
RFC5102 does not talk about Original Exporter yet.

What about:
"The IPFIX information model [RFC5102] specifies that the value of
non-key fields, which are derived from fields of packets or from packet
treatment and for which the value may change from packet to packet
within a single Flow, is determined by the first packet observed for the
corresponding Flow, unless the description of the Information Element
explicitly specifies a different semantics."

  
      
However, this rule might not apply in a Mediation Function. For example,
if an IPFIX Mediator receives two Flow Records with identical Flow Keys
values but with different DSCP values (the DSCP being a non Flow Key),
what should be the DSCP value of the aggregated Flow Record? Potential
solutions are: assign the value of the first received Flow Record within
the aggregation time, assign a special value such as 0 (However, in this
case, the value 0 is a valid DSCP value), remove the DSCP Information
Element from the Data Record, change the DSCP Information Element from a
non Flow Key to a Flow Key when re-exporting the aggregated Flow Record,
etc...
    
        
What about:
"However, this simple rule might not be appropriate when aggregating
Flow Records which have different values in a non-key field. For
example, if two Flows with identical Flow Key values are measured at
different Observation Points, they may contain identical packets
observed at different locations in the network and at different points
in time. On their way from the first to the second Observation Point,
some of the packet fields, such as the DSCP, may have changed. Hence, if
the Information Element ipDiffServCodePoint is included as a non-key
field, it can be useful to include the DSCP value observed at either the
first or the second Observation Point in the resulting Flow Record,
depending on the application."

I'm sure that there are more examples. This is just one where it seems
to be obvious to me that just looking at "the first packet" with respect
to time does not make sense.

Regards,
Gerhard


  
      
Furthermore, rules must be specify on how to aggregate the new
Configured Selection Fraction an IPFIX Mediator should report when
aggregating IPFIX Flow Records with different sampling rates. Finally,
special care must be taken when aggregating Flow Records resulting from
different Sampling techniques such as Systematic Count-Based Sampling
and Random n-out-of-N Sampling for example.


Feedback?

Regards, Benoit.

    
        
Gerhard,
      
          
Benoit,

Benoit Claise wrote:
  
        
            
Gerhard,

Thinking some more, I would like to come back to that point below.

    
          
              
6.8.  Consideration for Aggregation

   In case of Flow Key aggregation, Time Composition, and Spatial
   Composition, there are the following considerations:

   o  Aggregation rule for non Flow Keys
        
              
                  
"non Flow Keys" => "non-key fields"

      
            
                
      There are no obvious rules of non Flow Keys.  For example, if an
    
        
              
                  
"non Flow Keys" => "non-key fields"
  
      
            
                
      IPFIX Mediation receives two Flow Records with different DSCP
      values, and this DSCP field is not a Flow Key, those two Flow
      Records can be aggregated based on the Flow Keys value.  However,
      there is no rules for what the DSCP value should be for the
      aggregated Data Record.  Potential solutions are: the value of
        
              
                  
Actually, there is a rule!
Unless specified differently, the value of the first packet must be
included in the record. Hence, as long as timestamps are present and
allow to determine which one of the Flow Records includes the earliest
packet, the decision is evident!
  
      
            
                
I agree with this rule on Exporter.
However, for a Mediator, it's not obvious that we should follow it.
Anyway, it should be specified in the mediation framework or protocol draft.
In the mean time, I would like to keep this issue in the problem statement.
    
          
              
RFC5102:

   If they do not serve as Flow Keys, their value may change from packet
   to packet within a single Flow.  For Information Elements with values
   that are derived from fields of packets or from packet treatment and
   for which the value may change from packet to packet within a single
   Flow, the IPFIX information model defines that their value is
   determined *by the first packet* observed for the corresponding Flow,
   unless the description of the Information Element explicitly
   specifies a different semantics.

So, if a Collector receives a Flow Record with non-key field
ipDiffServCodePoint, it can assume that this is the DSCP value of the
first packet of all packets in the Flow.

Are you suggesting that RFC5102 is not valid for Mediator?
  
        
            
No. This rule is still fine.
However, in case of aggregation (this is the title for section 6.8
Consideration for Aggregation), the question is: what should be
Mediator do?
If the Mediator receives two Flow Records from different Exporters:
    one with DSCP=1 (non-key field)
    one with DCSP=2 (non-key field)
What to put in the aggregated Flow Record is the question? And it's
not obvious to me that it should be the one of the Flow Record that
started the first...
That's all I want to say.
      
          
I'm not sure if this is useful.

If you want to keep this issue in the problem statement draft, the text
should be changed. It should be clarified that RFC5102 specifies that a
non-key field value is taken from the first packet. The issue I see is
that a Mediator might have problems to determine which one of the
original Flow Records contains the first packet. For example, the flow
start timestamp might be missing or have equal values for multiple
original Flow Records. If the router clocks are not very well
synchronized, the timestamps may be biased.
  
        
            
Two good reasons why the rule you mentioned can't be applied as it is,
and why it's a real problem to be described in the problem statement.

Regards, Benoit.
      
          
Regards,
Gerhard

  
        
            
Regards, Benoit.

    
          
              
  
      
            
                
      single of the two DSCP, the value 0 (in this case, the value 0 is
      a valid DSCP value), or removing a DSCP field in its Data Record.

   o  Configured Selection Fraction on aggregation

      There is no obvious rules of how to compute Configured Selection
      Fraction, and whether a Mediator should report Configured
    
        
              
                  
remove ", and whether....,"
It is obvious, that Configured or Attained Selection Fraction is
necessary to interpret the Flow Records.


  
      
            
                
      Selection Fraction, when aggregation resulting from Sampling.  For
    
        
              
                  
"...when aggregating IPFIX Flow Records of sampled packets."

  
      
            
                
      example, special care must be taken in the following: aggregation
      resulting from the different Configured Selection Fraction,
      aggregation resulting from different Sampling techniques, such as
      Systematic Count-Based Sampling and Random n-out-of-N Sampling
      etc.
    
        
              
                  
  
      
            
                
7.  Summary and Conclusion

   This document described the problems that network administrators have
   been facing, the applicability of IPFIX Mediation to these problems,
   and the problems related to the implementation of IPFIX Mediators.
   To assist the operations of the Exporters and Collectors, there are
   various IPFIX Mediations from which the administrators may select.
   Examples of the applicability of IPFIX Mediation are as follows.

   o  Regarding large-scale measurement system, IPFIX Concentrators or
      IPFIX Distributors help to achieve traffic analysis with high data
      accuracy and fine flow granularity even as IP traffic grows.  As
      IPFIX Mediation capabilities, Flow selection Sampling,
    
        
              
                  
flow sampling?

  
      
            
                
      aggregation, and composition are effective.

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

   o  Regarding the distribution of Data Records, IPFIX Distributors
      help to achieve multipurpose traffic analysis for different
      organizations, or help to achieve respective traffic analysis
      based on Data Record types(IPv4, IPv6, MPLS, and VPN).

   o  Regarding IPFIX Exporting across domains, IPFIX Masquerading
    
        
              
                  
exporting

  
      
            
                
      Proxies help administrators to anonymize or filter Flow Records/
    
        
              
                  
Data Records

  
      
            
                
      Packet Reports, preventing privacy violations.

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

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

   o  Both Observation Point and IPFIX Message 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  IPFIX Mediators are required to manage Transport Sessions,
      Template IDs, and Observation Domain IDs.  Otherwise, anomalous
      IPFIX messages could be created.

   o  Data advertised by Option Templates from the Original Exporter,
    
        
              
                  
_Options_ Templates

better:
"Options Data Records exported by the Original Exporter, such as those
reporting the Sampling rate...."

Maybe the term "Options Data Record" should be introduced to simplify
things. BTW, we had the same problem in per-sctp-stream, and always
wrote "Data Record defined by an Options Template Record", which is not
very easy to read.

  
      
            
                
      such as the Sampling rate and Sampling algorithm used, might be
      lost.  If a Collector is not informed of current Sampling rates,
      traffic information might become worthless.

   These problems stem from the fact that no standards regarding IPFIX
   Mediation have been set.  In particular, the minimum set of
   information that should be communicated between Original Exporters
   and Collectors, the management between different IPFIX Transport
   Sessions, and the internal components of IPFIX Mediators should be
   standardized.
    
        
              
                  
  
      
            
                
8.  Security Considerations

   A flow-based measurement system must prevent potential security
   threats: the disclosure of confidential traffic data, injection of
   incorrect data, and unauthorized access to traffic data.  These
   security threats of the IPFIX protocol are covered by the security
   considerations section in [RFC5101] and are still valid for IPFIX
   Mediators.

   And a measurement system must also prevent following security threats
    
        
              
                  
"...the following..."

  
      
            
                
   related to IPFIX Mediation:

   o  Attacks against IPFIX Mediator

      IPFIX Mediators can be considered as a prime target for attacks,
      as an alternative to IPFIX Exporters and Collectors.  IPFIX
      Proxies or Masquerading Proxies need to prevent unauthorized
      access or denial-of-service (DoS) attacks from untrusted public
      networks.

   o  Man-in-the-middle attack by untrusted IPFIX Mediator

      The Collector-Mediator-Exporter structure model would increase the
      risk of the man-in-the-middle attack.

   o  Configuration on IPFIX Mediation

      In the case of IPFIX Distributors and IPFIX Masquerading Proxies,
      an accidental misconfiguration and unauthorized access to
      configuration data could lead to the crucial problem of disclosure
      of confidential traffic data.
    
        
              
                  
  
------------------------------------------------------------------------

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
  
      
            
                
  
        
            
------------------------------------------------------------------------

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------060006040801070106040403-- From cfinss@dial.pipex.com Thu Jul 30 07:33:28 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5BE13A700A; Thu, 30 Jul 2009 07:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2ZKdsSUx7Cp; Thu, 30 Jul 2009 07:33:26 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 1489F3A6C50; Thu, 30 Jul 2009 07:33:25 -0700 (PDT) X-Trace: 237566643/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.16/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.16 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEGAPtLcUo+vGkQ/2dsb2JhbABEgmk8jFjCdQIHgi6BWgU X-IronPort-AV: E=Sophos;i="4.43,295,1246834800"; d="scan'208";a="237566643" X-IP-Direction: IN Received: from 1cust16.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.16]) by smtp.pipex.tiscali.co.uk with SMTP; 30 Jul 2009 15:33:23 +0100 Message-ID: <000401ca111a$3bb01da0$0601a8c0@allison> From: "tom.petch" To: "Gerhard Muenz" , , , References: <4A6EB9BB.9040002@net.in.tum.de> Date: Thu, 30 Jul 2009 11:44:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailman-Approved-At: Thu, 30 Jul 2009 07:38:19 -0700 Cc: Michael Tuexen , Robin Seggelmann , Daniel Mentz Subject: Re: [IPFIX] [Syslog] Missing dead peer detection in DTLS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 14:33:28 -0000 Gerhard Thank you for pointing this out; it had escaped me. What I had thought though was that the lack of flow control with DTLS over UDP is a problem, and that the lack of this with syslog over UDP led the syslog RFC [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as might be expected, syslog over UDP. This in turn led me to expect that syslog over DTLS over UDP would not be acceptable to the IESG, rather that syslog over DTLS over SCTP would become the RECOMMENDED transport. So; several thoughts. This is an update to the extensions RFC, RFC4366, which itself is being updated by the TLS working group (hence my addition of them to the list) and I would much rather have one extensions RFC rather than several. This is a good concept and fills a need; perhaps the TLS working group would take this on. Flow control remains an issue which I do not think that this extension addresses. Is this a security exposure? or just, like syslog over UDP, an inconvenient truth? The petch-gerhards draft allows the recipient of the unidirectional flow to initiate the DTLS 'connection', and so enables it to re-establish the connection when anything goes wrong. This would seem an alternative to consider. Tom Petch ----- Original Message ----- From: "Gerhard Muenz" To: ; Cc: "Michael Tuexen" ; "Robin Seggelmann" ; "Daniel Mentz" Sent: Tuesday, July 28, 2009 10:41 AM Subject: [Syslog] Missing dead peer detection in DTLS Hi, This mail goes to the ipfix and syslog mailing lists in order to summarize the common issues regarding DTLS. IPFIX specifies support of DTLS as mandatory for transport over UDP and SCTP in RFC5101. In SYSLOG, it is intended to standardize DTLS for transport over UDP. In IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, and we will have a first implementation of IPFIX-over-DTLS/SCTP very soon. During this implementation effort, we found that the current specification of DTLS/UDP has a severe flaw when used with unidirectional protocols (like IPFIX): The sender cannot recognize if the receiver has crashed and lost the DTLS state. We discuss this issue in a draft: http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00 http://www.ietf.org/proceedings/75/slides/ipfix-6.pdf I've had a look at draft-feng-syslog-transport-dtls-01 and draft-petch-gerhards-syslog-transport-dtls-02. It seems that this problem has not yet been covered, although the problem should be the same for SYSLOG. As a solution, the DTLS Heartbeat Extension has been proposed very recently: http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00 A feature patch for OpenSSL is available: http://sctp.fh-muenster.de/dtls-patches.html#features So, I think that we should support this standardization initiative as it solves our problem. For IPFIX and SYSLOG over DTLS/UDP, we then can specify that the DTLS Heartbeat Extension MUST be implemented. Dan suggested to have a single document solving the DTLS issues regarding unidirectional protocols. I think that such a document is not needed if we have DTLS Heartbeat Extension. Regards, Gerhard Dipl.-Ing. Gerhard Münz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universität München Boltzmannstr. 3, 85748 Garching bei München, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz From tuexen@fh-muenster.de Thu Jul 30 08:24:39 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A2F28C2BD; Thu, 30 Jul 2009 08:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvsLWZHE1sxn; Thu, 30 Jul 2009 08:24:38 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 5ED5D3A6B22; Thu, 30 Jul 2009 08:24:23 -0700 (PDT) Received: from [IPv6:2001:df8::16:224:36ff:feef:67d1] (unknown [IPv6:2001:df8:0:16:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id 4B7141C0B4629; Thu, 30 Jul 2009 17:24:21 +0200 (CEST) From: Michael Tuexen To: "tom.petch" In-Reply-To: <000401ca111a$3bb01da0$0601a8c0@allison> X-Priority: 3 References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 17:24:20 +0200 X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Thu, 30 Jul 2009 14:25:00 -0700 Cc: Robin Seggelmann , ipfix@ietf.org, Daniel Mentz , syslog@ietf.org, tls@ietf.org Subject: Re: [IPFIX] [Syslog] Missing dead peer detection in DTLS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 15:24:39 -0000 Hi Tom, a question in-line. Best regards Michael On Jul 30, 2009, at 11:44 AM, tom.petch wrote: > Gerhard > > Thank you for pointing this out; it had escaped me. > > What I had thought though was that the lack of flow control with =20 > DTLS over UDP > is a problem, and that the lack of this with syslog over UDP led the =20= > syslog RFC > [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as =20= > might be > expected, syslog over UDP. So I think it is actually congestion control what you are looking for, which is provided by TCP when using SYSLOG/TLS/TCP/IP, right? > > This in turn led me to expect that syslog over DTLS over UDP would =20 > not be > acceptable to the IESG, rather that syslog over DTLS over SCTP would =20= > become the > RECOMMENDED transport. This would mean, that * SYSLOG/TLS/TCP/IP * SYSLOG/DTLS/SCTP/IP * SYSLOG/DTLS/DCCP/IP are in principle acceptable, whereas * SYSLOG/DTLS/UDP/IP is not. You would (from the congestion control perspective) have the same classification when taking out the DTLS or TLS layer, right? > > So; several thoughts. > > This is an update to the extensions RFC, RFC4366, which itself is =20 > being updated > by the TLS working group (hence my addition of them to the list) and =20= > I would > much rather have one extensions RFC rather than several. This is a =20= > good concept > and fills a need; perhaps the TLS working group would take this on. > > Flow control remains an issue which I do not think that this extension > addresses. > > Is this a security exposure? or just, like syslog over UDP, an =20 > inconvenient > truth? > > The petch-gerhards draft allows the recipient of the unidirectional =20= > flow to > initiate the DTLS 'connection', and so enables it to re-establish =20 > the connection > when anything goes wrong. This would seem an alternative to consider. > > Tom Petch > > ----- Original Message ----- > From: "Gerhard Muenz" > To: ; > Cc: "Michael Tuexen" ; "Robin Seggelmann" > ; "Daniel Mentz" > Sent: Tuesday, July 28, 2009 10:41 AM > Subject: [Syslog] Missing dead peer detection in DTLS > > > Hi, > > This mail goes to the ipfix and syslog mailing lists in order to > summarize the common issues regarding DTLS. > > IPFIX specifies support of DTLS as mandatory for transport over UDP =20= > and > SCTP in RFC5101. In SYSLOG, it is intended to standardize DTLS for > transport over UDP. > > In IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, and =20= > we > will have a first implementation of IPFIX-over-DTLS/SCTP very soon. > During this implementation effort, we found that the current > specification of DTLS/UDP has a severe flaw when used with > unidirectional protocols (like IPFIX): The sender cannot recognize if > the receiver has crashed and lost the DTLS state. > > We discuss this issue in a draft: > http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00 > http://www.ietf.org/proceedings/75/slides/ipfix-6.pdf > > I've had a look at draft-feng-syslog-transport-dtls-01 and > draft-petch-gerhards-syslog-transport-dtls-02. It seems that this > problem has not yet been covered, although the problem should be the > same for SYSLOG. > > As a solution, the DTLS Heartbeat Extension has been proposed very =20 > recently: > http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00 > A feature patch for OpenSSL is available: > http://sctp.fh-muenster.de/dtls-patches.html#features > > So, I think that we should support this standardization initiative =20 > as it > solves our problem. For IPFIX and SYSLOG over DTLS/UDP, we then can > specify that the DTLS Heartbeat Extension MUST be implemented. > > Dan suggested to have a single document solving the DTLS issues > regarding unidirectional protocols. I think that such a document is =20= > not > needed if we have DTLS Heartbeat Extension. > > Regards, > Gerhard > > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > > > From root@core3.amsl.com Fri Jul 31 03:00:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3EB6D3A6CD8; Fri, 31 Jul 2009 03:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090731100001.3EB6D3A6CD8@core3.amsl.com> Date: Fri, 31 Jul 2009 03:00:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 10:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Mediation: Problem Statement Author(s) : A. Kobayashi, et al. Filename : draft-ietf-ipfix-mediators-problem-statement-05.txt Pages : 31 Date : 2009-07-31 Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. This document describes the IPFIX Mediation applicability examples, along with some problems that network administrators have been facing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mediators-problem-statement-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-31024621.I-D@ietf.org> --NextPart-- From akoba@nttv6.net Fri Jul 31 21:09:35 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32EF83A67EA for ; Fri, 31 Jul 2009 21:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.117 X-Spam-Level: ** X-Spam-Status: No, score=2.117 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_LOCALHOST=0.457, HELO_LOCALHOST=3.941, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDkBf9ox+gte for ; Fri, 31 Jul 2009 21:09:34 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id C8D1E3A67F0 for ; Fri, 31 Jul 2009 21:08:39 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n7148PCh073674 for ; Sat, 1 Aug 2009 13:08:27 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 01 Aug 2009 13:08:29 +0900 From: Atsushi Kobayashi To: ipfix@ietf.org In-Reply-To: <20090731100001.3EB6D3A6CD8@core3.amsl.com> References: <20090731100001.3EB6D3A6CD8@core3.amsl.com> Message-Id: <20090801130620.A8EE.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [192.16.178.5]); Sat, 01 Aug 2009 13:08:28 +0900 (JST) Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 04:09:35 -0000 Dear all, I have submitted new version yesterday thanks to Brian, Gerhard, and Benoit. Thank you very much. All of issues have resolved. It is ready for 2nd WG Last Call. Regards, Atsushi On Fri, 31 Jul 2009 03:00:01 -0700 (PDT) Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > > Title : IPFIX Mediation: Problem Statement > Author(s) : A. Kobayashi, et al. > Filename : draft-ietf-ipfix-mediators-problem-statement-05.txt > Pages : 31 > Date : 2009-07-31 > > Flow-based measurement is a popular method for various network > monitoring usages. The sharing of flow-based information for > monitoring applications having different requirements raises some > open issues in terms of measurement system scalability, flow-based > measurement flexibility, and export reliability that IPFIX Mediation > may help resolve. This document describes the IPFIX Mediation > applicability examples, along with some problems that network > administrators have been facing. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -- Atsushi Kobayashi