From majordomo@mil.doit.wisc.edu Thu May 2 12:43:13 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12634 for ; Thu, 2 May 2002 12:43:12 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 173JJb-0002lF-00 for ipfix-list@mil.doit.wisc.edu; Thu, 02 May 2002 11:20:19 -0500 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 173JJZ-0002kE-00 for ipfix@net.doit.wisc.edu; Thu, 02 May 2002 11:20:17 -0500 Received: from ccook.quarrytech.com (CCOOK [10.1.3.133]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JW2727XJ; Thu, 2 May 2002 12:19:46 -0400 Message-Id: <4.3.1.0.20020502122035.02e90820@email.quarrytech.com> X-Sender: ccook@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 02 May 2002 12:25:48 -0400 To: ipfix@net.doit.wisc.edu From: "Christopher R. Cook" Subject: [ipfix] CFMP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk Sender: majordomo listserver Can any one help me with this .. ? Does any one remember an effort know as CFMP - Content Flow Management Protocol ? A while back it was being worked on by Cisco & Apogee ... it basically dealt with how to efficiently move large amounts of data from network elements to an initial repository for ( accounting, mediation ...) What I'm trying to find out is ..Did that work get folded in to this effort (IPfix) .... Was it a predecessor to the IPFIX wg ... ? Thanks .... -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon May 6 11:01:25 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22364 for ; Mon, 6 May 2002 11:01:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 174jhZ-00036g-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 May 2002 09:42:57 -0500 Received: from h032.c001.snv.cp.net ([209.228.32.142] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 174jhX-000366-00 for ipfix@net.doit.wisc.edu; Mon, 06 May 2002 09:42:55 -0500 Received: (cpmta 20086 invoked from network); 6 May 2002 07:42:23 -0700 Received: from 24.221.253.53 (HELO kcn) by smtp.register-admin.com (209.228.32.142) with SMTP; 6 May 2002 07:42:23 -0700 X-Sent: 6 May 2002 14:42:23 GMT Message-ID: <006901c1f50c$44ddbe00$850f880a@kcn> From: "K.C. Norseth" To: , "Benoit Claise" Cc: References: Subject: Re: [ipfix] IPFIX-architecture Section 5 Date: Mon, 6 May 2002 08:42:36 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit HI all, ----- Original Message ----- From: "kevin.zhang" To: "Benoit Claise" Cc: Sent: Tuesday, April 30, 2002 12:00 PM Subject: RE: [ipfix] IPFIX-architecture Section 5 | Hi Benoit, | | Please see my comments. | | > -----Original Message----- | > From: Benoit Claise [mailto:bclaise@cisco.com] | > Sent: Tuesday, April 30, 2002 11:17 AM | > To: kevin.zhang@xacct.com | > Cc: ipfix@net.doit.wisc.edu | > Subject: Re: [ipfix] IPFIX-architecture Section 5 | > | > | > Hi Kevin, | > | > | > > Hi All, | > > | > > I have the following comments regarding section 5.1.2 and | > section 5.1.4 in draft-ietf-ipfix-architecture-01.txt. | > > | > > I quote from our charter, the IPFIX system MUST - | > > " Ensure that the flow export system is reliable in that it will | > > minimize the likelihood of flow data being lost due to resource | > > constraints in the exporter or receiver and to accurately report | > > such loss if it occurs." | > > | > > As minimizing the flow data loss is a primary goal, I believe | > the functionality specified at the export process and collector | > is not sufficient. I thus propose the following modifications - | > > | > > ------------------------- | > > Original - | > > 5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) | > > | > > 1. Ability to detect loss of connectivity with the collector and | > > trigger the appropriate action (eg. a switch over to an | > > alternate collector.) | > > 2. Optionally export flow records to multiple collectors. | > > 3. Monitor control information/flow record export, detect any | > > overload in the process of exporting. | > > Modifications - | > > 5.1.2. IPFIX Device (at Export Process) Functionality | > > | > > 1. Ability to detect loss of connectivity with the collector | > and trigger the appropriate actions (e.g. a switch over to an | > alternate collector) | > > 2. Optionally export flow records to multiple collectors. | > > 3. Optionally re-transmit flow records upon indications of | > flow record losses from the collector. | > | > I don't like too much the term "re-transmit". | > What if you don't have the flow records anymore? | > | The IPFIX protocol should support application level reliability as user desires. This is | why I added "re-transmission" as an optional exporter functionality. My understanding |of the IPFIX protocol is that we need to provide adequate mechansims that would |allow different user requirements (e.g. reliability, redundancy, performance related |considerations) being addressed. Whether these capabilities are invoked by the IPFIX |users (applications using IPFIX protocol)would be implementation specific. I think the key word is optionally. In the case of an overload though, this usually means there is too much information and storing it on the optional device may be prohibitive. In the case where we have the collector on the device, this could be OK. Of course, looking intothe future, as devices end up having more storage capability and such, this may be more feasible. | | | > > | > > 4. Monitor control information from the collector and export | > process, detect any overload conditions in the export process | > and/or the collector. | > | > "Monitor control information from the collector and export process". | > I think this is confusing. We really want to monitor 2 things: | > - the control information | > - the export process | I agree, this is acutally what I meant. How about changing it to "Monitor control | information from the collector, monitor export process, detect ..." | | > And not the control information from the export process, as we | > could understand it from your sentence. | > | | | > I disagree with "the overload conditions on the collector", we | > are concentrating on the exporter | | IPFIX protocol is split between exporter and collectors. If the collector can indicate | the overload condition, the exporter should detect it and take actions just as |overloading at the export process. We are addressing an IPFIX system, and try to |"Minimize" losses as charter outlined. Detection of collector overloading is one way of |minimizing losses, as there's no point to sending to a overloaded collector, where data is |dropped; instead, fail-over to a redundant collector would be a much better approach. | | | > >From the requirements draft: | > 2.6. Collector | > | > The collector receives flow records from one or more export | > processes. The collector might process or store received flow | > record, but these actions are out of the scope of this document. | > | > > | > > ------------------------------------ | > > | > > ------------------------------------ | > > Original - | > > 5.1.4. IPFIX Protocol on Collector | > > | > > 1. Monitor the reception of export packets from IPFIX device. | > > 2. Optionally notify the status and overload conditions to the | > > IPFIX device. | > > | > > Modifications - | > > 5.1.4. Collector Functionality | > > 1. Receive and decode the flow records from the IPFIX devices. | > > 2. Ability to indicate flow record losses to the exporting | > IPFIX device and/or IPFIX users. | > | > Agreed. | > | > Regards, Benoit | > | > > | > > 3. Optionally notify the status and overload conditions to the | > IPFIX device. How would you propose this to happen? K.C. | > > ----------------------------------------- | > > | > > Thanks, | > > | > > Kevin | -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon May 6 11:06:12 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22581 for ; Mon, 6 May 2002 11:06:12 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 174jkj-0003Bh-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 May 2002 09:46:14 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 174jkh-0003Aw-00 for ipfix@net.doit.wisc.edu; Mon, 06 May 2002 09:46:11 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-163.cisco.com [144.254.7.163]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA04904; Mon, 6 May 2002 16:45:38 +0200 (MET DST) Message-ID: <3CD69712.D4706832@cisco.com> Date: Mon, 06 May 2002 16:45:38 +0200 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX-architecture Section 5 References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by strange-brew.cisco.com id QAA04904 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA22581 Hi Kevin, > > > > -----Original Message----- > > From: Benoit Claise [mailto:bclaise@cisco.com] > > Sent: Tuesday, April 30, 2002 11:17 AM > > To: kevin.zhang@xacct.com > > Cc: ipfix@net.doit.wisc.edu > > Subject: Re: [ipfix] IPFIX-architecture Section 5 > > > > > > Hi Kevin, > > > > > > > Hi All, > > > > > > I have the following comments regarding section 5.1.2 and > > section 5.1.4 in draft-ietf-ipfix-architecture-01.txt. > > > > > > I quote from our charter, the IPFIX system MUST - > > > " Ensure that the flow export system is reliable in that it will > > > minimize the likelihood of flow data being lost due to resource > > > constraints in the exporter or receiver and to accurately report > > > such loss if it occurs." > > > > > > As minimizing the flow data loss is a primary goal, I believe > > the functionality specified at the export process and collector > > is not sufficient. I thus propose the following modifications - > > > > > > ------------------------- > > > Original - > > > 5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) > > > > > > 1. Ability to detect loss of connectivity with the collector and > > > trigger the appropriate action (eg. a switch over to an > > > alternate collector.) > > > 2. Optionally export flow records to multiple collectors. > > > 3. Monitor control information/flow record export, detect any > > > overload in the process of exporting. > > > Modifications - > > > 5.1.2. IPFIX Device (at Export Process) Functionality > > > > > > 1. Ability to detect loss of connectivity with the collector > > and trigger the appropriate actions (e.g. a switch over to an > > alternate collector) > > > 2. Optionally export flow records to multiple collectors. > > > 3. Optionally re-transmit flow records upon indications of > > flow record losses from the collector. > > > > I don't like too much the term "re-transmit". > > What if you don't have the flow records anymore? > > > The IPFIX protocol should support application level reliability as user desires. This is why I added "re-transmission" as an optional exporter functionality. My understanding of the IPFIX protocol is that we need to provide adequate mechansims that would allow different user requirements (e.g. reliability, redundancy, performance related considerations) being addressed. Whether these capabilities are invoked by the IPFIX users (applications using IPFIX protocol)would be implementation specific. Then I would simply write: Optionally re-transmit lost flow records, if possible > > > > > > > > 4. Monitor control information from the collector and export > > process, detect any overload conditions in the export process > > and/or the collector. > > > > "Monitor control information from the collector and export process". > > I think this is confusing. We really want to monitor 2 things: > > - the control information > > - the export process > I agree, this is acutally what I meant. How about changing it to "Monitor control information from the collector, monitor export process, detect ..." So at the end, you want to change from: 3. Monitor control information/flow record export, detect .... to: 3. Monitor control information from the collector, monitor export process, detect ... This is almost the same. I just think that "Monitor control information" (without from the collector) is more generic. > > > > And not the control information from the export process, as we > > could understand it from your sentence. > > > > > I disagree with "the overload conditions on the collector", we > > are concentrating on the exporter > > IPFIX protocol is split between exporter and collectors. If the collector can indicate the overload condition, the exporter should detect it and take actions just as overloading at the export process. We are addressing an IPFIX system, and try to "Minimize" losses as charter outlined. Detection of collector overloading is one way of minimizing losses, as there's no point to sending to a overloaded collector, where data is dropped; instead, fail-over to a redundant collector would be a much better approach. Right, but this is part of the "monitoring the control information". Seeing the requirements definition of the collector "these actions are out of the scope of this document.", I think that we don't want to impose anything requirements to the collector. To summarize, I would just take back the original sentence: 3. Monitor control information and flow record export, detect any overload in the process of exporting. Regards, Benoit > > > > > >From the requirements draft: > > 2.6. Collector > > > > The collector receives flow records from one or more export > > processes. The collector might process or store received flow > > record, but these actions are out of the scope of this document. > > > > > > > > ------------------------------------ > > > > > > ------------------------------------ > > > Original - > > > 5.1.4. IPFIX Protocol on Collector > > > > > > 1. Monitor the reception of export packets from IPFIX device. > > > 2. Optionally notify the status and overload conditions to the > > > IPFIX device. > > > > > > Modifications - > > > 5.1.4. Collector Functionality > > > 1. Receive and decode the flow records from the IPFIX devices. > > > 2. Ability to indicate flow record losses to the exporting > > IPFIX device and/or IPFIX users. > > > > Agreed. > > > > Regards, Benoit > > > > > > > > 3. Optionally notify the status and overload conditions to the > > IPFIX device. > > > ----------------------------------------- > > > > > > Thanks, > > > > > > Kevin > > > ޖ[hfhzݢ++njwlk/zZy > > yI칻&ޙj:+vw""vvƲ칻&ފ,j܀ > > bm*_ݢ++n܆+ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon May 6 11:15:54 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23369 for ; Mon, 6 May 2002 11:15:54 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 174jrF-0003LN-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 May 2002 09:52:58 -0500 Received: from h000.c001.snv.cp.net ([209.228.32.114] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 174jrD-0003Ko-00 for ipfix@net.doit.wisc.edu; Mon, 06 May 2002 09:52:55 -0500 Received: (cpmta 14243 invoked from network); 6 May 2002 07:52:24 -0700 Received: from 24.221.253.53 (HELO kcn) by smtp.register-admin.com (209.228.32.114) with SMTP; 6 May 2002 07:52:24 -0700 X-Sent: 6 May 2002 14:52:24 GMT Message-ID: <00a501c1f50d$ab162620$850f880a@kcn> From: "K.C. Norseth" To: "IPFIX" Subject: [ipfix] Missing Bytes Date: Mon, 6 May 2002 08:52:38 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit This is a question that has been asked several times when working with NetFlow, that I have never been able to answer other than "Cisco does it so we had to". The question is: What bytes are counted and what are dropped in a packet? If I pass 100 bytes in 1 packet through a port, only 82 bytes are counted by NetFlow. Why? What are these bytes that are not counted? In explaining this in IPFIX terms, are we saying that the onservation point is not at the port, but deeper down in the device after some bytes are stripped off? I think that it should be 100 bytes accounted by the IPFIX device. What do other people say? K.C. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon May 6 11:31:21 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23723 for ; Mon, 6 May 2002 11:31:21 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 174k95-0003ic-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 May 2002 10:11:23 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 174k93-0003hx-00 for ipfix@net.doit.wisc.edu; Mon, 06 May 2002 10:11:21 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-163.cisco.com [144.254.7.163]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA19867; Mon, 6 May 2002 17:10:48 +0200 (MET DST) Message-ID: <3CD69CF7.87D9482D@cisco.com> Date: Mon, 06 May 2002 17:10:48 +0200 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "K.C. Norseth" CC: IPFIX Subject: Re: [ipfix] Missing Bytes References: <00a501c1f50d$ab162620$850f880a@kcn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit KC, The question is: what do you count? Layer 2 information? Layer 2 header? Layer 3 information only. Netflow chose not to report any layer 2 packets (retransmission, link set up, etc...) So, removing all layer 2 info, we're left with layer 3. So the number of bytes reported in Netflow is only the layer 3 info, IP header included. Regards, Benoit > This is a question that has been asked several times when working with > NetFlow, that I have never been able to answer other than "Cisco does it so > we had to". The question is: What bytes are counted and what are dropped in > a packet? > > If I pass 100 bytes in 1 packet through a port, only 82 bytes are counted by > NetFlow. Why? What are these bytes that are not counted? In explaining > this in IPFIX terms, are we saying that the onservation point is not at the > port, but deeper down in the device after some bytes are stripped off? > > I think that it should be 100 bytes accounted by the IPFIX device. What do > other people say? > > K.C. > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon May 6 11:44:01 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24240 for ; Mon, 6 May 2002 11:44:01 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 174kPF-00046C-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 May 2002 10:28:05 -0500 Received: from mailhub.xacct.com ([204.253.100.25]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 174kPD-00045T-00 for ipfix@net.doit.wisc.edu; Mon, 06 May 2002 10:28:03 -0500 Received: (qmail 16781 invoked from network); 6 May 2002 15:27:31 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.us.xacct.com with SMTP; 6 May 2002 15:27:31 -0000 Received: from Kevinz (ip-216-73-166-251.hqglobal.net [216.73.166.251]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g46FS8419875; Mon, 6 May 2002 08:28:08 -0700 Reply-To: From: "kevin.zhang" To: "Benoit Claise" Cc: Subject: RE: [ipfix] IPFIX-architecture Section 5 Date: Mon, 6 May 2002 11:28:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CD69712.D4706832@cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA24240 Hi Benoit, > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Monday, May 06, 2002 10:46 AM > To: kevin.zhang@xacct.com > Cc: ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] IPFIX-architecture Section 5 > > > Hi Kevin, > > > > > > > > -----Original Message----- > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > > Sent: Tuesday, April 30, 2002 11:17 AM > > > To: kevin.zhang@xacct.com > > > Cc: ipfix@net.doit.wisc.edu > > > Subject: Re: [ipfix] IPFIX-architecture Section 5 > > > > > > > > > Hi Kevin, > > > > > > > > > > Hi All, > > > > > > > > I have the following comments regarding section 5.1.2 and > > > section 5.1.4 in draft-ietf-ipfix-architecture-01.txt. > > > > > > > > I quote from our charter, the IPFIX system MUST - > > > > " Ensure that the flow export system is reliable in that it will > > > > minimize the likelihood of flow data being lost due to resource > > > > constraints in the exporter or receiver and to accurately report > > > > such loss if it occurs." > > > > > > > > As minimizing the flow data loss is a primary goal, I believe > > > the functionality specified at the export process and collector > > > is not sufficient. I thus propose the following modifications - > > > > > > > > ------------------------- > > > > Original - > > > > 5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) > > > > > > > > 1. Ability to detect loss of connectivity with the > collector and > > > > trigger the appropriate action (eg. a switch over to an > > > > alternate collector.) > > > > 2. Optionally export flow records to multiple collectors. > > > > 3. Monitor control information/flow record export, detect any > > > > overload in the process of exporting. > > > > Modifications - > > > > 5.1.2. IPFIX Device (at Export Process) Functionality > > > > > > > > 1. Ability to detect loss of connectivity with the collector > > > and trigger the appropriate actions (e.g. a switch over to an > > > alternate collector) > > > > 2. Optionally export flow records to multiple collectors. > > > > 3. Optionally re-transmit flow records upon indications of > > > flow record losses from the collector. > > > > > > I don't like too much the term "re-transmit". > > > What if you don't have the flow records anymore? > > > > > The IPFIX protocol should support application level reliability > as user desires. This is why I added "re-transmission" as an > optional exporter functionality. My understanding of the IPFIX > protocol is that we need to provide adequate mechansims that > would allow different user requirements (e.g. reliability, > redundancy, performance related considerations) being addressed. > Whether these capabilities are invoked by the IPFIX users > (applications using IPFIX protocol)would be implementation specific. > > Then I would simply write: > Optionally re-transmit lost flow records, if possible This sounds good to me, let's incorporate the change if nobody rejects it. > > > > > > > > > > > > > 4. Monitor control information from the collector and export > > > process, detect any overload conditions in the export process > > > and/or the collector. > > > > > > "Monitor control information from the collector and export process". > > > I think this is confusing. We really want to monitor 2 things: > > > - the control information > > > - the export process > > I agree, this is acutally what I meant. How about changing it > to "Monitor control information from the collector, monitor > export process, detect ..." > > So at the end, you want to change > from: > 3. Monitor control information/flow record export, detect .... > to: > 3. Monitor control information from the collector, monitor > export process, detect ... > > This is almost the same. I just think that "Monitor control > information" (without from the collector) is more generic. > As the term "control information" is specific in the IPFIX context, that is why we should explicitly indicate its origin. Other status information may come from other processes residing on the IPFIX exporting device, of which export process is of our interests here. > > > > > > > And not the control information from the export process, as we > > > could understand it from your sentence. > > > > > > > > I disagree with "the overload conditions on the collector", we > > > are concentrating on the exporter > > > > IPFIX protocol is split between exporter and collectors. If > the collector can indicate the overload condition, the exporter > should detect it and take actions just as overloading at the > export process. We are addressing an IPFIX system, and try to > "Minimize" losses as charter outlined. Detection of collector > overloading is one way of minimizing losses, as there's no point > to sending to a overloaded collector, where data is dropped; > instead, fail-over to a redundant collector would be a much > better approach. > > Right, but this is part of the "monitoring the control information". > Seeing the requirements definition of the collector "these > actions are out of the scope of this document.", I think that we > don't want to impose anything requirements to the collector. > I believe we meant that how the collector processes flow information is out of the scope. The collector's functionality to support protocol is within the scope. The bottom line is that the IPFIX protocol MUST provide mechanisms (or capabilities) to support the highly reliable flow exporting, that is reliable (application level ack) and robust (failover, failback). Whether the IPFIX end points want to invoke these capabilities is implementation specific and depending on the applications using the IPFIX system. > To summarize, I would just take back the original sentence: > 3. Monitor control information and flow record export, detect any > overload in the process of exporting. > > Regards, Benoit > > > > > > > > > > > >From the requirements draft: > > > 2.6. Collector > > > > > > The collector receives flow records from one or more export > > > processes. The collector might process or store received flow > > > record, but these actions are out of the scope of this document. > > > > > > > > > > > ------------------------------------ > > > > > > > > ------------------------------------ > > > > Original - > > > > 5.1.4. IPFIX Protocol on Collector > > > > > > > > 1. Monitor the reception of export packets from IPFIX device. > > > > 2. Optionally notify the status and overload conditions to the > > > > IPFIX device. > > > > > > > > Modifications - > > > > 5.1.4. Collector Functionality > > > > 1. Receive and decode the flow records from the IPFIX devices. > > > > 2. Ability to indicate flow record losses to the exporting > > > IPFIX device and/or IPFIX users. > > > > > > Agreed. > > > > > > Regards, Benoit > > > > > > > > > > > 3. Optionally notify the status and overload conditions to the > > > IPFIX device. > > > > ----------------------------------------- > > > > > > > > Thanks, > > > > > > > > Kevin > > > > ޖ[hfhzݢ++njwlk/zZy > > > yI칻&ޙj:+vw""vvƲ칻&ފ,j܀ > > > bm*_ݢ++n܆+ޖ[hfhzݢ++njwlk/zZyƠyI칻&ޙj:+vw""vvƲ칻&ފ,j܀bm*_ݢ++n܆+ From majordomo@mil.doit.wisc.edu Mon May 6 13:00:50 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27243 for ; Mon, 6 May 2002 13:00:50 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 174lQ3-0005Uk-00 for ipfix-list@mil.doit.wisc.edu; Mon, 06 May 2002 11:32:59 -0500 Received: from h032.c001.snv.cp.net ([209.228.32.142] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 174lQ2-0005UO-00 for ipfix@net.doit.wisc.edu; Mon, 06 May 2002 11:32:58 -0500 Received: (cpmta 27254 invoked from network); 6 May 2002 09:32:26 -0700 Received: from 24.221.253.53 (HELO kcn) by smtp.register-admin.com (209.228.32.142) with SMTP; 6 May 2002 09:32:26 -0700 X-Sent: 6 May 2002 16:32:26 GMT Message-ID: <013501c1f51b$a460e460$850f880a@kcn> From: "K.C. Norseth" To: "Benoit Claise" Cc: "IPFIX" References: <00a501c1f50d$ab162620$850f880a@kcn> <3CD69CF7.87D9482D@cisco.com> Subject: Re: [ipfix] Missing Bytes Date: Mon, 6 May 2002 10:32:40 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, If I pass an UDP or TCP packet of 100 bytes through the port, 82 is what is counted. This will need to be documented in IPFIX, whatever protocol is selected. It always bothered me to tell customers that I could not give them a reason other than Cisco does it. I could not find any documentation on the Cisco website for this. K.C. ----- Original Message ----- From: "Benoit Claise" To: "K.C. Norseth" Cc: "IPFIX" Sent: Monday, May 06, 2002 9:10 AM Subject: Re: [ipfix] Missing Bytes | KC, | | The question is: what do you count? | Layer 2 information? Layer 2 header? Layer 3 information only. | Netflow chose not to report any layer 2 packets (retransmission, link set up, | etc...) | So, removing all layer 2 info, we're left with layer 3. | So the number of bytes reported in Netflow is only the layer 3 info, IP header | included. | | Regards, Benoit | | > This is a question that has been asked several times when working with | > NetFlow, that I have never been able to answer other than "Cisco does it so | > we had to". The question is: What bytes are counted and what are dropped in | > a packet? | > | > If I pass 100 bytes in 1 packet through a port, only 82 bytes are counted by | > NetFlow. Why? What are these bytes that are not counted? In explaining | > this in IPFIX terms, are we saying that the onservation point is not at the | > port, but deeper down in the device after some bytes are stripped off? | > | > I think that it should be 100 bytes accounted by the IPFIX device. What do | > other people say? | > | > K.C. | > | > -- | > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body | > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say | > "unsubscribe ipfix" in message body | > Archive http://ipfix.doit.wisc.edu/archive/ | | | -- | Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body | Unsubscribe mailto:majordomo@net.doit.wisc.edu and say | "unsubscribe ipfix" in message body | Archive http://ipfix.doit.wisc.edu/archive/ | -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 8 05:42:48 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29471 for ; Wed, 8 May 2002 05:42:48 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 175NZ6-0005xU-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 May 2002 04:16:52 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 175NZ4-0005wh-00 for ipfix@net.doit.wisc.edu; Wed, 08 May 2002 04:16:50 -0500 Received: from cisco.com (bclaise-isdn-home4.cisco.com [10.49.4.221]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA18325; Wed, 8 May 2002 11:16:15 +0200 (MET DST) Message-ID: <3CD8ECDE.7050004@cisco.com> Date: Wed, 08 May 2002 11:16:14 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX-architecture Section 5 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by strange-brew.cisco.com id LAA18325 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA29471 Hi Kevin, >>> >>> >>>>-----Original Message----- >>>>From: Benoit Claise [mailto:bclaise@cisco.com] >>>>Sent: Tuesday, April 30, 2002 11:17 AM >>>>To: kevin.zhang@xacct.com >>>>Cc: ipfix@net.doit.wisc.edu >>>>Subject: Re: [ipfix] IPFIX-architecture Section 5 >>>> >>>> >>>>Hi Kevin, >>>> >>>> >>>> >>>> >>>>>Hi All, >>>>> >>>>>I have the following comments regarding section 5.1.2 and >>>>> >>>>> >>>>section 5.1.4 in draft-ietf-ipfix-architecture-01.txt. >>>> >>>> >>>>>I quote from our charter, the IPFIX system MUST - >>>>>" Ensure that the flow export system is reliable in that it will >>>>> minimize the likelihood of flow data being lost due to resource >>>>> constraints in the exporter or receiver and to accurately report >>>>> such loss if it occurs." >>>>> >>>>>As minimizing the flow data loss is a primary goal, I believe >>>>> >>>>> >>>>the functionality specified at the export process and collector >>>>is not sufficient. I thus propose the following modifications - >>>> >>>> >>>>>------------------------- >>>>>Original - >>>>>5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) >>>>> >>>>> 1. Ability to detect loss of connectivity with the >>>>> >>>>> >>collector and >> >> >>>>> trigger the appropriate action (eg. a switch over to an >>>>> alternate collector.) >>>>> 2. Optionally export flow records to multiple collectors. >>>>> 3. Monitor control information/flow record export, detect any >>>>> overload in the process of exporting. >>>>>Modifications - >>>>>5.1.2. IPFIX Device (at Export Process) Functionality >>>>> >>>>>1. Ability to detect loss of connectivity with the collector >>>>> >>>>> >>>>and trigger the appropriate actions (e.g. a switch over to an >>>>alternate collector) >>>> >>>> >>>>>2. Optionally export flow records to multiple collectors. >>>>>3. Optionally re-transmit flow records upon indications of >>>>> >>>>> >>>>flow record losses from the collector. >>>> >>>>I don't like too much the term "re-transmit". >>>>What if you don't have the flow records anymore? >>>> >>>> >>>> >>>The IPFIX protocol should support application level reliability >>> >>> >>as user desires. This is why I added "re-transmission" as an >>optional exporter functionality. My understanding of the IPFIX >>protocol is that we need to provide adequate mechansims that >>would allow different user requirements (e.g. reliability, >>redundancy, performance related considerations) being addressed. >>Whether these capabilities are invoked by the IPFIX users >>(applications using IPFIX protocol)would be implementation specific. >> >>Then I would simply write: >>Optionally re-transmit lost flow records, if possible >> >> > >This sounds good to me, let's incorporate the change if nobody rejects it. > > > > >>> >>> >>>>>4. Monitor control information from the collector and export >>>>> >>>>> >>>>process, detect any overload conditions in the export process >>>>and/or the collector. >>>> >>>>"Monitor control information from the collector and export process". >>>>I think this is confusing. We really want to monitor 2 things: >>>>- the control information >>>>- the export process >>>> >>>> >>>I agree, this is acutally what I meant. How about changing it >>> >>> >>to "Monitor control information from the collector, monitor >>export process, detect ..." >> >>So at the end, you want to change >>from: >> 3. Monitor control information/flow record export, detect .... >>to: >> 3. Monitor control information from the collector, monitor >>export process, detect ... >> >>This is almost the same. I just think that "Monitor control >>information" (without from the collector) is more generic. >> >> >> >As the term "control information" is specific in the IPFIX context, that is why we should explicitly indicate its origin. Other status information may come from other processes residing on the IPFIX exporting device, of which export process is of our interests here. > No. If you look at the definition from the architecture draft, the control information is exported. So we don't speak of control information from other processes. * Control Stream, Data Stream: The information that needs to be exported from the IPFIX device can be classified into the following categories: Norseth & Sadasivan [Page 6] Internet Draft draft-ietf-ipfix-architecture-01.txt February 2002 - Control Information : This includes the flow type definition, selection criteria for packets within the flow. This is also called as Control Stream. This stream carries all the information for the end-points to understand the IPFIX protocol and specifically for the receiver to understand and interpret the data stream send by the sender. - Flow record : This includes data records corresponding to the information on various observed flows at each of the observation point.This is also called as Data Stream. > > > > >>> >>> >>>>And not the control information from the export process, as we >>>>could understand it from your sentence. >>>> >>>> >>>> >>>>I disagree with "the overload conditions on the collector", we >>>>are concentrating on the exporter >>>> >>>> >>>IPFIX protocol is split between exporter and collectors. If >>> >>> >>the collector can indicate the overload condition, the exporter >>should detect it and take actions just as overloading at the >>export process. We are addressing an IPFIX system, and try to >>"Minimize" losses as charter outlined. Detection of collector >>overloading is one way of minimizing losses, as there's no point >>to sending to a overloaded collector, where data is dropped; >>instead, fail-over to a redundant collector would be a much >>better approach. >> >>Right, but this is part of the "monitoring the control information". >>Seeing the requirements definition of the collector "these >>actions are out of the scope of this document.", I think that we >>don't want to impose anything requirements to the collector. >> >> >> >I believe we meant that how the collector processes flow information is out of the scope. The collector's functionality to support protocol is within the scope. The bottom line is that the IPFIX protocol MUST provide mechanisms (or capabilities) to support the highly reliable flow exporting, that is reliable (application level ack) and robust (failover, failback). Whether the IPFIX end points want to invoke these capabilities is implementation specific and depending on the applications using the IPFIX system. > Again, I disagree with the MUST. If the charter was saying: "Ensure that the flow export system is reliable", then I would agree. But the charter says: "Ensure that the flow export system is reliable in that it will minimize the likelihood of flow data being lost due to resource constraints in the exporter or receiver and to accurately report such loss if it occurs." Regards, Benoit > > > > > >>To summarize, I would just take back the original sentence: >> 3. Monitor control information and flow record export, detect any >> overload in the process of exporting. >> >>Regards, Benoit >> >> >> >>> >>> >>>>>From the requirements draft: >>>>2.6. Collector >>>> >>>> The collector receives flow records from one or more export >>>> processes. The collector might process or store received flow >>>> record, but these actions are out of the scope of this document. >>>> >>>> >>>> >>>>>------------------------------------ >>>>> >>>>>------------------------------------ >>>>>Original - >>>>>5.1.4. IPFIX Protocol on Collector >>>>> >>>>> 1. Monitor the reception of export packets from IPFIX device. >>>>> 2. Optionally notify the status and overload conditions to the >>>>> IPFIX device. >>>>> >>>>>Modifications - >>>>>5.1.4. Collector Functionality >>>>>1. Receive and decode the flow records from the IPFIX devices. >>>>>2. Ability to indicate flow record losses to the exporting >>>>> >>>>> >>>>IPFIX device and/or IPFIX users. >>>> >>>>Agreed. >>>> >>>>Regards, Benoit >>>> >>>> >>>> >>>>>3. Optionally notify the status and overload conditions to the >>>>> >>>>> >>>>IPFIX device. >>>> >>>> >>>>>----------------------------------------- >>>>> >>>>>Thanks, >>>>> >>>>>Kevin >>>>>-^(TM)s(S([hfhs(?zݢ++njwlk/zZS(yz( >>>>> >>>>> >>>>yI칻&^(TM)?j:+v0/00w""vvƲ칻&S(--^(TM),j>EUR >>>>bmY"*_<ݢ++n++ >>>> >>>> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 8 10:16:17 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08403 for ; Wed, 8 May 2002 10:16:16 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 175RaY-0005RC-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 May 2002 08:34:38 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 175RaU-0005Po-00 for ipfix@net.doit.wisc.edu; Wed, 08 May 2002 08:34:34 -0500 Received: from cisco.com (bclaise-isdn-home4.cisco.com [10.49.4.221]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA21004; Wed, 8 May 2002 15:33:59 +0200 (MET DST) Message-ID: <3CD92948.4010406@cisco.com> Date: Wed, 08 May 2002 15:34:00 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "K.C. Norseth" CC: IPFIX , pvanderv@cisco.com Subject: Re: [ipfix] Missing Bytes References: <00a501c1f50d$ab162620$850f880a@kcn> <3CD69CF7.87D9482D@cisco.com> <013501c1f51b$a460e460$850f880a@kcn> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi KC, >Hi Benoit, > >If I pass an UDP or TCP packet of 100 bytes through the port, 82 is what is >counted. > What you told me estonished me, so we made some testing with the same traffic generator as yours: IXIA. We made the test with a data link layer "Ethernet 2" In IXIA, you can determine the frame size, which by default include the CRC (4 bytes). Generate a UDP packet of 100 bytes actually gives you a packet composed of: 14 bytes: Ethernet header (6 destination MAC + 6 source MAC + 2 type) 20 bytes: IP header 8 bytes: UDP header 54 bytes: Data 4 bytes: CRC So, removing the layer 2 information (14 + 4), you end up with NetFlow accounting 82 bytes. Maybe the test you had in mind was to generate a UDP packet with some UDP data of 100 bytes. In that case, NetFlow would have reported 100 + 8 UDP + 20 IP = 128 bytes. Pay attention that the reported bytes (generating the packets the IXIA way) will obvioulsy depend on the Data Link layer encapsulation. Now, I fully agree that the Data Model draft should clearly explain what is meant by "number of bytes" in a flow . Regards, Benoit > >This will need to be documented in IPFIX, whatever protocol is selected. It >always bothered me to tell customers that I could not give them a reason >other than Cisco does it. I could not find any documentation on the Cisco >website for this. > >K.C. > > >----- Original Message ----- >From: "Benoit Claise" >To: "K.C. Norseth" >Cc: "IPFIX" >Sent: Monday, May 06, 2002 9:10 AM >Subject: Re: [ipfix] Missing Bytes > > >| KC, >| >| The question is: what do you count? >| Layer 2 information? Layer 2 header? Layer 3 information only. >| Netflow chose not to report any layer 2 packets (retransmission, link set >up, >| etc...) >| So, removing all layer 2 info, we're left with layer 3. >| So the number of bytes reported in Netflow is only the layer 3 info, IP >header >| included. >| >| Regards, Benoit >| >| > This is a question that has been asked several times when working with >| > NetFlow, that I have never been able to answer other than "Cisco does it >so >| > we had to". The question is: What bytes are counted and what are dropped >in >| > a packet? >| > >| > If I pass 100 bytes in 1 packet through a port, only 82 bytes are >counted by >| > NetFlow. Why? What are these bytes that are not counted? In >explaining >| > this in IPFIX terms, are we saying that the onservation point is not at >the >| > port, but deeper down in the device after some bytes are stripped off? >| > >| > I think that it should be 100 bytes accounted by the IPFIX device. What >do >| > other people say? >| > >| > K.C. >| > >| > -- >| > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message >body >| > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >| > "unsubscribe ipfix" in message body >| > Archive http://ipfix.doit.wisc.edu/archive/ >| >| >| -- >| Help mailto:majordomo@net.doit.wisc.edu and say "help" in message >body >| Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >| "unsubscribe ipfix" in message body >| Archive http://ipfix.doit.wisc.edu/archive/ >| > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 8 10:27:26 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08946 for ; Wed, 8 May 2002 10:27:26 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 175Ru9-0005v5-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 May 2002 08:54:53 -0500 Received: from pool-162-83-254-186.ny5030.east.verizon.net ([162.83.254.186] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 175Ru5-0005uy-00 for ipfix@net.doit.wisc.edu; Wed, 08 May 2002 08:54:49 -0500 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g48DsAx27389; Wed, 8 May 2002 09:54:10 -0400 Reply-To: From: "Carter Bullard" To: "'Benoit Claise'" , "'K.C. Norseth'" Cc: "'IPFIX'" , Subject: RE: [ipfix] Missing Bytes Date: Wed, 8 May 2002 09:54:02 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A3BE@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED66076B81@ptah.newyork.qosient.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Guys, Any chance that there could be a 'capabilities' indication as to what layers the IPFIX data applies to. The three cases I can think of as a start would be Layer 2, Sub-Layer 3 (mpls), and Layer 3. These seem generic enough to handle even appletalk ;o) While Layer 4 maybe unambiguous in some cases, it seems that the IPFIX model can't generate just Layer 4 flow data, so these may be reasonable? And when reporting bytes, it may be important to specify if the value is derived (extracted from the packet header itself) or realized (true wire length). Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Benoit Claise > Sent: Wednesday, May 08, 2002 9:34 AM > To: K.C. Norseth > Cc: IPFIX; pvanderv@cisco.com > Subject: Re: [ipfix] Missing Bytes > > > Hi KC, > > >Hi Benoit, > > > >If I pass an UDP or TCP packet of 100 bytes through the port, 82 is > >what is counted. > > > What you told me estonished me, so we made some testing with the same > traffic generator as yours: IXIA. > We made the test with a data link layer "Ethernet 2" > In IXIA, you can determine the frame size, which by default > include the > CRC (4 bytes). > Generate a UDP packet of 100 bytes actually gives you a > packet composed of: 14 bytes: Ethernet header (6 destination > MAC + 6 source MAC + 2 type) 20 bytes: IP header 8 bytes: > UDP header 54 bytes: Data 4 bytes: CRC > > So, removing the layer 2 information (14 + 4), you end up > with NetFlow > accounting 82 bytes. > > Maybe the test you had in mind was to generate a UDP packet with some > UDP data of 100 bytes. > In that case, NetFlow would have reported 100 + 8 UDP + 20 IP > = 128 bytes. > > Pay attention that the reported bytes (generating the packets > the IXIA > way) will obvioulsy depend on the Data Link layer encapsulation. > > Now, I fully agree that the Data Model draft should clearly > explain what > is meant by "number of bytes" in a flow . > > Regards, Benoit > > > > >This will need to be documented in IPFIX, whatever protocol is > >selected. It always bothered me to tell customers that I could not > >give them a reason other than Cisco does it. I could not find any > >documentation on the Cisco website for this. > > > >K.C. > > > > > >----- Original Message ----- > >From: "Benoit Claise" > >To: "K.C. Norseth" > >Cc: "IPFIX" > >Sent: Monday, May 06, 2002 9:10 AM > >Subject: Re: [ipfix] Missing Bytes > > > > > >| KC, > >| > >| The question is: what do you count? > >| Layer 2 information? Layer 2 header? Layer 3 information only. > >| Netflow chose not to report any layer 2 packets > (retransmission, link > >| set > >up, > >| etc...) > >| So, removing all layer 2 info, we're left with layer 3. > >| So the number of bytes reported in Netflow is only the > layer 3 info, > >| IP > >header > >| included. > >| > >| Regards, Benoit > >| > >| > This is a question that has been asked several times > when working > >| > with NetFlow, that I have never been able to answer other than > >| > "Cisco does it > >so > >| > we had to". The question is: What bytes are counted and what are > >| > dropped > >in > >| > a packet? > >| > > >| > If I pass 100 bytes in 1 packet through a port, only 82 bytes are > >counted by > >| > NetFlow. Why? What are these bytes that are not counted? In > >explaining > >| > this in IPFIX terms, are we saying that the onservation point is > >| > not at > >the > >| > port, but deeper down in the device after some bytes are > stripped > >| > off? > >| > > >| > I think that it should be 100 bytes accounted by the > IPFIX device. > >| > What > >do > >| > other people say? > >| > > >| > K.C. > >| > > >| > -- > >| > Help mailto:majordomo@net.doit.wisc.edu and say > "help" in message > >body > >| > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe > >| > ipfix" in message body > >| > Archive http://ipfix.doit.wisc.edu/archive/ > >| > >| > >| -- > >| Help mailto:majordomo@net.doit.wisc.edu and say > "help" in message > >body > >| Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe > >| ipfix" in message body > >| Archive http://ipfix.doit.wisc.edu/archive/ > >| > > > > > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 8 10:55:08 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10307 for ; Wed, 8 May 2002 10:55:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 175SIg-0006Rt-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 May 2002 09:20:14 -0500 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 175SIe-0006Rn-00 for ipfix-req@net.doit.wisc.edu; Wed, 08 May 2002 09:20:12 -0500 Received: from fokus.fhg.de (dhcp132 [195.37.78.132]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g48EJx421778; Wed, 8 May 2002 16:19:59 +0200 (MEST) Message-ID: <3CD933EA.10508@fokus.fhg.de> Date: Wed, 08 May 2002 16:19:22 +0200 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: =?ISO-8859-1?Q?J=FCrgen?= Quittek CC: Benoit Claise , Sebastian Zander , Georg Carle , "K.C. Norseth" , IPFIX Requirements <" ipfix-req"@net.doit.wisc.edu> Subject: [ipfix-req] IPFIX security considerations for requirements document Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.gmd.de id g48EJx421778 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA10307 Hi Jrgen and others, attached you can find the re-worked security considerations section for the IPFIX requirements draft. If you think there are additional threads that needs to be covered or have further comments, send them to me via email. We also can discuss this in our next teleconfernce (May 17). Regards Tanja Security considerations The future IPFIX protocol must be capable to transport data over the public Internet. Therefore it cannot be excluded that an attacker can gain access to the network and capture exchanged packets. This document describes requirements for IP Flow Information Export (IPFIX). It therefore also states the required security features for a future IPFIX protocol. Like other requirements, the security requirements differ for the considered applications. The incentive to modify collected data for accounting or intrusion detection for instance is usually higher than the incentive to change data collected for traffic profiling. Therefore the required security features in this document are listed per application in the appendix. The suggestion of concrete solutions for achieving the required security properties will be part of the IPFIX architecture and protocol description and is out of scope of this document. Furthermore, methods for remote configuration of the IPFIX processes are out of scope for IPFIX. Therefore, threads that are caused by data exchange for remote configuration are not considered here. The following potential security hazards for an IPFIX protocol can be identified: - Disclosure of IP flow information data The content of IPFIX flow records should be kept confidential between the involved parties (exporting process and colleting process) user and provider). Observation of IPFIX flow records gives an attacker information about the active flows in the network, communication endpoints and traffic patterns. This information can not only be used to spy out user behavior but also to plan and conceal future attacks. Therefore the requirements document recommends to ensure the confidentiality of the transferred data. This can be achieved for instance by encryption. - Forgery of IPFIX flow records Especially for applications like accounting or intrusion detection there are strong incentives (e.g. to save money or prevent the detection of an attack) to forge exported IPFIX flow records. This can be done either by altering data (flow records) on the path or by injecting forged flow records that pretend to be originated by the original exporting process. In order to make the IPFIX protocol resistant against such attacks this document requires to ensure authenticity and integrity for the IPFIX data transfer. Special caution is required if security applications rely on IPFIX data With forged flow records it is possible to trick on security applications. It is for instance possible to pretend that a DoS attack happens without even launching a real attack. - Denial of Service (DoS) attacks DoS attacks on routers or other middleboxes that have the IPFIX protocol implemented would also affect the IPFIX protocol and impair the sending of IPFIX records. Nevertheless, since such hazards are not induced specifically by the IPFIX protocol the prevention of such attacks is out of scope of this document. Nevertheless IPFIX itself also causes potential hazards for DoS attacks. All process that expect the reception of traffic can be target of a DoS attack. With the IPFIX exporting process this is only the case if it supports the pull mode (which can be an optional feature of the future IPFIX protocol according to this document). The collecting process always expects data and therefore can be flooded by forged flow records. -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 8 11:11:06 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11445 for ; Wed, 8 May 2002 11:11:06 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 175Sbu-0006uI-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 May 2002 09:40:06 -0500 Received: from mailhub.xacct.com ([204.253.100.25]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 175Sbq-0006tN-00 for ipfix@net.doit.wisc.edu; Wed, 08 May 2002 09:40:02 -0500 Received: (qmail 12146 invoked from network); 8 May 2002 14:39:31 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.us.xacct.com with SMTP; 8 May 2002 14:39:30 -0000 Received: from Kevinz (slip-32-102-181-10.md.us.prserv.net [32.102.181.10]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g48Ee3418812; Wed, 8 May 2002 07:40:03 -0700 Reply-To: From: "kevin.zhang" To: "Benoit Claise" Cc: Subject: RE: [ipfix] IPFIX-architecture Section 5 Date: Wed, 8 May 2002 10:40:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CD8ECDE.7050004@cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA11445 Hi Benoit, > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Wednesday, May 08, 2002 5:16 AM > To: kevin.zhang@xacct.com > Cc: ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] IPFIX-architecture Section 5 > > > Hi Kevin, > > >>> > >>> > >>>>-----Original Message----- > >>>>From: Benoit Claise [mailto:bclaise@cisco.com] > >>>>Sent: Tuesday, April 30, 2002 11:17 AM > >>>>To: kevin.zhang@xacct.com > >>>>Cc: ipfix@net.doit.wisc.edu > >>>>Subject: Re: [ipfix] IPFIX-architecture Section 5 > >>>> > >>>> > >>>>Hi Kevin, > >>>> > >>>> > >>>> > >>>> > >>>>>Hi All, > >>>>> > >>>>>I have the following comments regarding section 5.1.2 and > >>>>> > >>>>> > >>>>section 5.1.4 in draft-ietf-ipfix-architecture-01.txt. > >>>> > >>>> > >>>>>I quote from our charter, the IPFIX system MUST - > >>>>>" Ensure that the flow export system is reliable in that it will > >>>>> minimize the likelihood of flow data being lost due to resource > >>>>> constraints in the exporter or receiver and to accurately report > >>>>> such loss if it occurs." > >>>>> > >>>>>As minimizing the flow data loss is a primary goal, I believe > >>>>> > >>>>> > >>>>the functionality specified at the export process and collector > >>>>is not sufficient. I thus propose the following modifications - > >>>> > >>>> > >>>>>------------------------- > >>>>>Original - > >>>>>5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) > >>>>> > >>>>> 1. Ability to detect loss of connectivity with the > >>>>> > >>>>> > >>collector and > >> > >> > >>>>> trigger the appropriate action (eg. a switch over to an > >>>>> alternate collector.) > >>>>> 2. Optionally export flow records to multiple collectors. > >>>>> 3. Monitor control information/flow record export, detect any > >>>>> overload in the process of exporting. > >>>>>Modifications - > >>>>>5.1.2. IPFIX Device (at Export Process) Functionality > >>>>> > >>>>>1. Ability to detect loss of connectivity with the collector > >>>>> > >>>>> > >>>>and trigger the appropriate actions (e.g. a switch over to an > >>>>alternate collector) > >>>> > >>>> > >>>>>2. Optionally export flow records to multiple collectors. > >>>>>3. Optionally re-transmit flow records upon indications of > >>>>> > >>>>> > >>>>flow record losses from the collector. > >>>> > >>>>I don't like too much the term "re-transmit". > >>>>What if you don't have the flow records anymore? > >>>> > >>>> > >>>> > >>>The IPFIX protocol should support application level reliability > >>> > >>> > >>as user desires. This is why I added "re-transmission" as an > >>optional exporter functionality. My understanding of the IPFIX > >>protocol is that we need to provide adequate mechansims that > >>would allow different user requirements (e.g. reliability, > >>redundancy, performance related considerations) being addressed. > >>Whether these capabilities are invoked by the IPFIX users > >>(applications using IPFIX protocol)would be implementation specific. > >> > >>Then I would simply write: > >>Optionally re-transmit lost flow records, if possible > >> > >> > > > >This sounds good to me, let's incorporate the change if nobody > rejects it. > > > > > > > > > >>> > >>> > >>>>>4. Monitor control information from the collector and export > >>>>> > >>>>> > >>>>process, detect any overload conditions in the export process > >>>>and/or the collector. > >>>> > >>>>"Monitor control information from the collector and export process". > >>>>I think this is confusing. We really want to monitor 2 things: > >>>>- the control information > >>>>- the export process > >>>> > >>>> > >>>I agree, this is acutally what I meant. How about changing it > >>> > >>> > >>to "Monitor control information from the collector, monitor > >>export process, detect ..." > >> > >>So at the end, you want to change > >>from: > >> 3. Monitor control information/flow record export, detect .... > >>to: > >> 3. Monitor control information from the collector, monitor > >>export process, detect ... > >> > >>This is almost the same. I just think that "Monitor control > >>information" (without from the collector) is more generic. > >> > >> > >> > >As the term "control information" is specific in the IPFIX > context, that is why we should explicitly indicate its origin. > Other status information may come from other processes residing > on the IPFIX exporting device, of which export process is of our > interests here. > > > No. If you look at the definition from the architecture draft, the > control information is exported. So we don't speak of control > information from other processes. > > * Control Stream, Data Stream: > The information that needs to be exported from the IPFIX device > can be classified into the following categories: > > I don't agree that the control information can only be exported from an exportor to the collector. I raised this point many times on the mailing list and at the last meeting, and I believe certain agreement on this had achieved. I had another email proposing changes to this definition. Please see my email re. Terminology - Control Stream, Data Stream. I looked many standard protocols, and have not been able to find any uni-directional restrictions on control information exchanges. As we are using a connection-oriented transport protocol (TCP, SCTP), it is reasonable to assume that IPFIX is connection oriented, and the control information exchange helps to setup the connection/session. > > > > Norseth & Sadasivan [Page 6] > > > Internet Draft draft-ietf-ipfix-architecture-01.txt February 2002 > > > - Control Information : > This includes the flow type definition, selection criteria > for packets within the flow. This is also called as Control > Stream. This stream carries all the information for the > end-points to understand the IPFIX protocol and specifically > for the receiver to understand and interpret the data stream > send by the sender. > > - Flow record : > This includes data records corresponding to the information > on various observed flows at each of the observation > point.This is also called as Data Stream. > > > > > > > > > > >>> > >>> > >>>>And not the control information from the export process, as we > >>>>could understand it from your sentence. > >>>> > >>>> > >>>> > >>>>I disagree with "the overload conditions on the collector", we > >>>>are concentrating on the exporter > >>>> > >>>> > >>>IPFIX protocol is split between exporter and collectors. If > >>> > >>> > >>the collector can indicate the overload condition, the exporter > >>should detect it and take actions just as overloading at the > >>export process. We are addressing an IPFIX system, and try to > >>"Minimize" losses as charter outlined. Detection of collector > >>overloading is one way of minimizing losses, as there's no point > >>to sending to a overloaded collector, where data is dropped; > >>instead, fail-over to a redundant collector would be a much > >>better approach. > >> > >>Right, but this is part of the "monitoring the control information". > >>Seeing the requirements definition of the collector "these > >>actions are out of the scope of this document.", I think that we > >>don't want to impose anything requirements to the collector. > >> > >> > >> > >I believe we meant that how the collector processes flow > information is out of the scope. The collector's functionality to > support protocol is within the scope. The bottom line is that the > IPFIX protocol MUST provide mechanisms (or capabilities) to > support the highly reliable flow exporting, that is reliable > (application level ack) and robust (failover, failback). Whether > the IPFIX end points want to invoke these capabilities is > implementation specific and depending on the applications using > the IPFIX system. > > > Again, I disagree with the MUST. > If the charter was saying: "Ensure that the flow export system is > reliable", then I would agree. > But the charter says: "Ensure that the flow export system is reliable in > that it will minimize the likelihood of flow data being lost due to > resource constraints > in the exporter or receiver and to accurately report such loss if it > occurs." > Minimizing the likelihood of flow data loss is a typical objective for any systems. This means given the constraints of the system (e.g. exporter processing and memory resource), the loss should be minimized. If there's no such constraint, no data loss should be achieved. We should not design a protocol that intrinsically can not ensure reliability even when exporter/collector resources are not a issue. > Regards, Benoit > > > > > > > > > > > > >>To summarize, I would just take back the original sentence: > >> 3. Monitor control information and flow record export, detect any > >> overload in the process of exporting. > >> > >>Regards, Benoit > >> > >> > >> > >>> > >>> > >>>>>From the requirements draft: > >>>>2.6. Collector > >>>> > >>>> The collector receives flow records from one or more export > >>>> processes. The collector might process or store received flow > >>>> record, but these actions are out of the scope of this document. > >>>> > >>>> > >>>> > >>>>>------------------------------------ > >>>>> > >>>>>------------------------------------ > >>>>>Original - > >>>>>5.1.4. IPFIX Protocol on Collector > >>>>> > >>>>> 1. Monitor the reception of export packets from IPFIX device. > >>>>> 2. Optionally notify the status and overload conditions to the > >>>>> IPFIX device. > >>>>> > >>>>>Modifications - > >>>>>5.1.4. Collector Functionality > >>>>>1. Receive and decode the flow records from the IPFIX devices. > >>>>>2. Ability to indicate flow record losses to the exporting > >>>>> > >>>>> > >>>>IPFIX device and/or IPFIX users. > >>>> > >>>>Agreed. > >>>> > >>>>Regards, Benoit > >>>> > >>>> > >>>> > >>>>>3. Optionally notify the status and overload conditions to the > >>>>> > >>>>> > >>>>IPFIX device. > >>>> > >>>> > >>>>>----------------------------------------- > >>>>> > >>>>>Thanks, > >>>>> > >>>>>Kevin > >>>>>-^(TM)s(S([hfhs(?zݢ++njwlk/zZS(yz( > >>>>> > >>>>> > >>>>yI칻&^(TM)?j:+v0/00w""vvƲ칻&S(-- > ^(TM),j>EUR > >>>>bmY"*_<ݢ++n++ > >>>> > >>>> > > ޖ[hfhzݢ++njwlk/zZyƠyI칻&ޙj:+vw""vvƲ칻&ފ,j܀bm*_ݢ++n܆+ From majordomo@mil.doit.wisc.edu Wed May 8 11:16:53 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12073 for ; Wed, 8 May 2002 11:16:53 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 175Sr0-0007FE-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 May 2002 09:55:42 -0500 Received: from pool-162-83-254-186.ny5030.east.verizon.net ([162.83.254.186] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 175Sqx-0007F4-00 for ipfix-req@net.doit.wisc.edu; Wed, 08 May 2002 09:55:39 -0500 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g48Etcx27542 for ; Wed, 8 May 2002 10:55:38 -0400 Reply-To: From: "Carter Bullard" To: Subject: [ipfix-req] IPFIX security considerations for requirements document Date: Wed, 8 May 2002 10:55:30 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607E437@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12073 Hey Tanja, Can I make a suggestion on wording for the section on Forgery? It may see like a minor thing, but I think its important. > - Forgery of IPFIX flow records > Especially for applications like accounting or intrusion > detection there are strong incentives (e.g. to save money > or prevent the detection of an attack) to forge exported > IPFIX flow records. This can be done either by altering > data (flow records) on the path or by injecting > forged flow records that pretend to be originated by > the original exporting process. I know what you're after, but it kinda sounds like there is an incentive for the accounting or intrusion detection system to forge records. How's this as an alternative? - Forgery of IPFIX flow records Because of the potential uses of IPFIX flow records in applications such as accounting and security, there is a strong need to provide source authentication and integrity assurance/protection for IPFIX data. Hope this helps, Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby > Sent: Wednesday, May 08, 2002 10:19 AM > To: Jrgen Quittek > Cc: Benoit Claise; Sebastian Zander; Georg Carle; K.C. > Norseth; IPFIX Requirements > Subject: [ipfix-req] IPFIX security considerations for > requirements document > > > Hi Jrgen and others, > > attached you can find the re-worked security considerations > section for > the IPFIX requirements draft. > If you think there are additional threads that needs to be covered or > have further comments, send them to me via email. We also can discuss > this in our next teleconfernce (May 17). > > Regards > Tanja > > Security considerations > > The future IPFIX protocol must be capable to transport data over the > public Internet. Therefore it cannot be excluded that an attacker can > gain access to the network and capture exchanged packets. > This document describes requirements for IP Flow Information Export > (IPFIX). It therefore also states the required security > features for a > future IPFIX protocol. Like other requirements, the security > requirements differ for the considered applications. The incentive to > modify collected data for accounting or intrusion detection > for instance > is usually higher than the incentive to change data collected for > traffic profiling. Therefore the required security features in this > document are listed per application in the appendix. > The suggestion of concrete solutions for achieving the > required security > properties > will be part of the IPFIX architecture and protocol > description and is > out of scope of this document. Furthermore, methods for remote > configuration of the IPFIX processes are out of scope for IPFIX. > Therefore, threads that are caused by data exchange for remote > configuration are not considered here. > > The following potential security hazards for an IPFIX protocol can be > identified: > > - Disclosure of IP flow information data > The content of IPFIX flow records should be kept confidential between > the involved parties (exporting process and colleting > process) user and > provider). Observation of IPFIX flow records gives an attacker > information about the active flows in the network, communication > endpoints and traffic patterns. This information can not only > be used to > spy out user behavior but also to plan and conceal future attacks. > Therefore the requirements document recommends to ensure the > confidentiality of the transferred data. This can be achieved for > instance by encryption. > > - Forgery of IPFIX flow records > Especially for applications like accounting or intrusion > detection there > are strong incentives (e.g. to save money or prevent the > detection of an > attack) to forge exported IPFIX flow records. This can be > done either > by altering data (flow records) on the path or by injecting > forged flow > records that pretend to be originated by the original > exporting process. > In order to make the IPFIX protocol resistant against such > attacks this > document requires to ensure authenticity and integrity for the IPFIX > data transfer. > Special caution is required if security applications rely on > IPFIX data > With forged flow records it is possible to trick on security > applications. It is for instance possible to pretend that a > DoS attack > happens without even launching a real attack. > > - Denial of Service (DoS) attacks > DoS attacks on routers or other middleboxes that have the > IPFIX protocol > implemented would also affect the IPFIX protocol and impair > the sending > of IPFIX records. Nevertheless, since such hazards are not induced > specifically by the IPFIX protocol the prevention of such > attacks is out > of scope of this document. > > Nevertheless IPFIX itself also causes potential hazards for > DoS attacks. > All process that expect the reception of traffic can be > target of a DoS > attack. With the IPFIX exporting process this is only the case if it > supports the pull mode (which can be an optional feature of > the future > IPFIX protocol according to this document). The collecting process > always expects data and therefore can be flooded by forged > flow records. > > > -- > Dipl.-Ing. Tanja Zseby > FhI FOKUS/Global Networking Email: > zseby@fokus.fhg.de > Kaiserin-Augusta-Allee 31 Phone: > +49-30-3463-7153 > D-10589 Berlin, Germany Fax: > +49-30-3463-8153 > -------------------------------------------------------------- > ------------------------ > "Living on earth is expensive but it includes a free trip > around the sun." (Anonymous) > -------------------------------------------------------------- > ------------------------ > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 8 11:23:42 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12292 for ; Wed, 8 May 2002 11:23:42 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 175Sxu-0007Pq-00 for ipfix-list@mil.doit.wisc.edu; Wed, 08 May 2002 10:02:50 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 175Sxt-0007PZ-00 for ipfix@net.doit.wisc.edu; Wed, 08 May 2002 10:02:49 -0500 Received: from cisco.com (bclaise-isdn-home4.cisco.com [10.49.4.221]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA16578; Wed, 8 May 2002 17:02:14 +0200 (MET DST) Message-ID: <3CD93DF7.4030609@cisco.com> Date: Wed, 08 May 2002 17:02:15 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX-architecture Section 5 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by strange-brew.cisco.com id RAA16578 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12292 Hi Kevin, > > >>-----Original Message----- >>From: Benoit Claise [mailto:bclaise@cisco.com] >>Sent: Wednesday, May 08, 2002 5:16 AM >>To: kevin.zhang@xacct.com >>Cc: ipfix@net.doit.wisc.edu >>Subject: Re: [ipfix] IPFIX-architecture Section 5 >> >> >>Hi Kevin, >> >> >> >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Benoit Claise [mailto:bclaise@cisco.com] >>>>>>Sent: Tuesday, April 30, 2002 11:17 AM >>>>>>To: kevin.zhang@xacct.com >>>>>>Cc: ipfix@net.doit.wisc.edu >>>>>>Subject: Re: [ipfix] IPFIX-architecture Section 5 >>>>>> >>>>>> >>>>>>Hi Kevin, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi All, >>>>>>> >>>>>>>I have the following comments regarding section 5.1.2 and >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>section 5.1.4 in draft-ietf-ipfix-architecture-01.txt. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>I quote from our charter, the IPFIX system MUST - >>>>>>>" Ensure that the flow export system is reliable in that it will >>>>>>> minimize the likelihood of flow data being lost due to resource >>>>>>> constraints in the exporter or receiver and to accurately report >>>>>>> such loss if it occurs." >>>>>>> >>>>>>>As minimizing the flow data loss is a primary goal, I believe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>the functionality specified at the export process and collector >>>>>>is not sufficient. I thus propose the following modifications - >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>------------------------- >>>>>>>Original - >>>>>>>5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) >>>>>>> >>>>>>> 1. Ability to detect loss of connectivity with the >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>collector and >>>> >>>> >>>> >>>> >>>>>>> trigger the appropriate action (eg. a switch over to an >>>>>>> alternate collector.) >>>>>>> 2. Optionally export flow records to multiple collectors. >>>>>>> 3. Monitor control information/flow record export, detect any >>>>>>> overload in the process of exporting. >>>>>>>Modifications - >>>>>>>5.1.2. IPFIX Device (at Export Process) Functionality >>>>>>> >>>>>>>1. Ability to detect loss of connectivity with the collector >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>and trigger the appropriate actions (e.g. a switch over to an >>>>>>alternate collector) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>2. Optionally export flow records to multiple collectors. >>>>>>>3. Optionally re-transmit flow records upon indications of >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>flow record losses from the collector. >>>>>> >>>>>>I don't like too much the term "re-transmit". >>>>>>What if you don't have the flow records anymore? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>The IPFIX protocol should support application level reliability >>>>> >>>>> >>>>> >>>>> >>>>as user desires. This is why I added "re-transmission" as an >>>>optional exporter functionality. My understanding of the IPFIX >>>>protocol is that we need to provide adequate mechansims that >>>>would allow different user requirements (e.g. reliability, >>>>redundancy, performance related considerations) being addressed. >>>>Whether these capabilities are invoked by the IPFIX users >>>>(applications using IPFIX protocol)would be implementation specific. >>>> >>>>Then I would simply write: >>>>Optionally re-transmit lost flow records, if possible >>>> >>>> >>>> >>>> >>>This sounds good to me, let's incorporate the change if nobody >>> >>> >>rejects it. >> >> >>> >>> >>> >>> >>>>> >>>>> >>>>> >>>>> >>>>>>>4. Monitor control information from the collector and export >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>process, detect any overload conditions in the export process >>>>>>and/or the collector. >>>>>> >>>>>>"Monitor control information from the collector and export process". >>>>>>I think this is confusing. We really want to monitor 2 things: >>>>>>- the control information >>>>>>- the export process >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I agree, this is acutally what I meant. How about changing it >>>>> >>>>> >>>>> >>>>> >>>>to "Monitor control information from the collector, monitor >>>>export process, detect ..." >>>> >>>>So at the end, you want to change >>>>from: >>>> 3. Monitor control information/flow record export, detect .... >>>>to: >>>> 3. Monitor control information from the collector, monitor >>>>export process, detect ... >>>> >>>>This is almost the same. I just think that "Monitor control >>>>information" (without from the collector) is more generic. >>>> >>>> >>>> >>>> >>>> >>>As the term "control information" is specific in the IPFIX >>> >>> >>context, that is why we should explicitly indicate its origin. >>Other status information may come from other processes residing >>on the IPFIX exporting device, of which export process is of our >>interests here. >> >> >>No. If you look at the definition from the architecture draft, the >>control information is exported. So we don't speak of control >>information from other processes. >> >>* Control Stream, Data Stream: >>The information that needs to be exported from the IPFIX device >>can be classified into the following categories: >> >> >> >> >I don't agree that the control information can only be exported from an exportor to the collector. I raised this point many times on the mailing list and at the last meeting, and I believe certain agreement on this had achieved. I had another email proposing changes to this definition. Please see my email re. Terminology - Control Stream, Data Stream. I looked many standard protocols, and have not been able to find any uni-directional restrictions on control information exchanges. As we are using a connection-oriented transport protocol (TCP, SCTP), it is reasonable to assume that IPFIX is connection oriented, and the control information exchange helps to setup the connection/session. > I was not discussing the direction of the control information. I was discussing the fact that the control information is between the exporter and the collector. And not between the export process on the exporter and any other processes on the exporter. I was referring to your sentence (that I disagree with): "Other status information may come from other processes residing on the IPFIX exporting device, of which export process is of our interests here." Regards, Benoit > > > > >> >>Norseth & Sadasivan [Page 6] >> > >>Internet Draft draft-ietf-ipfix-architecture-01.txt February 2002 >> >> >>- Control Information : >>This includes the flow type definition, selection criteria >>for packets within the flow. This is also called as Control >>Stream. This stream carries all the information for the >>end-points to understand the IPFIX protocol and specifically >>for the receiver to understand and interpret the data stream >>send by the sender. >> >>- Flow record : >>This includes data records corresponding to the information >>on various observed flows at each of the observation >>point.This is also called as Data Stream. >> >> >> >>> >>> >>> >>> >>>>> >>>>> >>>>> >>>>> >>>>>>And not the control information from the export process, as we >>>>>>could understand it from your sentence. >>>>>> >>>>>> >>>>>> >>>>>>I disagree with "the overload conditions on the collector", we >>>>>>are concentrating on the exporter >>>>>> >>>>>> >>>>>> >>>>>> >>>>>IPFIX protocol is split between exporter and collectors. If >>>>> >>>>> >>>>> >>>>> >>>>the collector can indicate the overload condition, the exporter >>>>should detect it and take actions just as overloading at the >>>>export process. We are addressing an IPFIX system, and try to >>>>"Minimize" losses as charter outlined. Detection of collector >>>>overloading is one way of minimizing losses, as there's no point >>>>to sending to a overloaded collector, where data is dropped; >>>>instead, fail-over to a redundant collector would be a much >>>>better approach. >>>> >>>>Right, but this is part of the "monitoring the control information". >>>>Seeing the requirements definition of the collector "these >>>>actions are out of the scope of this document.", I think that we >>>>don't want to impose anything requirements to the collector. >>>> >>>> >>>> >>>> >>>> >>>I believe we meant that how the collector processes flow >>> >>> >>information is out of the scope. The collector's functionality to >>support protocol is within the scope. The bottom line is that the >>IPFIX protocol MUST provide mechanisms (or capabilities) to >>support the highly reliable flow exporting, that is reliable >>(application level ack) and robust (failover, failback). Whether >>the IPFIX end points want to invoke these capabilities is >>implementation specific and depending on the applications using >>the IPFIX system. >> >> >>Again, I disagree with the MUST. >>If the charter was saying: "Ensure that the flow export system is >>reliable", then I would agree. >>But the charter says: "Ensure that the flow export system is reliable in >>that it will minimize the likelihood of flow data being lost due to >>resource constraints >>in the exporter or receiver and to accurately report such loss if it >>occurs." >> >> >> > >Minimizing the likelihood of flow data loss is a typical objective for any systems. This means given the constraints of the system (e.g. exporter processing and memory resource), the loss should be minimized. If there's no such constraint, no data loss should be achieved. > >We should not design a protocol that intrinsically can not ensure reliability even when exporter/collector resources are not a issue. > > > >>Regards, Benoit >> >> >> >>> >>> >>> >>> >>> >>>>To summarize, I would just take back the original sentence: >>>> 3. Monitor control information and flow record export, detect any >>>> overload in the process of exporting. >>>> >>>>Regards, Benoit >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>From the requirements draft: >>>>>>2.6. Collector >>>>>> >>>>>> The collector receives flow records from one or more export >>>>>> processes. The collector might process or store received flow >>>>>> record, but these actions are out of the scope of this document. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>------------------------------------ >>>>>>> >>>>>>>------------------------------------ >>>>>>>Original - >>>>>>>5.1.4. IPFIX Protocol on Collector >>>>>>> >>>>>>> 1. Monitor the reception of export packets from IPFIX device. >>>>>>> 2. Optionally notify the status and overload conditions to the >>>>>>> IPFIX device. >>>>>>> >>>>>>>Modifications - >>>>>>>5.1.4. Collector Functionality >>>>>>>1. Receive and decode the flow records from the IPFIX devices. >>>>>>>2. Ability to indicate flow record losses to the exporting >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>IPFIX device and/or IPFIX users. >>>>>> >>>>>>Agreed. >>>>>> >>>>>>Regards, Benoit >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>3. Optionally notify the status and overload conditions to the >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>IPFIX device. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>----------------------------------------- >>>>>>> >>>>>>>Thanks, >>>>>>> >>>>>>>Kevin >>>>>>>-^(TM)s(S([hfhs(?zݢ++njwlk/zZS(yz( >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>yI칻&^(TM)?j:+v0/00w""vvƲ칻&S(-- >>>>>> >>>>>> >>^(TM),j>EUR >> >> >>>>>>bmY"*_<ݢ++n++ >>>>>> >>>>>> >>>>>> >>>>>> >> >> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri May 17 10:50:48 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16330 for ; Fri, 17 May 2002 10:50:48 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 178igU-0002o6-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 May 2002 09:26:18 -0500 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 178igT-0002nz-00 for ipfix-req@net.doit.wisc.edu; Fri, 17 May 2002 09:26:17 -0500 Received: from fokus.fhg.de (dhcp176 [195.37.78.176]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g4HEQC011453; Fri, 17 May 2002 16:26:12 +0200 (MEST) Message-ID: <3CE512D5.8090201@fokus.fhg.de> Date: Fri, 17 May 2002 16:25:25 +0200 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Benoit Claise CC: IPFIX Requirements <" ipfix-req"@net.doit.wisc.edu> Subject: [ipfix-req] sampling section Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, here comes the section on sampling. I will also add Sebastians comments to the security section and send you a new version today. Regards Tanja 5.2 Sampling Sampling describes the systematic or random selection of a subset of elements (the sample) out of a set of elements (the parent population). Usually the purpose of applying sampling techniques is to estimate a parameter of the parent population by using only the elements of the subset. In IPFIX sampling techniques can be applied for instance to select a subset of packets out of all packets of a flow or to select a subset of flows out of all flows on a link. Sampling methods differ in their sampling strategy (e.g. systematic or random) and in the event that triggers the selection of an element. The selection of one packet can for instance be triggered by its arrival time (time-based sampling), by its position in the flow (count-based sampling) or by the packet content (content-based sampling). The metering process MAY support measuring traffic by packet sampling. If sampling is supported the sampling method and its parameters MUST be well defined. If the sampling parameters are changed during operation, the new sampling parameters MUST be indicated to all collectors receiving the affected flow records. If the sampling method is changed during operation, the new sampling method with its parameters MUST be indicated to all collectors receiving the affected flow records. comments: - I didnt remove "systematic or random selection" because I think it is useful to see that this are attributes to the selection process (which defines the sampling method) - I didnt add the sentence "The IPFIX requirements don't impose any sampling methods but," because I think this is clear, because sampling has a MAY. -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri May 17 10:59:18 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16556 for ; Fri, 17 May 2002 10:59:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 178j0g-0003FE-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 May 2002 09:47:10 -0500 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 178j0e-0003F5-00 for ipfix-req@net.doit.wisc.edu; Fri, 17 May 2002 09:47:08 -0500 Received: from fokus.fhg.de (dhcp176 [195.37.78.176]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g4HEl2015212; Fri, 17 May 2002 16:47:02 +0200 (MEST) Message-ID: <3CE517B7.4020104@fokus.fhg.de> Date: Fri, 17 May 2002 16:46:15 +0200 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Benoit Claise CC: IPFIX Requirements <" ipfix-req"@net.doit.wisc.edu> Subject: [ipfix-req] security considerations Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, here comes the new security considerations section. I integrated comments from Sebastian and Carter. Regards Tanja 9. Security considerations The future IPFIX protocol must be capable to transport data over the public Internet. Therefore it cannot be excluded that an attacker captures or modifies exchanged packets or inserts additional packets. This document describes requirements for IP Flow Information Export (IPFIX). It therefore also states the required security features for a future IPFIX protocol. Like other requirements, the security requirements differ for the considered applications. The incentive to modify collected data for accounting or intrusion detection for instance is usually higher than the incentive to change data collected for traffic profiling. Therefore the required security features in this document are listed per application in the appendix. The suggestion of concrete solutions for achieving the required security properties will be part of the IPFIX architecture and protocol description and is out of scope of this document. Furthermore, methods for remote configuration of the IPFIX processes are out of scope for IPFIX. Therefore, threads that are caused by data exchange for remote configuration are not considered here. The following potential security hazards for an IPFIX protocol can be identified: - Disclosure of IP flow information data The content of data exchanged by the IPFIX protocol (e.g. IPFIX flow records) should be kept confidential between the involved parties (exporting process and colleting process). Observation of IPFIX flow records gives an attacker information about the active flows in the network, communication endpoints and traffic patterns. This information cannot only be used to spy out user behavior but also to plan and conceal future attacks. Therefore the requirements document recommends to ensure the confidentiality of the transferred data. This can be achieved for instance by encryption. - Forgery of IPFIX flow records Because of the potential uses of IPFIX flow records in accounting and security applications, there are strong incentives to forge exported IPFIX flow records (e.g. to save money or prevent the detection of an attack). This can be done either by altering flow records on the path or by injecting forged flow records that pretend to be originated by the original exporting process. In order to make the IPFIX protocol resistant against such attacks this document requires to ensure authenticity and integrity for the IPFIX data transfer. Special caution is required if security applications rely on IPFIX data. With forged flow records it is possible to trick on security applications. It is for instance possible to pretend that a DoS attack happens without even launching a real attack. - Denial of Service (DoS) attacks DoS attacks on routers or other middleboxes that have the IPFIX protocol implemented would also affect the IPFIX protocol and impair the sending of IPFIX records. Nevertheless, since such hazards are not induced specifically by the IPFIX protocol the prevention of such attacks is out of scope of this document. Nevertheless IPFIX itself also causes potential hazards for DoS attacks. All processes that expect the reception of traffic can be target of a DoS attack. With the IPFIX exporting process this is only the case if it supports the pull mode (which can be an optional feature of the future IPFIX protocol according to this document). The collecting process always expects data and therefore can be flooded by forged flow records. -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri May 17 11:18:33 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17275 for ; Fri, 17 May 2002 11:18:22 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 178jFH-0003ZU-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 May 2002 10:02:15 -0500 Received: from pool-151-204-156-167.ny325.east.verizon.net ([151.204.156.167] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 178jFF-0003ZP-00 for ipfix-req@net.doit.wisc.edu; Fri, 17 May 2002 10:02:13 -0500 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g4HF2Dx18767 for ; Fri, 17 May 2002 11:02:13 -0400 Reply-To: From: "Carter Bullard" To: Subject: FW: [ipfix-req] security considerations Date: Fri, 17 May 2002 11:02:04 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607E486@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Tanja, I sent a rewriting of a part of the security considerations section. This is the section that I suggested. - Forgery of IPFIX flow records Because of the potential uses of IPFIX flow records in applications such as accounting and security, there is a strong need to provide source authentication and integrity assurance/protection for IPFIX data. I believe that it conveys your intention without suggesting that the accounting application could possibly forge data. Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby > Sent: Friday, May 17, 2002 10:46 AM > To: Benoit Claise > Cc: IPFIX Requirements > Subject: [ipfix-req] security considerations > > > Hi Benoit, > > here comes the new security considerations section. I integrated > comments from Sebastian and Carter. > > Regards > Tanja > > > 9. Security considerations > > The future IPFIX protocol must be capable to transport data over the > public Internet. Therefore it cannot be excluded that an attacker > captures or modifies exchanged packets or inserts additional > packets. This document describes requirements for IP Flow > Information Export > (IPFIX). It therefore also states the required security > features for a > future IPFIX protocol. Like other requirements, the security > requirements differ for the considered applications. The incentive to > modify collected data for accounting or intrusion detection > for instance > is usually higher than the incentive to change data collected for > traffic profiling. Therefore the required security features in this > document are listed per application in the appendix. > The suggestion of concrete solutions for achieving the > required security > properties will be part of the IPFIX architecture and protocol > description and is out of scope of this document. > Furthermore, methods > for remote configuration of the IPFIX processes are out of scope for > IPFIX. Therefore, threads that are caused by data exchange for remote > configuration are not considered here. > > The following potential security hazards for an IPFIX protocol can be > identified: > > - Disclosure of IP flow information data > The content of data exchanged by the IPFIX protocol (e.g. IPFIX flow > records) should be kept confidential between the involved parties > (exporting process and colleting process). Observation of IPFIX flow > records gives an attacker information about the active flows in the > network, communication endpoints and traffic patterns. This > information > cannot only be used to spy out user behavior but also to plan and > conceal future attacks. Therefore the requirements document > recommends > to ensure the confidentiality of the transferred data. This can be > achieved for instance by encryption. > > - Forgery of IPFIX flow records > Because of the potential uses of IPFIX flow records in accounting and > security applications, there are strong incentives to forge exported > IPFIX flow records (e.g. to save money or prevent the > detection of an > attack). This can be done either by altering flow records on > the path or > by injecting forged flow records that pretend to be originated by the > original exporting process. In order to make the IPFIX protocol > resistant against such attacks this document requires to ensure > authenticity and integrity for the IPFIX data transfer. > Special caution is required if security applications rely on > IPFIX data. > With forged flow records it is possible to trick on security > applications. It is for instance possible to pretend that a > DoS attack > happens without even launching a real attack. > > - Denial of Service (DoS) attacks > DoS attacks on routers or other middleboxes that have the > IPFIX protocol > implemented would also affect the IPFIX protocol and impair > the sending > of IPFIX records. Nevertheless, since such hazards are not induced > specifically by the IPFIX protocol the prevention of such > attacks is out > of scope of this document. > Nevertheless IPFIX itself also causes potential hazards for > DoS attacks. > All processes that expect the reception of traffic can be target of a > DoS attack. With the IPFIX exporting process this is only the > case if it > supports the pull mode (which can be an optional feature of > the future > IPFIX protocol according to this document). The collecting process > always expects data and therefore can be flooded by forged > flow records. > > > -- > Dipl.-Ing. Tanja Zseby > FhI FOKUS/Global Networking Email: > zseby@fokus.fhg.de > Kaiserin-Augusta-Allee 31 Phone: > +49-30-3463-7153 > D-10589 Berlin, Germany Fax: > +49-30-3463-8153 > -------------------------------------------------------------- > ------------------------ > "Living on earth is expensive but it includes a free trip > around the sun." (Anonymous) > -------------------------------------------------------------- > ------------------------ > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri May 17 11:27:15 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17502 for ; Fri, 17 May 2002 11:27:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 178jNz-0003kT-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 May 2002 10:11:15 -0500 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 178jNw-0003kM-00 for ipfix-req@net.doit.wisc.edu; Fri, 17 May 2002 10:11:13 -0500 Received: from fokus.fhg.de (dhcp176 [195.37.78.176]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g4HFAt018803; Fri, 17 May 2002 17:10:55 +0200 (MEST) Message-ID: <3CE51D50.4010208@fokus.fhg.de> Date: Fri, 17 May 2002 17:10:08 +0200 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: carter@qosient.com CC: "'Benoit Claise'" , "'IPFIX Requirements'" <" ipfix-req"@net.doit.wisc.edu> Subject: Re: [ipfix-req] security considerations References: <5C8959A16A71B449AE793CF52FBBED6607E485@ptah.newyork.qosient.com> Content-Type: multipart/alternative; boundary="------------080602080607000507090303" Precedence: bulk Sender: majordomo listserver --------------080602080607000507090303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Carter, in the new version I already tried to integrate your suggestion into the section.The sentence now is "Because of the potential uses of IPFIX flow records in accounting and security applications, there are strong incentives to forge exported IPFIX flow records (e.g. to save money or prevent the detection of an attack)." I think the last part of your suggestion is already covered in: "In order to make the IPFIX protocol resistant against such attacks this document requires to ensure authenticity and integrity for the IPFIX data transfer." Do you agree with this wording ? Regards Tanja Carter Bullard wrote: >Hey Tanja, > I sent a rewriting of a part of the security considerations >section. This is the section that I suggested. > > >- Forgery of IPFIX flow records >Because of the potential uses of IPFIX flow records in >applications such as accounting and security, there is a >strong need to provide source authentication and integrity >assurance/protection for IPFIX data. > >I believe that it conveys your intention without suggesting >that the accounting application could possibly forge data. > >Carter > >Carter Bullard >QoSient, LLC >300 E. 56th Street, Suite 18K >New York, New York 10022 > >carter@qosient.com >Phone +1 212 588-9133 >Fax +1 212 588-9134 >http://qosient.com > >>-----Original Message----- >>From: majordomo listserver >>[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby >>Sent: Friday, May 17, 2002 10:46 AM >>To: Benoit Claise >>Cc: IPFIX Requirements >>Subject: [ipfix-req] security considerations >> >> >>Hi Benoit, >> >>here comes the new security considerations section. I integrated >>comments from Sebastian and Carter. >> >>Regards >>Tanja >> >> >>9. Security considerations >> >>The future IPFIX protocol must be capable to transport data over the >>public Internet. Therefore it cannot be excluded that an attacker >>captures or modifies exchanged packets or inserts additional >>packets. This document describes requirements for IP Flow >>Information Export >>(IPFIX). It therefore also states the required security >>features for a >>future IPFIX protocol. Like other requirements, the security >>requirements differ for the considered applications. The incentive to >>modify collected data for accounting or intrusion detection >>for instance >>is usually higher than the incentive to change data collected for >>traffic profiling. Therefore the required security features in this >>document are listed per application in the appendix. >>The suggestion of concrete solutions for achieving the >>required security >>properties will be part of the IPFIX architecture and protocol >>description and is out of scope of this document. >>Furthermore, methods >>for remote configuration of the IPFIX processes are out of scope for >>IPFIX. Therefore, threads that are caused by data exchange for remote >>configuration are not considered here. >> >>The following potential security hazards for an IPFIX protocol can be >>identified: >> >>- Disclosure of IP flow information data >>The content of data exchanged by the IPFIX protocol (e.g. IPFIX flow >>records) should be kept confidential between the involved parties >>(exporting process and colleting process). Observation of IPFIX flow >>records gives an attacker information about the active flows in the >>network, communication endpoints and traffic patterns. This >>information >>cannot only be used to spy out user behavior but also to plan and >>conceal future attacks. Therefore the requirements document >>recommends >>to ensure the confidentiality of the transferred data. This can be >>achieved for instance by encryption. >> >>- Forgery of IPFIX flow records >>Because of the potential uses of IPFIX flow records in accounting and >>security applications, there are strong incentives to forge exported >>IPFIX flow records (e.g. to save money or prevent the >>detection of an >>attack). This can be done either by altering flow records on >>the path or >>by injecting forged flow records that pretend to be originated by the >>original exporting process. In order to make the IPFIX protocol >>resistant against such attacks this document requires to ensure >>authenticity and integrity for the IPFIX data transfer. >>Special caution is required if security applications rely on >>IPFIX data. >>With forged flow records it is possible to trick on security >>applications. It is for instance possible to pretend that a >>DoS attack >>happens without even launching a real attack. >> >>- Denial of Service (DoS) attacks >>DoS attacks on routers or other middleboxes that have the >>IPFIX protocol >>implemented would also affect the IPFIX protocol and impair >>the sending >>of IPFIX records. Nevertheless, since such hazards are not induced >>specifically by the IPFIX protocol the prevention of such >>attacks is out >>of scope of this document. >>Nevertheless IPFIX itself also causes potential hazards for >>DoS attacks. >>All processes that expect the reception of traffic can be target of a >>DoS attack. With the IPFIX exporting process this is only the >>case if it >>supports the pull mode (which can be an optional feature of >>the future >>IPFIX protocol according to this document). The collecting process >>always expects data and therefore can be flooded by forged >>flow records. >> >> >>-- >>Dipl.-Ing. Tanja Zseby >>FhI FOKUS/Global Networking Email: >>zseby@fokus.fhg.de >>Kaiserin-Augusta-Allee 31 Phone: >>+49-30-3463-7153 >>D-10589 Berlin, Germany Fax: >>+49-30-3463-8153 >>-------------------------------------------------------------- >>------------------------ >>"Living on earth is expensive but it includes a free trip >>around the sun." (Anonymous) >>-------------------------------------------------------------- >>------------------------ >> >> >> >> >>-- >>Help mailto:majordomo@net.doit.wisc.edu and say "help" >>in message body >>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>"unsubscribe ipfix" in message body >>Archive http://ipfix.doit.wisc.edu/archive/ >> >> > > -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- --------------080602080607000507090303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Carter,

in the new version I already tried to integrate your suggestion into the section.The sentence now is

"Because of the potential uses of IPFIX flow records in accounting and security applications, there are strong incentives to forge exported IPFIX flow records (e.g. to save money or prevent the detection of an attack)."

I think the last part of your suggestion is already covered in:

"In order to make the IPFIX protocol resistant against such attacks this document requires to ensure authenticity and integrity for the IPFIX data transfer."

Do you agree with this wording ?

Regards
Tanja


Carter Bullard wrote:
Hey Tanja,
   I sent a rewriting of a part of the security considerations
section.  This is the section that I suggested.


- Forgery of IPFIX flow records
Because of the potential uses of IPFIX flow records in
applications such as accounting and security, there is a
strong need to provide source authentication and integrity
assurance/protection for IPFIX data.

I believe that it conveys your intention without suggesting
that the accounting application could possibly forge data.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter@qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

-----Original Message-----
From: majordomo listserver 
[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby
Sent: Friday, May 17, 2002 10:46 AM
To: Benoit Claise
Cc: IPFIX Requirements
Subject: [ipfix-req] security considerations


Hi Benoit,

here comes the new security considerations section. I integrated 
comments from Sebastian and Carter.

Regards
Tanja


9. Security considerations

The future IPFIX protocol must be capable to transport data over the 
public Internet. Therefore it cannot be excluded that an attacker 
captures or modifies exchanged packets or inserts additional 
packets. This document describes requirements for IP Flow 
Information Export 
(IPFIX). It therefore also states the required security 
features for a 
future IPFIX protocol. Like other requirements, the security 

requirements differ for the considered applications. The incentive to 
modify collected data for accounting or intrusion detection 
for instance 
is usually higher than the incentive to change data collected for 
traffic profiling. Therefore the required security features in this 
document are listed per application in the appendix.
The suggestion of concrete solutions for achieving the 
required security 
properties will be part of the IPFIX architecture and protocol 
description and is out of scope of this document. 
Furthermore, methods 
for remote configuration of the IPFIX processes are out of scope for 
IPFIX. Therefore, threads that are caused by data exchange for remote 
configuration are not considered here.

The following potential security hazards for an IPFIX protocol can be 
identified:

- Disclosure of IP flow information data
The content of data exchanged by the IPFIX protocol (e.g. IPFIX flow 
rec
ords) should be kept confidential between the involved parties 
(exporting process and colleting process). Observation of IPFIX flow 
records gives an attacker information about the active flows in the 
network, communication endpoints and traffic patterns. This 
information 
cannot only be used to spy out user behavior but also to plan and 
conceal future attacks. Therefore the requirements document 
recommends 
to ensure the confidentiality of the transferred data. This can be 
achieved for instance by encryption.

- Forgery of IPFIX flow records
Because of the potential uses of IPFIX flow records in accounting and 
security applications, there are strong incentives to forge exported 
IPFIX  flow records (e.g. to save money or prevent the 
detection of an 
attack). This can be done either by altering flow records on 
the path or 
by injecting forged flow records that pretend to be originated by the 
original exporting
 process. In order to make the IPFIX protocol 
resistant against such attacks this document requires to ensure 
authenticity and integrity for the IPFIX data transfer.
Special caution is required if security applications rely on 
IPFIX data. 
With forged flow records it is possible to trick on security 
applications. It is for instance possible to pretend that a 
DoS attack 
happens without even launching a real attack.

- Denial of Service (DoS) attacks
DoS attacks on routers or other middleboxes that have the 
IPFIX protocol 
implemented would also affect the IPFIX protocol and impair 
the sending 
of IPFIX records. Nevertheless, since such hazards are not induced 
specifically by the IPFIX protocol the prevention of such 
attacks is out 
of scope of this document.
Nevertheless IPFIX itself also causes potential hazards for 
DoS attacks. 
All processes that expect the reception of traffic can be target of a 

DoS attack. With the IPFIX exporting process this is only the 
case if it 
supports the pull mode (which can be an optional feature of 
the future 
IPFIX protocol according to this document). The collecting process 
always expects data and therefore can be flooded by forged 
flow records.


-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: 
zseby@fokus.fhg.de	
Kaiserin-Augusta-Allee 31				Phone: 
+49-30-3463-7153
D-10589 Berlin, Germany				Fax:   
+49-30-3463-8153
--------------------------------------------------------------
------------------------ 
"Living on earth is expensive but it includes a free trip 
around the sun." (Anonymous)
--------------------------------------------------------------
------------------------




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say 
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/





-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: zseby@fokus.fhg.de	
Kaiserin-Augusta-Allee 31				Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------

--------------080602080607000507090303-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri May 17 11:39:54 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17793 for ; Fri, 17 May 2002 11:39:53 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 178jct-00044v-00 for ipfix-list@mil.doit.wisc.edu; Fri, 17 May 2002 10:26:39 -0500 Received: from pool-151-204-156-167.ny325.east.verizon.net ([151.204.156.167] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 178jcr-00044m-00 for ipfix-req@net.doit.wisc.edu; Fri, 17 May 2002 10:26:37 -0500 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g4HFQbx18783 for ; Fri, 17 May 2002 11:26:37 -0400 Reply-To: From: "Carter Bullard" To: "'IPFIX Requirements'" Subject: FW: [ipfix-req] security considerations Date: Fri, 17 May 2002 11:26:28 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607E489@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Tanja, The English suggests that the accounting and security applications have the incentive to forge exported IPFIX records. You may want to explicitly state who has the incentive to forge, this would clear up the ambiguity. Authentication comes in many flavors, source, receiver, mutual, etc.... authentication. There is no requirement in the charter to provide either receiver or mutual authentication between an IPFIX exporter and its consumer. That is why my suggestion specified source authentication. You may want to consider being this specific. Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby Sent: Friday, May 17, 2002 11:10 AM To: carter@qosient.com Cc: 'Benoit Claise'; 'IPFIX Requirements' Subject: Re: [ipfix-req] security considerations Hi Carter, in the new version I already tried to integrate your suggestion into the section.The sentence now is "Because of the potential uses of IPFIX flow records in accounting and security applications, there are strong incentives to forge exported IPFIX flow records (e.g. to save money or prevent the detection of an attack)." I think the last part of your suggestion is already covered in: "In order to make the IPFIX protocol resistant against such attacks this document requires to ensure authenticity and integrity for the IPFIX data transfer." Do you agree with this wording ? Regards Tanja Carter Bullard wrote: Hey Tanja, I sent a rewriting of a part of the security considerationssection. This is the section that I suggested.- Forgery of IPFIX flow recordsBecause of the potential uses of IPFIX flow records inapplications such as accounting and security, there is astrong need to provide source authentication and integrityassurance/protection for IPFIX data.I believe that it conveys your intention without suggestingthat the accounting application could possibly forge data.CarterCarter BullardQoSient, LLC300 E. 56th Street, Suite 18KNew York, New York 10022carter@qosient.comPhone +1 212 588-9133Fax +1 212 588-9134http://qosient.com -----Original Message-----From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja ZsebySent: Friday, May 17, 2002 10:46 AMTo: Benoit ClaiseCc: IPFIX RequirementsSubject: [ipfix-req] security considerationsHi Benoit,here comes the new security considerations section. I integrated comments from Sebastian and Carter.RegardsTanja9. Security considerationsThe future IPFIX protocol must be capable to transport data over the public Internet. Therefore it cannot be excluded that an attacker captures or modifies exchanged packets or inserts additional packets. This document describes requirements for IP Flow Information Export (IPFIX). It therefore also states the required security features for a future IPFIX protocol. Like other requirements, the security requirements differ for the considered applications. The incentive to modify collected data for accounting or intrusion detection for instance is usually higher than the incentive to change data collected for traffic profiling. Therefore the required security features in this document are listed per application in the appendix.The suggestion of concrete solutions for achieving the required security properties will be part of the IPFIX architecture and protocol description and is out of scope of this document. Furthermore, methods for remote configuration of the IPFIX processes are out of scope for IPFIX. Therefore, threads that are caused by data exchange for remote configuration are not considered here.The following potential security hazards for an IPFIX protocol can be identified:- Disclosure of IP flow information dataThe content of data exchanged by the IPFIX protocol (e.g. IPFIX flow rec ords) should be kept confidential between the involved parties (exporting process and colleting process). Observation of IPFIX flow records gives an attacker information about the active flows in the network, communication endpoints and traffic patterns. This information cannot only be used to spy out user behavior but also to plan and conceal future attacks. Therefore the requirements document recommends to ensure the confidentiality of the transferred data. This can be achieved for instance by encryption.- Forgery of IPFIX flow recordsBecause of the potential uses of IPFIX flow records in accounting and security applications, there are strong incentives to forge exported IPFIX flow records (e.g. to save money or prevent the detection of an attack). This can be done either by altering flow records on the path or by injecting forged flow records that pretend to be originated by the original exporting process. In order to make the IPFIX protocol resistant against such attacks this document requires to ensure authenticity and integrity for the IPFIX data transfer.Special caution is required if security applications rely on IPFIX data. With forged flow records it is possible to trick on security applications. It is for instance possible to pretend that a DoS attack happens without even launching a real attack.- Denial of Service (DoS) attacksDoS attacks on routers or other middleboxes that have the IPFIX protocol implemented would also affect the IPFIX protocol and impair the sending of IPFIX records. Nevertheless, since such hazards are not induced specifically by the IPFIX protocol the prevention of such attacks is out of scope of this document.Nevertheless IPFIX itself also causes potential hazards for DoS attacks. All processes that expect the reception of traffic can be target of a DoS attack. With the IPFIX exporting process this is only the case if it supports the pull mode (which can be an optional feature of the future IPFIX protocol according to this document). The collecting process always expects data and therefore can be flooded by forged flow records.-- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153D-10589 Berlin, Germany Fax: +49-30-3463-8153-------------------------------------------------------- ------------------------------ "Living on earth is expensive but it includes a free trip around the sun." (Anonymous)------------------------------------------------------------- ---------------------------Help mailto:majordomo@net.doit.wisc.edu and say "help" in message bodyUnsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message bodyArchive http://ipfix.doit.wisc.edu/archive/ -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 ------------------------------------------------------------------------ -------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) ------------------------------------------------------------------------ -------------- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue May 21 06:25:30 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02526 for ; Tue, 21 May 2002 06:25:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17A6RH-0003p7-00 for ipfix-list@mil.doit.wisc.edu; Tue, 21 May 2002 05:00:20 -0500 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17A6RF-0003ny-00 for ipfix-req@net.doit.wisc.edu; Tue, 21 May 2002 05:00:17 -0500 Received: from fokus.fhg.de (dhcp176 [195.37.78.176]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g4LA0C004193; Tue, 21 May 2002 12:00:12 +0200 (MEST) Message-ID: <3CEA1A7B.6060802@fokus.fhg.de> Date: Tue, 21 May 2002 11:59:23 +0200 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: carter@qosient.com CC: "'IPFIX Requirements'" , Benoit Claise Subject: Re: FW: [ipfix-req] security considerations References: <5C8959A16A71B449AE793CF52FBBED6607E489@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Carter, here my next try to integrate our text parts: "IPFIX flow records are used in accounting and security applications. This leads to strong incentives for attackers to forge exported IPFIX flow records (e.g. to save money or to prevent the detection of an attack). In order to make the IPFIX protocol resistant against such attacks, source authentication and integrity assurance must be provided for IPFIX data. These requirements are covered in the security requirements section of this document." What do you think ? Regards Tanja Carter Bullard wrote: >Hey Tanja, > The English suggests that the accounting and security applications >have the incentive to forge exported IPFIX records. You may want to >explicitly state who has the incentive to forge, this would clear up the >ambiguity. > > Authentication comes in many flavors, source, receiver, mutual, >etc.... authentication. There is no requirement in the charter to >provide either receiver or mutual authentication between an IPFIX >exporter and its consumer. That is why my suggestion specified source >authentication. You may want to consider being this specific. > >Carter > >Carter Bullard >QoSient, LLC >300 E. 56th Street, Suite 18K >New York, New York 10022 > >carter@qosient.com >Phone +1 212 588-9133 >Fax +1 212 588-9134 >http://qosient.com > > >-----Original Message----- >From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On >Behalf Of Tanja Zseby >Sent: Friday, May 17, 2002 11:10 AM >To: carter@qosient.com >Cc: 'Benoit Claise'; 'IPFIX Requirements' >Subject: Re: [ipfix-req] security considerations > > >Hi Carter, > >in the new version I already tried to integrate your suggestion into the >section.The sentence now is > >"Because of the potential uses of IPFIX flow records in accounting and >security applications, there are strong incentives to forge exported >IPFIX flow records (e.g. to save money or prevent the detection of an >attack)." > >I think the last part of your suggestion is already covered in: > >"In order to make the IPFIX protocol resistant against such attacks this >document requires to ensure authenticity and integrity for the IPFIX >data transfer." > >Do you agree with this wording ? > >Regards >Tanja > > >Carter Bullard wrote: > >Hey Tanja, I sent a rewriting of a part of the security >considerationssection. This is the section that I suggested.- Forgery >of IPFIX flow recordsBecause of the potential uses of IPFIX flow records >inapplications such as accounting and security, there is astrong need to >provide source authentication and integrityassurance/protection for >IPFIX data.I believe that it conveys your intention without >suggestingthat the accounting application could possibly forge >data.CarterCarter BullardQoSient, LLC300 E. 56th Street, Suite 18KNew >York, New York 10022carter@qosient.comPhone +1 212 588-9133Fax +1 212 >588-9134http://qosient.com >-----Original Message-----From: majordomo listserver >[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja ZsebySent: >Friday, May 17, 2002 10:46 AMTo: Benoit ClaiseCc: IPFIX >RequirementsSubject: [ipfix-req] security considerationsHi Benoit,here >comes the new security considerations section. I integrated comments >from Sebastian and Carter.RegardsTanja9. Security considerationsThe >future IPFIX protocol must be capable to transport data over the public >Internet. Therefore it cannot be excluded that an attacker captures or >modifies exchanged packets or inserts additional packets. This document >describes requirements for IP Flow Information Export (IPFIX). It >therefore also states the required security features for a future IPFIX >protocol. Like other requirements, the security >requirements differ for the considered applications. The incentive to >modify collected data for accounting or intrusion detection for instance >is usually higher than the incentive to change data collected for >traffic profiling. Therefore the required security features in this >document are listed per application in the appendix.The suggestion of >concrete solutions for achieving the required security properties will >be part of the IPFIX architecture and protocol description and is out of >scope of this document. Furthermore, methods for remote configuration of >the IPFIX processes are out of scope for IPFIX. Therefore, threads that >are caused by data exchange for remote configuration are not considered >here.The following potential security hazards for an IPFIX protocol can >be identified:- Disclosure of IP flow information dataThe content of >data exchanged by the IPFIX protocol (e.g. IPFIX flow rec >ords) should be kept confidential between the involved parties >(exporting process and colleting process). Observation of IPFIX flow >records gives an attacker information about the active flows in the >network, communication endpoints and traffic patterns. This information >cannot only be used to spy out user behavior but also to plan and >conceal future attacks. Therefore the requirements document recommends >to ensure the confidentiality of the transferred data. This can be >achieved for instance by encryption.- Forgery of IPFIX flow >recordsBecause of the potential uses of IPFIX flow records in accounting >and security applications, there are strong incentives to forge exported >IPFIX flow records (e.g. to save money or prevent the detection of an >attack). This can be done either by altering flow records on the path or >by injecting forged flow records that pretend to be originated by the >original exporting process. In order to make the IPFIX protocol >resistant against such attacks this document requires to ensure >authenticity and integrity for the IPFIX data transfer.Special caution >is required if security applications rely on IPFIX data. With forged >flow records it is possible to trick on security applications. It is for >instance possible to pretend that a DoS attack happens without even >launching a real attack.- Denial of Service (DoS) attacksDoS attacks on >routers or other middleboxes that have the IPFIX protocol implemented >would also affect the IPFIX protocol and impair the sending of IPFIX >records. Nevertheless, since such hazards are not induced specifically >by the IPFIX protocol the prevention of such attacks is out of scope of >this document.Nevertheless IPFIX itself also causes potential hazards >for DoS attacks. All processes that expect the reception of traffic can >be target of a >DoS attack. With the IPFIX exporting process this is only the case if it >supports the pull mode (which can be an optional feature of the future >IPFIX protocol according to this document). The collecting process >always expects data and therefore can be flooded by forged flow >records.-- Dipl.-Ing. Tanja Zseby >FhI FOKUS/Global Networking Email: >zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 >Phone: +49-30-3463-7153D-10589 Berlin, Germany >Fax: >+49-30-3463-8153-------------------------------------------------------- >------------------------------ "Living on earth is expensive but it >includes a free trip around the sun." >(Anonymous)------------------------------------------------------------- >---------------------------Help >mailto:majordomo@net.doit.wisc.edu and say "help" in message >bodyUnsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe >ipfix" in message bodyArchive http://ipfix.doit.wisc.edu/archive/ > > > -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu May 23 13:00:18 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18067 for ; Thu, 23 May 2002 13:00:17 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17AvSq-0006nX-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 May 2002 11:29:20 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112] helo=zrc2s0jx.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17AvSo-0006mz-00 for ipfix@net.doit.wisc.edu; Thu, 23 May 2002 11:29:18 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4NGSw819142; Thu, 23 May 2002 11:28:58 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 09:28:36 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C027BC00D@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: ipfix@net.doit.wisc.edu Cc: kcn@norseth.com, gsadasiv@cisco.com Subject: [ipfix] Comments on IPFIX-architecture draft Date: Thu, 23 May 2002 09:29:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20276.F5A1AC48" Precedence: bulk Sender: majordomo listserver 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. ------_=_NextPart_001_01C20276.F5A1AC48 Content-Type: text/plain Here it goes my comments. Sorry if some of them were already mentioned, but I finally found time to read through this. General: My main problem with this draft as it stands today is that it has a lot of fat that comes from dwelling in certain areas that I do not think it believes in an architecture document. For example, section 4.4.2 and 4.4.3 and the whole notion of match and filter functions is totally an implementation decision that has nothing to do with the ipfix protocol we will select or the definition of a flow (or should not have). The definition of a flow should stick to what is proposed in the beggining of section 3. If I'm going to use the "mother of all rule sets", do it in a stepwise manner (using match or filter functions), or use complex logical constructs has nothing to do with the architecture. Other comments: Section 3 - Typo - Phrase is repeated twice "Each property is defined as the result of applying a function to the values of. Each property is defined as the result of applying a function to the values of:" Section 3 - Wording "Each of the fields from 1., 2. and 3. are referred to as flow keys." Not sure what are these fields you are talking about...Are them the above mentioned list in the text? Section 3 - Wording "Though a flow could match a general application-level end-to-end stream, its definition is not restricted to this alone. The above definition covers a broad range from a flow containing all packets observed on a set of observation points to a flow consisting of just a single packet between two applications with a specific sequence number observed at a single observation point." I think we just remove this whole text without loss of generality or meaning. It seems to me it is repetitive based on the fact that this is already clear given the "flow keys" (1,2 and 3). Section 3. - Document structure. Not sure about putting flow examples in a terminology section...The examples use several terms that are only defined later in the text. I suggest move tall the examples to a new section somewhere after the terminology. Section 3 - Clarification on the match/filter functions on the examples IMO this "match/filter" function mentioned in example 2 does not belong in a architecture draft. This is an implementation internal decision. IMO the only think the architecture document should say is that Section 3 - Typo "Each of the field which belongs to" s/field/fields Section 3 - Terminology " * Flow Type: A function F which would take input as a set of flow keys and the output would be one or more flows depending on the combination of values for the set of flow keys." A set of "common properties", which the real world instantion would be the so-called fields already defines a flow. As mentioned in the beggining of secion 3 "All packets belonging to a particular flow have a set of common properties" So, the notion of flow type seems redundant. If its purposes in life is to justify the other text in the draft which talks about match/filter, is one more reason to remove this definition. Section 4 - Clarification In general I think dwelling in the internal of a device in a IETF architecture document is not a good practice, but that's MHO. At least in the "typical ipfix device" picture the functional boxes of the "selection criteria for flow export" and "metering process" should be removed. It is not a process that talks to external entities (a.k.a IETF Ipfix's protocol) and neither has anything to do with defining a flow. Anyway, my opinion is that we only need the first picture in section 4. Everything else is perfectly described in the text (section 4.1 onwards). Section 4.3 - Wording "The typical functions of an Observation Domain may include:" and then " * May perform appropriate middle-box functions to translate the flow information." There is already a "may" on the first phrase Section 4.4.1 - Typo " MAY need the following interpreting the flow records further:" suggestion "May need the following information to interpret the flow records further" Section 4.4.2. - Remove IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se. Section 4.4.3. - Remove IMO this section has no bearing in a architecture draft. It is completely an implementation decision that not even affect the IPfix protocol per se. Section 5.2.1 - Conflicting terms " As mentioned in the selection criteria, the control and data stream MUST be transported over a congestion-aware transport protocol" In the selection criteria, ability to use a congestion-aware protocol is a SHOULD. Quote follows from section 5.1: " The following is the list of criteria that the candidate protocol SHOULD meet in order to be the..." Section 5.2.1 - Redundancy and possible conflict of terms " The data stream MAY be exported over an reliable or unreliable transport protocol." In section 5.1 congestion-aware is SHOULD, later is MUST and now (section 5.2.1) is MAY. I suggest removing this phrase. Everything related to which protocol must be used as a transport is already discussed on the beggining of this section. regards, Reinaldo ------_=_NextPart_001_01C20276.F5A1AC48 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Comments on IPFIX-architecture draft

Here it goes my comments. Sorry if some of them were = already mentioned, but I finally found time to read through = this.

General:

My main problem with this draft as it stands today is = that it has a lot of fat that comes from dwelling in certain areas that = I do not think it believes in an architecture document. For example, = section 4.4.2 and 4.4.3 and the whole notion of match and filter = functions is totally an implementation decision that has nothing to do = with the ipfix protocol we will select or the definition of a flow (or = should not have).

The definition of a flow should stick to what is = proposed in the beggining of section 3. If I'm going to use the = "mother of all rule sets", do it in a stepwise manner (using = match or filter functions), or use complex logical constructs has = nothing to do with the architecture.

Other comments:


Section 3 - Typo - Phrase is repeated twice

"Each property is defined as the result of = applying a function to the values of.
Each property is defined as the result of applying a = function to the values of:"

Section 3 - Wording

"Each of the fields from 1., 2.
       and 3. are = referred to as flow keys."

Not sure what are these fields you are talking = about...Are them the above mentioned list in the text?


Section 3 - Wording

"Though a flow could match a
       general = application-level end-to-end stream, its definition is
       not restricted = to this alone. The above definition covers a broad
       range from a = flow containing all packets observed on a set of
       observation = points to a flow consisting of just a single packet
       between two = applications with a specific sequence number observed
       at a single = observation point."

I think we just remove this whole text without loss = of generality or meaning. It seems to me it is repetitive based on the = fact that this is already clear given the "flow keys" (1,2 = and 3).

Section 3. - Document structure.

Not sure about putting flow examples in a terminology = section...The examples use several terms that are only defined later in = the text. I suggest move tall the examples to a new section somewhere = after the terminology.

Section 3 - Clarification on the match/filter = functions on the examples

IMO this "match/filter" function mentioned = in example 2 does not belong in a architecture draft. This is an = implementation internal decision. IMO the only think the architecture = document should say is that 

Section 3 - Typo

"Each of the field which belongs to"

s/field/fields

Section 3 - Terminology

"   * Flow Type:
       A function F = which would take input as a set of flow keys and the
       output would be = one or more flows depending on the combination of
       values for the = set of flow keys."

A set of "common properties", which the = real world instantion would be the so-called fields already defines a = flow. As mentioned in the beggining of secion 3

"All packets belonging to
       a particular = flow have a set of common properties"

So, the notion of flow type seems redundant. If its = purposes in life is to justify the other text in the draft which talks = about match/filter, is one more reason to remove this definition. =

Section 4 - Clarification

In general I think dwelling in the internal of a = device in a IETF architecture document is not a good practice, but = that's MHO. At least in the "typical ipfix device" picture = the functional boxes of the "selection criteria for flow = export" and "metering process" should be removed.  = It is not a process that talks to external entities (a.k.a IETF Ipfix's = protocol) and neither has anything to do with defining a = flow.

Anyway, my opinion is that we only need the first = picture in section 4. Everything else is perfectly described in the = text (section 4.1 onwards).

Section 4.3 - Wording

"The typical functions of
   an Observation Domain may = include:"

and then

"    * May perform appropriate = middle-box functions to translate the
       flow = information."

There is already a "may" on the first = phrase

Section 4.4.1 - Typo

" MAY need the
   following interpreting the flow records = further:"

suggestion

"May need the following information to interpret = the flow records further"



Section 4.4.2. - Remove

IMO this section has no bearing in a architecture = draft. It is completely an implementation decision that not even affect = the IPfix protocol per se.

Section 4.4.3. - Remove

IMO this section has no bearing in a architecture = draft. It is completely an implementation decision that not even affect = the IPfix protocol per se.

Section 5.2.1 - Conflicting terms

"   As mentioned in the selection = criteria, the control and data stream
   MUST be transported over a = congestion-aware transport protocol"

In the selection criteria, ability to use a = congestion-aware protocol is a SHOULD. Quote follows from section = 5.1:

"   The following is the list of = criteria that the candidate protocol
   SHOULD meet in order to be = the..."

Section 5.2.1 - Redundancy and possible conflict of = terms

"   The data stream MAY be exported = over an reliable or unreliable
   transport protocol."

In section 5.1 congestion-aware is SHOULD, later is = MUST and now (section 5.2.1) is MAY. I suggest removing this phrase. = Everything related to which protocol must be used as a transport is = already discussed on the beggining of this section.

regards,

Reinaldo






------_=_NextPart_001_01C20276.F5A1AC48-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu May 23 15:30:06 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23829 for ; Thu, 23 May 2002 15:30:06 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17Axms-00027k-00 for ipfix-list@mil.doit.wisc.edu; Thu, 23 May 2002 13:58:10 -0500 Received: from rip.psg.com ([147.28.0.39]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17Axmq-00027c-00 for ipfix@net.doit.wisc.edu; Thu, 23 May 2002 13:58:08 -0500 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17Axmm-0002ju-00; Thu, 23 May 2002 11:58:04 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Reinaldo Penno" Cc: ipfix@net.doit.wisc.edu, kcn@norseth.com, gsadasiv@cisco.com Subject: Re: [ipfix] Comments on IPFIX-architecture draft References: <7B802811BE77D51189910002A55CFD2C027BC00D@zsc3c032.us.nortel.com> Message-Id: Date: Thu, 23 May 2002 11:58:04 -0700 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > My main problem with this draft as it stands today is that it has > a lot of fat that comes from dwelling in certain areas that I do > not think it believes in an architecture document. For example, > section 4.4.2 and 4.4.3 and the whole notion of match and filter > functions is totally an implementation decision that has nothing > to do with the ipfix protocol we will select or the definition of > a flow (or should not have). i don't understand more than you don't understand. perhaps i am confused by taking the wg's charter seriously. Deliverables Best Current Practice: IETF Recommendations for the Emergency Telecommunications Service using existing protocols - what can be done with existing protcols and what can not be done. Informationals: Requirements for Internet Emergency Preparedness in the Internet. Framework for Supporting Internet Emergency Preparedness in IP Telephony. randy -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri May 24 13:11:16 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05810 for ; Fri, 24 May 2002 13:11:16 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17BICp-00070H-00 for ipfix-list@mil.doit.wisc.edu; Fri, 24 May 2002 11:46:19 -0500 Received: from pool-151-204-154-53.ny325.east.verizon.net ([151.204.154.53] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17BICl-000709-00 for ipfix-req@net.doit.wisc.edu; Fri, 24 May 2002 11:46:15 -0500 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g4OGk1x15861; Fri, 24 May 2002 12:46:01 -0400 Reply-To: From: "Carter Bullard" To: "'Tanja Zseby'" Cc: "'IPFIX Requirements'" , "'Benoit Claise'" Subject: RE: FW: [ipfix-req] security considerations Date: Fri, 24 May 2002 12:45:52 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607E4AB@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED66076D50@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Tanja, That's great! Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby > Sent: Tuesday, May 21, 2002 5:59 AM > To: carter@qosient.com > Cc: 'IPFIX Requirements'; Benoit Claise > Subject: Re: FW: [ipfix-req] security considerations > > > Hi Carter, > > here my next try to integrate our text parts: > > "IPFIX flow records are used in accounting and security > applications. This leads to strong incentives for attackers > to forge exported IPFIX flow records (e.g. to save money or > to prevent the detection of an attack). In order to make the > IPFIX protocol resistant against such attacks, source > authentication and integrity assurance must be provided for > IPFIX data. These requirements are covered in the security > requirements section of this document." > > What do you think ? > > Regards > Tanja > > > Carter Bullard wrote: > > >Hey Tanja, > > The English suggests that the accounting and security > applications > >have the incentive to forge exported IPFIX records. You may want to > >explicitly state who has the incentive to forge, this would clear up > >the ambiguity. > > > > Authentication comes in many flavors, source, receiver, mutual, > >etc.... authentication. There is no requirement in the charter to > >provide either receiver or mutual authentication between an IPFIX > >exporter and its consumer. That is why my suggestion > specified source > >authentication. You may want to consider being this specific. > > > >Carter > > > >Carter Bullard > >QoSient, LLC > >300 E. 56th Street, Suite 18K > >New York, New York 10022 > > > >carter@qosient.com > >Phone +1 212 588-9133 > >Fax +1 212 588-9134 > >http://qosient.com > > > > > >-----Original Message----- > >From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On > >Behalf Of Tanja Zseby > >Sent: Friday, May 17, 2002 11:10 AM > >To: carter@qosient.com > >Cc: 'Benoit Claise'; 'IPFIX Requirements' > >Subject: Re: [ipfix-req] security considerations > > > > > >Hi Carter, > > > >in the new version I already tried to integrate your suggestion into > >the section.The sentence now is > > > >"Because of the potential uses of IPFIX flow records in > accounting and > >security applications, there are strong incentives to forge exported > >IPFIX flow records (e.g. to save money or prevent the > detection of an > >attack)." > > > >I think the last part of your suggestion is already covered in: > > > >"In order to make the IPFIX protocol resistant against such attacks > >this document requires to ensure authenticity and integrity for the > >IPFIX data transfer." > > > >Do you agree with this wording ? > > > >Regards > >Tanja > > > > > >Carter Bullard wrote: > > > >Hey Tanja, I sent a rewriting of a part of the security > >considerationssection. This is the section that I > suggested.- Forgery > >of IPFIX flow recordsBecause of the potential uses of IPFIX flow > >records inapplications such as accounting and security, there is > >astrong need to provide source authentication and > >integrityassurance/protection for IPFIX data.I believe that > it conveys > >your intention without suggestingthat the accounting > application could > >possibly forge data.CarterCarter BullardQoSient, LLC300 E. > 56th Street, Suite 18KNew > >York, New York 10022carter@qosient.comPhone +1 212 > 588-9133Fax +1 212 > >588-9134http://qosient.com > >-----Original Message-----From: majordomo listserver > >[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja ZsebySent: > >Friday, May 17, 2002 10:46 AMTo: Benoit ClaiseCc: IPFIX > >RequirementsSubject: [ipfix-req] security considerationsHi > Benoit,here > >comes the new security considerations section. I integrated comments > >from Sebastian and Carter.RegardsTanja9. Security considerationsThe > >future IPFIX protocol must be capable to transport data over > the public > >Internet. Therefore it cannot be excluded that an attacker > captures or > >modifies exchanged packets or inserts additional packets. > This document > >describes requirements for IP Flow Information Export (IPFIX). It > >therefore also states the required security features for a > future IPFIX > >protocol. Like other requirements, the security requirements > differ for > >the considered applications. The incentive to modify > collected data for > >accounting or intrusion detection for instance is usually > higher than > >the incentive to change data collected for traffic > profiling. Therefore > >the required security features in this document are listed per > >application in the appendix.The suggestion of concrete solutions for > >achieving the required security properties will be part of the IPFIX > >architecture and protocol description and is out of scope of this > >document. Furthermore, methods for remote configuration of the IPFIX > >processes are out of scope for IPFIX. Therefore, threads that are > >caused by data exchange for remote configuration are not considered > >here.The following potential security hazards for an IPFIX > protocol can > >be identified:- Disclosure of IP flow information dataThe content of > >data exchanged by the IPFIX protocol (e.g. IPFIX flow rec > >ords) should be kept confidential between the involved parties > >(exporting process and colleting process). Observation of IPFIX flow > >records gives an attacker information about the active flows in the > >network, communication endpoints and traffic patterns. This > information > >cannot only be used to spy out user behavior but also to plan and > >conceal future attacks. Therefore the requirements document > recommends > >to ensure the confidentiality of the transferred data. This can be > >achieved for instance by encryption.- Forgery of IPFIX flow > >recordsBecause of the potential uses of IPFIX flow records in > >accounting and security applications, there are strong incentives to > >forge exported IPFIX flow records (e.g. to save money or > prevent the > >detection of an attack). This can be done either by altering flow > >records on the path or by injecting forged flow records that > pretend to > >be originated by the original exporting process. In order > to make the > >IPFIX protocol resistant against such attacks this document > requires to > >ensure authenticity and integrity for the IPFIX data > transfer.Special > >caution is required if security applications rely on IPFIX > data. With > >forged flow records it is possible to trick on security > applications. > >It is for instance possible to pretend that a DoS attack happens > >without even launching a real attack.- Denial of Service (DoS) > >attacksDoS attacks on routers or other middleboxes that have > the IPFIX > >protocol implemented would also affect the IPFIX protocol and impair > >the sending of IPFIX records. Nevertheless, since such > hazards are not > >induced specifically by the IPFIX protocol the prevention of such > >attacks is out of scope of this document.Nevertheless IPFIX > itself also > >causes potential hazards for DoS attacks. All processes that > expect the > >reception of traffic can be target of a DoS attack. With the IPFIX > >exporting process this is only the case if it supports the pull mode > >(which can be an optional feature of the future IPFIX protocol > >according to this document). The collecting process always > expects data > >and therefore can be flooded by forged flow > >records.-- Dipl.-Ing. Tanja Zseby > >FhI FOKUS/Global Networking Email: > >zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 > >Phone: +49-30-3463-7153D-10589 Berlin, Germany > >Fax: > >+49-30-3463-8153--------------------------------------------- > ---------- > >+- > >------------------------------ "Living on earth is expensive but it > >includes a free trip around the sun." > >(Anonymous)-------------------------------------------------- > ---------- > >- > >---------------------------Help > >mailto:majordomo@net.doit.wisc.edu and say "help" in message > >bodyUnsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe > >ipfix" in message bodyArchive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > -- > Dipl.-Ing. Tanja Zseby > FhI FOKUS/Global Networking Email: > zseby@fokus.fhg.de > Kaiserin-Augusta-Allee 31 Phone: > +49-30-3463-7153 > D-10589 Berlin, Germany Fax: > +49-30-3463-8153 > -------------------------------------------------------------- > ------------------------ > "Living on earth is expensive but it includes a free trip > around the sun." (Anonymous) > -------------------------------------------------------------- > ------------------------ > > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri May 31 00:55:04 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27474 for ; Fri, 31 May 2002 00:55:04 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17DdqN-0006Sy-00 for ipfix-list@mil.doit.wisc.edu; Thu, 30 May 2002 23:16:51 -0500 Received: from h005.c001.snv.cp.net ([209.228.32.119] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 17DdqL-0006Sg-00 for ipfix@net.doit.wisc.edu; Thu, 30 May 2002 23:16:49 -0500 Received: (cpmta 4470 invoked from network); 30 May 2002 21:16:18 -0700 Received: from 24.221.253.53 (HELO kcn) by smtp.register-admin.com (209.228.32.119) with SMTP; 30 May 2002 21:16:18 -0700 X-Sent: 31 May 2002 04:16:18 GMT Message-ID: <022301c2085a$01f66900$850f880a@kcn> From: "K.C. Norseth" To: "IPFIX" Subject: [ipfix] draft-ietf-ipfix-data-01.txt Date: Thu, 30 May 2002 22:16:58 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello people, Sorry for the delay on this, but here is an update. I want to get a discussion on it before I submit it. http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-01.txt Thanks Greg Ruth for his help on this version. K.C. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri May 31 17:27:36 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05239 for ; Fri, 31 May 2002 17:27:36 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17DtS9-0001g6-00 for ipfix-list@mil.doit.wisc.edu; Fri, 31 May 2002 15:56:53 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112] helo=zrc2s0jx.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17DtS8-0001fF-00 for ipfix@net.doit.wisc.edu; Fri, 31 May 2002 15:56:52 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4VKuWZ01152; Fri, 31 May 2002 15:56:33 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 13:56:16 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C029270B3@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: "K.C. Norseth" , IPFIX Subject: RE: [ipfix] draft-ietf-ipfix-data-01.txt Date: Fri, 31 May 2002 13:56:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C208E5.9C2A2198" Precedence: bulk Sender: majordomo listserver 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. ------_=_NextPart_001_01C208E5.9C2A2198 Content-Type: text/plain; charset="iso-8859-1" Hello KC, I just quickly browsed through it and It seems the changed very little from the previous version. Moreover I (and also others) suggested a great deal of text to the data doc that is not there. Not to mention you can still find some terms like CCE through the text. And again there is a looott of fat and things not related to the charter. IMHO you rip of section 4 and 5 completely. cheers, Reinaldo >-----Original Message----- >From: K.C. Norseth [mailto:kcn@norseth.com] >Sent: Thursday, May 30, 2002 9:17 PM >To: IPFIX >Subject: [ipfix] draft-ietf-ipfix-data-01.txt > > >Hello people, > >Sorry for the delay on this, but here is an update. I want to get a >discussion on it before I submit it. > >http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-01.txt > >Thanks Greg Ruth for his help on this version. > >K.C. > > >-- >Help mailto:majordomo@net.doit.wisc.edu and say "help" >in message body >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >"unsubscribe ipfix" in message body >Archive http://ipfix.doit.wisc.edu/archive/ > ------_=_NextPart_001_01C208E5.9C2A2198 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] draft-ietf-ipfix-data-01.txt

Hello KC,

I just quickly browsed through it and It seems the = changed very little from the previous version. Moreover I (and also = others) suggested a great deal of text to the data doc that is not = there.  Not to mention you can still find some terms like CCE = through the text.

And again there is a looott of fat and things not = related to the charter. IMHO you rip of section 4 and 5 completely. =

cheers,

Reinaldo




>-----Original Message-----
>From: K.C. Norseth [mailto:kcn@norseth.com]
>Sent: Thursday, May 30, 2002 9:17 PM
>To: IPFIX
>Subject: [ipfix] = draft-ietf-ipfix-data-01.txt
>
>
>Hello people,
>
>Sorry for the delay on this, but here is an = update.  I want to get a
>discussion on it before I submit it.
>
>http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-01= .txt
>
>Thanks Greg Ruth for his help on this = version.
>
>K.C.
>
>
>--
>Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
>in message body
>Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>"unsubscribe ipfix" in message = body
>Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C208E5.9C2A2198-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/