From majordomo@mil.doit.wisc.edu Tue Jul 1 11:59:41 2003 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 LAA05496 for ; Tue, 1 Jul 2003 11:59:40 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19XN4M-0000kC-00 for ipfix-list@mil.doit.wisc.edu; Tue, 01 Jul 2003 10:29:22 -0500 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19XN4L-0000k7-00 for ipfix-reqs@net.doit.wisc.edu; Tue, 01 Jul 2003 10:29:21 -0500 Received: from Givoly ([192.168.0.3]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h61FarL01487; Tue, 1 Jul 2003 08:36:53 -0700 From: "Tal Givoly" To: "MEYER,JEFFREY D \(HP-Cupertino,ex1\)" , "Simon Leinen" , Subject: RE: [ipfix-reqs] Indicating Anonymization Date: Tue, 1 Jul 2003 08:29:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960122@xsun01.ptp.hp.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff, Unless rationale and proper definition of the anonymization requirement are clearly restated, I believe that any anonymization should be done at the collector. This would solve many issues with the current approach and would also support the correlation to actual user sessions. This may also make it become out of scope of the IPFIX requirements as they do not currently pertain to the output format/transport/protocol of the collector. Tal -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of MEYER,JEFFREY D (HP-Cupertino,ex1) Sent: Monday, June 30, 2003 7:31 PM To: 'Tal Givoly'; MEYER,JEFFREY D (HP-Cupertino,ex1); Simon Leinen; ipfix-reqs@net.doit.wisc.edu Subject: RE: [ipfix-reqs] Indicating Anonymization Tal, Reversability of the XOR pattern if you have a known address which can be identified by its flow behavior does sound like a pretty simple attack. I won't defend it, but would be curious in effective alternatives. I'm not a cryptographer... Assuming such a mechanism is defined, I'd still suggest it be carried as a unique flow attribute, and I believe that providing for anonymizing only a user addresses and not server addresses would prove more useful. Alternatively, data can effectively be anonymized once aggregated at the collector. In other words, reports saying that some number of unique addresses showed some behavior or had some quality in common provides information of interest, but does not divulge individual identities. Perhaps this is a more reasonable approach... -- Jeff > -----Original Message----- > From: Tal Givoly [mailto:givoly@xacct.com] > Sent: Monday, June 30, 2003 3:12 PM > To: MEYER,JEFFREY D (HP-Cupertino,ex1); Simon Leinen; > ipfix-reqs@net.doit.wisc.edu > Subject: RE: [ipfix-reqs] Indicating Anonymization > > > Jeff, > > That, indeed, was the main point I was trying to make. > > I'll explain why it seems that the anonymization algorithm > you suggest is > too simple - if someone can come up with an effective alternative, the > requirement may have some more merit than it has now. > > Why is XOR with a random number too simple a function if one wants to > anonymize traffic? > > If the same 32-bit field is XORed for all instances of the > same IP address, > then it would be very simple to identify that pattern. For > instance, traffic > flowing to or from port 53 would be DNS traffic. It would be > very easy to > figure out which are these DNS servers, as there aren't that > many associated > with an organization. Same thing for SMTP/POP3 servers and > any other server > with well-known ports. So, basically, it wouldn't be > difficult to identify > the constant with which all IP addresses are XORed. > > This may have lead people to think about anonymization of > other fields, such > as port numbers... I believe that that too is a futile effort > if it is just > a fixed XOR pattern. Not many protocols have the same > source/destination > port - the ones that do stand out in the crowd. DNS is one of > them. Most DNS > traffic between servers shares port 53 for both client and > server. So once > you identify the few protocols that identify this pattern and > solve a few > simple equations, you know the mask that was applied. > > Getting back to the bigger picture - can anybody whom > contributed to the > original requirements provide some rationale and perhaps even > propose at > least one transformation function that servers the purpose? > > Tal > > -----Original Message----- > From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] > Sent: Monday, June 30, 2003 12:19 PM > To: 'Tal Givoly'; Simon Leinen; ipfix-reqs@net.doit.wisc.edu > Subject: RE: [ipfix-reqs] Indicating Anonymization > > > Tal, > > I think your last statement sums it up: "Is the > anonymization requirement > well defined?" > > In general, if the requirement is to prevent data which is > considered > private being used by anyone, then I think the policy would > take place at > the IPFIX Observer level itself. In this case any correlation is > meaningless, and runs counter to the expectation of privacty. > > One particular technique could be the use of a 32-bit random number > calculated by the observer each time it starts, and not > available to an > external system. This value could then simply be XOR'd with > the actual IP > address. This would provide a one way anonymization and > guarantee that the > same IP address is always given the same id over the period > the exporter is > up. > > I think one complicating factor is that you may want the IP > address of > users anonymized, but NOT the IP address of servers on the > Internet. What > it means to configure anonymization behavior is probably an > area of further > exploration. > > I'm unclear on why anonymizing ports is interesting. > > I'd prefer to see a separate Flow Attribute in the > Information Model to > effectively inform any downstream consumer of the fact that > what is being > delivered is NOT the IP address of the actual system, but > some scrambled > value. Semantically, this is a different piece of > information, i.e. it is a > unique, but non-correlateable identifier. > > Regards, > > Jeff Meyer > > > -----Original Message----- > > From: Tal Givoly [mailto:givoly@xacct.com] > > Sent: Sunday, June 29, 2003 3:52 PM > > To: Simon Leinen; ipfix-reqs@net.doit.wisc.edu > > Subject: RE: [ipfix-reqs] Indicating Anonymization > > > > > > Simon, > > > > It may be that that anonymization is perhaps even more > > complex than this. > > > > I assume that the original intent was that even without any form of > > encryption, the legitimate collector, or any party > > eavesdropping on the > > communication, would not be able to correlate individual > > user's usage back > > to that user. However, any form of anonymization that is a > > 1-to-1 function > > of the original address space, and is completely specified, > > implies that > > anybody could go back and discover the true identity of the > > "anonymized" > > user. This would clearly be the case if one knows the > > function applied to > > anonymize the address, and it is a 1-to-1 function (because > you may be > > using, for instance, a 32-bit field to represent the "anonymized" IP > > address). One would know the function, if as you suggest, > the function > > itself is completely specified. > > > > Why should it be a 1-to-1 function, you may ask? Well, it is > > important that > > the collector still be able to distinguish the identity of > > the individual > > user sessions - although not necessarily the user itself. But > > it shouldn't > > get mixed with other sessions. > > > > Why should you use the same field type for the anonymized > > values? Well, > > that's not mandatory - but it would make it possible for some > > tools that are > > designed for operating on IP addresses, for instance, to operate on > > "anonymized" IP addresses. This is not mandatory, but may be useful. > > > > Now, anonymization at the device level does introduce another > > problem - any > > system downstream from the collector may not be able to > > correlate back to > > individual user session. Supposing, for instance, IP addresses are > > dynamically assigned via DHCP or RADIUS (depending on access > > technology) - > > then another source of information will actually have the > > user's identity > > (be it MAC address for DHCP or user name/realm for RADIUS). > > It will also be > > the source that allows for distinguishing two users sessions > > sharing the > > same IP but at different times (from 9-10 user1 used IP1 > > while the same IP1 > > was used between 10:05 and 11 by user2). So any anonymization > > in the device > > would prevent downstream systems from recognizing that > > different records > > represent different users traffic altogether. > > > > This raises the questions: > > - Is anonymization requirement well-defined? > > - Is it even an important requirement for IPFIX? > > > > I don't recall that there was much discussion ever about this > > requirement. > > Wouldn't encryption of the links to avoid eavesdropping serve > > most of the > > intended purpose? Why do we require the devices to support this? > > > > Tal > > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > > Of Simon Leinen > > Sent: Sunday, June 29, 2003 1:40 PM > > To: ipfix-reqs@net.doit.wisc.edu > > Subject: [ipfix-reqs] Indicating Anonymization > > > > > > While updating my protocol evaluation I-D, I found the requirements > > I-D section on anonymization somewhat problematic. I apologize > > bringing this up so late in the process. > > > > The current revision (-10) has the following to say about > > anonymization: > > > > 6.7. Anonymization > > > > The exporting process MAY be capable of anonymizing source and > > destination IP addresses in flow data before exporting them. It > > MAY support anonymization of port numbers and other > > fields. Please note that anonymization is not originally an > > application requirement, but derived from general requirements > > for treatment of measured traffic data within a network. > > > > When anonymized flow data is exported, this MUST be clearly > > indicated to all receiving collecting processes, such that they > > can distinguish anonymized data from non-anonymized data. > > > > Note that there is no single generally accepted method for > anonymizing > > flow export data (or even individual fields such as an IP address), > > and different situations may require different levels of > > anonymization. > > > > Because of this, I think that it is not sufficient that the > collector > > be able to "distinguish anonymized data from non-anonymized > data", but > > it must also know the method and "degree" of anonymization. This is > > similar to sampling, where it is not sufficient to know > whether there > > is sampling going on or not, but one is also interested in sampling > > parameters such as sampling method (e.g. pseudo-random, > > packet/byte/time/flow-based) and parameters (e.g. sampling > interval). > > > > On the other hand, whether and how anonymization is > performed will be > > purely a matter of configuration of the exporting device, > and will not > > change during normal operation. This is in contrast to sampling, > > where the parameters may change to adapt to the offered > load. So one > > could argue that it's not even necessary to report anonymization, > > because of the general assumption that the collector can know the > > static configuration of the exporting device by some other means. > > > > If we agree that collectors can obtain the necessary knowledge about > > the configuration of anonymization by other means, then I > suggest the > > following replacement text. This is blatantly stolen from > the current > > text about sampling: > > > > 6.7. Anonymization > > > > The metering process MAY be capable of anonymizing source and > > destination IP addresses in flow data before exporting them. It > > MAY support anonymization of port numbers and other > > fields. Please note that anonymization is not originally an > > application requirement, but derived from general requirements > > for treatment of measured traffic data within a network. > > > > If anonymization is supported, the anonymization configuration > > MUST be well defined. The anonymization configuration includes > > the anonymization method and all its parameters. > > > > However, if we really think that the anonymization > configuration must > > be conveyed to the collector through the IPFIX protocol, I would > > suggest the following wording (also stolen from the text on > sampling, > > but from the part on what happens when the sampling configuration > > changes during operation): > > > > 6.7. Anonymization > > > > The metering process MAY be capable of anonymizing source and > > destination IP addresses in flow data before exporting them. It > > MAY support anonymization of port numbers and other > > fields. Please note that anonymization is not originally an > > application requirement, but derived from general requirements > > for treatment of measured traffic data within a network. > > > > If anonymization is supported, the anonymization configuration > > MUST be indicated to the collector. The anonymization > > configuration includes the anonymization method and all its > > parameters. > > -- > > Simon. > > > > -- > > 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 Thu Jul 3 02:14:45 2003 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 CAA28981 for ; Thu, 3 Jul 2003 02:14:45 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19Xwxj-0002Kt-00 for ipfix-list@mil.doit.wisc.edu; Thu, 03 Jul 2003 00:48:55 -0500 Received: from smtp-out.sprintlabs.com ([208.30.172.76]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19Xwxi-0002Ko-00 for ipfix@net.doit.wisc.edu; Thu, 03 Jul 2003 00:48:54 -0500 Received: from mailman.sprintlabs.com (mx.sprintlabs.com [199.2.53.192]) by smtp-out.sprintlabs.com (Postfix) with ESMTP id 46112B8102; Wed, 2 Jul 2003 22:49:36 -0700 (PDT) Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2656.59) id ; Wed, 2 Jul 2003 22:48:53 -0700 Message-ID: <49D9473417F1234C9C86886EE8353FAAEFF693@mailman.sprintlabs.com> From: Gianluca Iannaccone To: "'ispmon@ops.ietf.org'" Cc: "'ippm@ietf.org'" , "'ipfix@net.doit.wisc.edu'" , "'psamp@ops.ietf.org'" , "'idwg-public@zurich.ibm.com'" , "'inch@nic.surfnet.nl'" Subject: [ipfix] ispmon BOF Date: Wed, 2 Jul 2003 22:48:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Precedence: bulk Sender: majordomo listserver [apologies if you receive multiple copies of this email] please find attached the agenda and description of the new BOF on Monitoring Infrastructure Deployment. thanks, gianluca ---------------------------------------------------------- Monitoring Infrastructure Deployment BOF (ispmon) Thursday, July 17 at 1530-1730 =============================== CHAIR: Gianluca Iannaccone AGENDA 5 min - Agenda Bashing 15 min - Presentation: draft-bhattacharyya-monitoring-deployment-00 10 min - Presentation: Sprint's Continuous Monitoring (CMON) project 15 min - Scope and candidate charter for Working group 15 min - Next steps MAILING LIST General Discussion: ispmon@ops.ietf.org To Subscribe: ispmon-request@ops.ietf.org, "subscribe" in body Archive: http://opt.ietf.org/lists/ispmon DESCRIPTION Various types of measurement data need to be collected to support monitoring applications. We classified them in two broad categories: (i) aggregate information that need to be collected at coarse time-scales and reported on a regular basis (e.g. SNMP, flows, routing tables) ; (ii) packet-level traces to analyze and understand a specific phenomenon. There are a number of implementation challenges in order to capture, process, summarize and export data at the required level of granularity at the time that it is needed. Some of these problems are being addressed in different IETF working groups whereas some others have not been. The goal of this BOF is to discuss whether a new working group is needed to undertake the following activities: (i) define a framework for monitoring needed to support day-to-day operations in IP networks, (ii) identify existing and on-going efforts in the IETF on various aspects of the framework and ensure that this work guarantees inter-operability among ISPs, and (iii) provide clear guidelines to equipment vendors on what infrastructure is needed to support monitoring in ISP networks. A charter for the new working group could address (but not be limited to) the following aspects: . provide BCP documents on how to instrument monitoring systems in large-scale provider networks. . describe known-to-work implementations and identify open issues. . specify components of an operational monitoring infrastructure in particular regarding aspects not addressed in other IETF WGs (e.g., storage, aging and analysis of collected data, control plane functionality). . specify ways for ISPs to share monitoring data. . make recommendations to other working groups standardizing different elements of monitoring, e.g., IPPM, IPFIX and PSAMP, INCH, IDWG, etc., READING LIST . draft-bhattacharyya-monitoring-deployment-00.txt . draft-bhattacharyya-monitoring-sprint-01.txt . draft-ietf-ipfix-reqs-10.txt . draft-ietf-psamp-framework-03.txt . draft-ietf-idwg-requirements-10.txt . draft-ietf-inch-iodef-01.txt . RFC2330: Framework for IP Performance Metrics RELATED WGs IP Flow Information Export (ipfix) http://www.ietf.org/html.charters/ipfix-charter.html Packet Sampling (psamp) http://www.ietf.org/html.charters/psamp-charter.html IP Performance Metrics (ippm) http://www.ietf.org/html.charters/ippm-charter.html Intrusion Detection Exchange Format (idwg) http://www.ietf.org/html.charters/idwg-charter.html Extended Incident Handling (inch) http://www.ietf.org/html.charters/inch-charter.html ---------------------------------------------------------- Gianluca Iannaccone ' gianluca@sprintlabs.com Sprint ATL ' tel +1 (650) 375-4198 1 Adrian Court ' fax +1 (650) 375-4079 Burlingame, CA 94010 ' www.sprintlabs.com/~gianluca -- 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 Jul 7 19:33:22 2003 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 TAA21526 for ; Mon, 7 Jul 2003 19:33:22 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19ZfA5-0005Ri-00 for ipfix-list@mil.doit.wisc.edu; Mon, 07 Jul 2003 18:12:45 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19ZfA4-0005RZ-00 for ipfix@net.doit.wisc.edu; Mon, 07 Jul 2003 18:12:44 -0500 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h67NCg8Y018325 for ; Tue, 8 Jul 2003 11:12:42 +1200 (NZST) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR) with ESMTP id ARX09935; Tue, 8 Jul 2003 11:12:41 +1200 (NZST) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h67NCaw31680 for ipfix@net.doit.wisc.edu; Tue, 8 Jul 2003 11:12:36 +1200 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Tue, 8 Jul 2003 11:12:36 +1200 Message-ID: <1057619556.6c9042df254fa@hotlava.auckland.ac.nz> Date: Tue, 8 Jul 2003 11:12:36 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Fwd: text conferencing at ietf57 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.167 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit OK, Marshall has got text messaging organised for Vienna. Anyone (who'll be there) care to volunteer to be our 'scribe?' Cheers, Nevil ----- Forwarded message from mrose+mtr.ietf@dbc.mtview.ca.us ----- Date: Mon, 7 Jul 2003 14:09:23 -0700 From: Marshall Rose Reply-To: Marshall Rose Subject: text conferencing at ietf57 To: wgchairs@ietf.org Remote Access for the 57th IETF meeting in Vienna: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 57th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms will be hosted on ietf.jabber.at and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent. So, the minute taker can review this information right after the meeting. In addition to the conference rooms for each wg that is meeting, there are three others of general interest: bar, hallway, and plenary. 1. Before the meeting: 1.1. If you want to participate If you don't already have one, get yourself a Jabber client, here are some suggestions: platform suggestion -------- ---------- win32 http://exodus.jabberstudio.org 'nix http://gabber.sf.net macos http://jabberfox.sf.net When you start the client for the first time, it will eventually ask if you want to register on a public server. Go ahead and do that. If you want to find out more, instead of choosing these defaults, here are pointers to some additional information: list of clients: http://www.jabber.org/user/clientlist.php howto: http://www.jabber.org/user/userguide/ server list: http://www.jabber.org/user/publicservers.php To make sure everything is running ok, do a "Join Group Chat" with your Jabber client: Group/Room: testing Server: conference.ietf.jabber.com This conference room is up and running right now (although probably no one will be in it when you connect). 1.2. What the Chair does If you want to make text conferencing available, you'll need to have a volunteer scribe in the meeting room. The scribe will be typing in a running commentary as to what's going on in the room (who's presenting, what question is being asked, etc.) So, why not send an email out on the mailing list now, before the meeting, to ask for volunteers? 2. At the meeting 2.1. What the Chair does When a session starts, the chair asks if someone in the room is willing to act as "scribe". If no one volunteers, read no further, we're done! Otherwise, the scribe should do a "Join Group Chat" with their Jabber client, e.g., Group/Room: foobar Server: conference.ietf.jabber.com 2.2. What the Scribe does The scribe types in a running commentary as to what's going on in the room. For example, if a speaker makes a presentation, the scribe types in the URL for the presentation (more on this in a bit). Simlarly, during question time, a remote participant can type a question into the room and the scribe can pass it on to the speaker. 2.3. What each Presenter does Each presenter should put a copy of their presentation on a web server somewhere, so remote participants can follow along. 2.4. Where to find the conference log [ tbd: i'm still working on this one... ] ####### ----- End forwarded message ----- ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- 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 Jul 8 04:24:48 2003 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 EAA13693 for ; Tue, 8 Jul 2003 04:24:48 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19ZnO8-0006WW-00 for ipfix-list@mil.doit.wisc.edu; Tue, 08 Jul 2003 02:59:48 -0500 Received: from cms1.etri.re.kr ([129.254.16.11] helo=cms1.cms.etri.re.kr) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19ZnO7-0006WQ-00 for ipfix@net.doit.wisc.edu; Tue, 08 Jul 2003 02:59:47 -0500 Received: from etri.re.kr (147.6.128.57 [147.6.128.57]) by cms1.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3K3S85SK; Tue, 8 Jul 2003 16:59:32 +0900 Message-ID: <3F0A7A07.80005@etri.re.kr> Date: Tue, 08 Jul 2003 17:00:07 +0900 From: Changhoon Kim Organization: ETRI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tanja Zseby CC: David Diep , ipfix@net.doit.wisc.edu, choits@etri.re.kr, Guido Pohl , Lutz Mark , Carsten Schmoll Subject: Re: [ipfix] Per-packet record proposal (pktId) References: <003001c33bcd$9b9ae520$46049085@hitachiialx8tm> <3EFBDF6E.EFAB6BEE@etri.re.kr> <3EFC226F.9020406@fokus.fraunhofer.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello Tanja, I compared your draft ("FOKUS") with ours ("ETRI") and summarized the common points and the differences. Some open questions to ipfixers which, I reckon, may be raised during our presentation at the Vienna meeting are also included. (Our draft can be found at http://www.ietf.org/internet-drafts/draft-kim-ipfix-ppr-00.txt, but the one we advertised on June 26 as an attachment of a mail to ipfix was the most updated version.) 1. Common Points * Objective - Incorporating per-packet information export into the existing IPFIX proposals. [Q]: Is there a common agreement on including ppr export to ipfix's scope? I'd like to listen to the voices of the group members on this issue. * Necessity and Applicability - Highly various; including QoS monitoring, usage-based accounting, traffic profiling, and application recognition. * Data Export Extension - At least two different forms of FlowSet are required; one for flow records and the other for packet records. Defining new FlowSets can be easily accomplished using template records. 2. Differences * Information Model - ETRI includes basic information model elements mostly based on IPv4/TCP headers and packet payload. It doesn't include a global identification field for a packet, while FOKUS does. [Q]: Given that all the required values for generating global id is provided, what about computing packets' global id in the collecting process? We found that the ipfix requirements and information model draft also didn't mention to exporting global flow ids. * Configuration Extension - ETRI introduces a selection criteria for enabling/disabling per-packet record generation with an emphasis on optional packet payload investigation. * Data Export - FOKUS proposes to use the Flow Index to associate the packet records to the corresponding flow records. ETRI's approach is to associate the two records on the basis of the order of FlowSets; the FlowSet conveying flow information must be disposed right ahead of the FlowSet conveying per-packet records. The FlowSet for flow records may be of the same form as the existing FlowSet or may be newly defined so that the new FlowSet can contain minimal information -- e.g. a unique flow index. - According to FOKUS, a FlowSet for Packet Properties can contain the information of packets which belong to multiple flows. In ETRI's proposal, on the other hand, a FlowSet for per-packet records contains the information of packets of a single flow. - ETRI mentions to packet record export intervals. [Q]: According to FOKUS, does every pkt record need to contain its corresponding flow index? If so, this may incur redundancy, and if not, it may also require a separate form of FlowSet to convey the flow id. We would deeply appreciate active answers or rigorous comments for the above questions and analysis result. Best regards, Chang Tanja Zseby wrote: > Hi, > > we support the idea to integrate a field for a packet ID for multiunit > QoS measurements. > Maybe you can have a look at a paper that we presented a few month ago > on how to use IPFIX/netflow9 for passive one-way delay measurements: > http://www.ist-intermon.org/workshop/papers/03_03_powd-netflow9.pdf > We also started a separate draft on this (see attachment, not yet > submitted) for exporting pktIDs and per packet timestamps with IPFIX . > > Regards > Tanja > -- 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 Jul 9 02:09:20 2003 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 CAA02638 for ; Wed, 9 Jul 2003 02:09:20 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19a7Wp-0003FO-00 for ipfix-list@mil.doit.wisc.edu; Wed, 09 Jul 2003 00:30:07 -0500 Received: from mail4.hitachi.co.jp ([133.145.228.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19a7Wn-0003CL-00 for ipfix@net.doit.wisc.edu; Wed, 09 Jul 2003 00:30:05 -0500 Received: from mc2.mcg.hitachi.co.jp by mail4.hitachi.co.jp (8.9.3p2/3.7W-mail4) id OAA15781; Wed, 9 Jul 2003 14:28:42 +0900 (JST) Received: (from root@localhost) by mc2.mcg.hitachi.co.jp (8.11.6+Sun/8.11.6) id h695SfD09481 for ; Wed, 9 Jul 2003 14:28:41 +0900 (JST) Received: from unknown [192.168.2.1] by mc2.mcg.hitachi.co.jp with SMTP id QAA09479 ; Wed, 9 Jul 2003 14:28:41 +0900 Received: from navsg1.hitachi.co.jp by navsg1.hitachi.co.jp (8.9.3/3.7W-navsg1) id OAA14188; Wed, 9 Jul 2003 14:28:40 +0900 (JST) Received: from hsdlgw92.sdl.hitachi.co.jp ([133.144.7.20]) by navsg1.hitachi.co.jp (NAVGW 2.5.2.17) with SMTP id M2003070914283904831 ; Wed, 09 Jul 2003 14:28:39 +0900 Received: from vgate.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.9.3/3.7W01100113) id OAA01859; Wed, 9 Jul 2003 14:28:39 +0900 Received: from yokolab1.sdl.hitachi.co.jp ([133.144.101.11]) by vgate.sdl.hitachi.co.jp (SAVSMTP 3.0.1.45) with SMTP id M2003070914283810248 ; Wed, 09 Jul 2003 14:28:38 +0900 Received: from hitachiialx8tm (dhcp4-70.sdl.hitachi.co.jp [133.144.4.70]) by yokolab1.sdl.hitachi.co.jp (8.9.3/3.7W02021014) with ESMTP id OAA27114; Wed, 9 Jul 2003 14:28:39 +0900 From: "David Diep" To: "'Guido Pohl'" , "'Changhoon Kim'" Cc: "'Tanja Zseby'" , , , "'Lutz Mark'" , "'Carsten Schmoll'" Subject: RE: [ipfix] Per-packet record proposal (pktId) Date: Wed, 9 Jul 2003 14:29:26 +0900 Message-ID: <003101c345db$0ff821a0$46049085@hitachiialx8tm> 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.2627 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear Guido and Chang, Just as a precision, I think that the FlowIDs (i.e. flow index value) just need to be unique within a NetFlow instance on a particular device at a given time because when a collector receives a NetFlow packet it can use the source IP address and the SourceID parameter of the NetFlow packet header to avoid any mistake due to FlowIDs collision. So FlowIDs do not need to be globally unique. Concerning the packet IDs I think they just need to be unique within a flow under observation. The packet ID is not globally unique. Best Regards, David Diep -----Original Message----- From: Guido Pohl [mailto:pohl@fokus.fraunhofer.de] Sent: Wednesday, July 09, 2003 2:06 AM To: Changhoon Kim Cc: Tanja Zseby; David Diep; ipfix@net.doit.wisc.edu; choits@etri.re.kr; Guido Pohl; Lutz Mark; Carsten Schmoll Subject: [ipfix] Per-packet record proposal (pktId) Dear Chang, concerning your mail and questions please find our comments inline ... I will answer the questions with the hope the answers are in sync with the other people of the team ;-) > [Q]: Is there a common agreement on including ppr export to ipfix's scope? > I'd like to listen to the voices of the group members on this issue. Assuming that ppr is short for per-packet record, I've found the following in the requirements draft draft-ietf-ipfix-reqs-10.txt: Please note that not all requirements for QoS monitoring are covered by the IPFIX requirements specified in the following sections. The IPFIX requirements are targeted at per flow information including summaries of per-packet properties for packets within a flow, but not per-packet information itself. For example jitter measurement requires timestamping each packet and reporting of all timestamps of a flow, but the IPFIX requirements only cover timestamps of first and last packet of a flow. So it seems that per-packet export has "never" taken into consideration ... > [Q]: Given that all the required values for generating global id is provided, > what about computing packets' global id in the collecting process? > We found that the ipfix requirements and information model draft also didn't > mention to exporting global flow ids. Behind the idea of generating a packet id for packets stands pure parsimony. So if the information exported per packet is rather sparse i.e. not the complete header and parts of the payload then one can save resources in terms of network bandwidth ... Of course, if all the information are to be exported anyway we could calculate identifiers after collecting the per-packet records. I think, that FlowIDs do not need to be globally unique, instead they are in conjuncion with the information who exports the data. (But yes this is not clearly stated in the draft (that is to come). > [Q]: According to FOKUS, does every pkt record need to contain its corresponding > flow index? If so, this may incur redundancy, and if not, it may also require a separate > form of FlowSet to convey the flow id. Yes. We intended to include the flow index. A second way would be to relate somehow whole packet information sets (with same flow properties) to templates and then relate templates to specific flows - I guess. We should think about the impact of the solutions more closely. > > We would deeply appreciate active answers or rigorous comments for the above questions > and analysis result. Thanks for your comments so far. Hope that I could clarify the question - please feel free to contact me again if not. Kind regards, Guido -- _ Guido Pohl /\ Phone : +49 30 3463 7164 _ _ Fraunhofer FOKUS -=CC MeTeoR=-/^ \ FAX : 8164 _ _ Kaiserin-Augusta-Allee 31 //_\_\ E-Mail : pohl@fokus.fraunhofer.de _ _ 10589 Berlin, Germany /____\ _ -- 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 Jul 9 08:54:10 2003 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 IAA29152 for ; Wed, 9 Jul 2003 08:54:10 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19aE6z-00035U-00 for ipfix-list@mil.doit.wisc.edu; Wed, 09 Jul 2003 07:31:53 -0500 Received: from babar.switch.ch ([130.59.4.85]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19aE6x-00035O-00 for ipfix-info@net.doit.wisc.edu; Wed, 09 Jul 2003 07:31:52 -0500 Received: from babar (localhost [IPv6:::1]) by babar.switch.ch (8.12.9+Sun/8.12.2) with ESMTP id h69CVoEI017003 for ; Wed, 9 Jul 2003 14:31:50 +0200 (CEST) Message-ID: <16140.2868.515226.732017@limmat.switch.ch> Date: Wed, 9 Jul 2003 14:31:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Simon Leinen To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] Typo in draft-ietf-ipfix-info-00.txt (field ID 11 used twice) X-Mailer: VM 7.17 under Emacs 21.2.95.1 X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit In draft-ietf-ipfix-info-00.txt, both `packetCount' and `destinationPort' use field ID 11. I suggest to change the field ID of `packetCount' to 2, because that's what NetFlow v9 seems to use. Just curious: Is the text in section 9 actually machine-generated from the schema in Appendix A? That would explain why I find section 9 a bit tedious to read (very repetitive). Maybe it would be useful to generate an additional short-hand section containing an overview of all fields, maybe in tabular format. That would make it easier to uncover problems such as this. Regards, -- Simon. *** draft-ietf-ipfix-info-00.txt 2003/07/09 12:24:13 1.1 --- draft-ietf-ipfix-info-00-sl.txt 2003/07/09 12:24:41 *************** *** 959,965 **** 9.10.3 Field Id ! The field id is 11. 9.11 byteCount --- 959,965 ---- 9.10.3 Field Id ! The field id is 2. 9.11 byteCount *************** *** 1609,1615 **** packets ! 11 2 --- 1609,1615 ---- packets ! 2 2 -- 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 Jul 9 12:47:55 2003 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 MAA09423 for ; Wed, 9 Jul 2003 12:47:55 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19aHiH-0002vI-00 for ipfix-list@mil.doit.wisc.edu; Wed, 09 Jul 2003 11:22:37 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19aHiF-0002v7-00 for ipfix-reqs@net.doit.wisc.edu; Wed, 09 Jul 2003 11:22:35 -0500 Received: from fokus.fraunhofer.de (dhcp104 [195.37.78.104]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id h69GM2Q04281; Wed, 9 Jul 2003 18:22:03 +0200 (MEST) Message-ID: <3F0C3F92.3060808@fokus.fraunhofer.de> Date: Wed, 09 Jul 2003 18:15:14 +0200 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tal Givoly CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" , Simon Leinen , ipfix-reqs@net.doit.wisc.edu Subject: Re: [ipfix-reqs] Indicating Anonymization References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Tal, the following is my personal viewpoint. The reason for anonymization is to make use of the data without compromising privacy. Its not a replacement for encryption. The someone using the data could be a 3rd party which needs the data for e.g. research. If the exporter tells the collector the algorithm and all parameters there is no point for anonymization as you pointed out. However i agree to Simon that just knowing that fields have been anonymized or not is not enough. To make use of the data someone needs to know some properties of the anonymization process e.g. whether the anonymization is prefix-preserving etc. How about adding something like: "In case anonymization is used all receiving collectors MUST be able to obtain information about the anonymization method which enables them to make use of the anonymized data. However this information MUST NOT enable a receiving collector to compromise the privacy achieved by the anonymization method." A definition of algorithms or header fields to be anonymized does not belong into the draft. We just mention some fields which we thought might be candidates for anonymization. Maybe we mention too much already. Instead of XOR i'd suggest a crypto hash ;-). Cheers, Sebastian Tal Givoly wrote: > Jeff, > > Unless rationale and proper definition of the anonymization requirement are > clearly restated, I believe that any anonymization should be done at the > collector. This would solve many issues with the current approach and would > also support the correlation to actual user sessions. This may also make it > become out of scope of the IPFIX requirements as they do not currently > pertain to the output format/transport/protocol of the collector. > > Tal > > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of MEYER,JEFFREY D (HP-Cupertino,ex1) > Sent: Monday, June 30, 2003 7:31 PM > To: 'Tal Givoly'; MEYER,JEFFREY D (HP-Cupertino,ex1); Simon Leinen; > ipfix-reqs@net.doit.wisc.edu > Subject: RE: [ipfix-reqs] Indicating Anonymization > > > Tal, > > Reversability of the XOR pattern if you have a known address which can > be identified by its flow behavior does sound like a pretty simple attack. > > I won't defend it, but would be curious in effective alternatives. I'm > not a cryptographer... > > Assuming such a mechanism is defined, I'd still suggest it be carried as > a unique flow attribute, and I believe that providing for anonymizing only > a user addresses and not server addresses would prove more useful. > > > Alternatively, data can effectively be anonymized once aggregated > at the collector. > > In other words, reports saying that some number of unique addresses > showed some behavior or had some quality in common provides information > of interest, but does not divulge individual identities. > > Perhaps this is a more reasonable approach... > > -- Jeff > > >>-----Original Message----- >>From: Tal Givoly [mailto:givoly@xacct.com] >>Sent: Monday, June 30, 2003 3:12 PM >>To: MEYER,JEFFREY D (HP-Cupertino,ex1); Simon Leinen; >>ipfix-reqs@net.doit.wisc.edu >>Subject: RE: [ipfix-reqs] Indicating Anonymization >> >> >>Jeff, >> >>That, indeed, was the main point I was trying to make. >> >>I'll explain why it seems that the anonymization algorithm >>you suggest is >>too simple - if someone can come up with an effective alternative, the >>requirement may have some more merit than it has now. >> >>Why is XOR with a random number too simple a function if one wants to >>anonymize traffic? >> >>If the same 32-bit field is XORed for all instances of the >>same IP address, >>then it would be very simple to identify that pattern. For >>instance, traffic >>flowing to or from port 53 would be DNS traffic. It would be >>very easy to >>figure out which are these DNS servers, as there aren't that >>many associated >>with an organization. Same thing for SMTP/POP3 servers and >>any other server >>with well-known ports. So, basically, it wouldn't be >>difficult to identify >>the constant with which all IP addresses are XORed. >> >>This may have lead people to think about anonymization of >>other fields, such >>as port numbers... I believe that that too is a futile effort >>if it is just >>a fixed XOR pattern. Not many protocols have the same >>source/destination >>port - the ones that do stand out in the crowd. DNS is one of >>them. Most DNS >>traffic between servers shares port 53 for both client and >>server. So once >>you identify the few protocols that identify this pattern and >>solve a few >>simple equations, you know the mask that was applied. >> >>Getting back to the bigger picture - can anybody whom >>contributed to the >>original requirements provide some rationale and perhaps even >>propose at >>least one transformation function that servers the purpose? >> >>Tal >> >>-----Original Message----- >>From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com] >>Sent: Monday, June 30, 2003 12:19 PM >>To: 'Tal Givoly'; Simon Leinen; ipfix-reqs@net.doit.wisc.edu >>Subject: RE: [ipfix-reqs] Indicating Anonymization >> >> >>Tal, >> >> I think your last statement sums it up: "Is the >>anonymization requirement >>well defined?" >> >> In general, if the requirement is to prevent data which is >>considered >>private being used by anyone, then I think the policy would >>take place at >>the IPFIX Observer level itself. In this case any correlation is >>meaningless, and runs counter to the expectation of privacty. >> >> One particular technique could be the use of a 32-bit random number >>calculated by the observer each time it starts, and not >>available to an >>external system. This value could then simply be XOR'd with >>the actual IP >>address. This would provide a one way anonymization and >>guarantee that the >>same IP address is always given the same id over the period >>the exporter is >>up. >> >> I think one complicating factor is that you may want the IP >>address of >>users anonymized, but NOT the IP address of servers on the >>Internet. What >>it means to configure anonymization behavior is probably an >>area of further >>exploration. >> >> I'm unclear on why anonymizing ports is interesting. >> >> I'd prefer to see a separate Flow Attribute in the >>Information Model to >>effectively inform any downstream consumer of the fact that >>what is being >>delivered is NOT the IP address of the actual system, but >>some scrambled >>value. Semantically, this is a different piece of >>information, i.e. it is a >>unique, but non-correlateable identifier. >> >>Regards, >> >> Jeff Meyer >> >> >>>-----Original Message----- >>>From: Tal Givoly [mailto:givoly@xacct.com] >>>Sent: Sunday, June 29, 2003 3:52 PM >>>To: Simon Leinen; ipfix-reqs@net.doit.wisc.edu >>>Subject: RE: [ipfix-reqs] Indicating Anonymization >>> >>> >>>Simon, >>> >>>It may be that that anonymization is perhaps even more >>>complex than this. >>> >>>I assume that the original intent was that even without any form of >>>encryption, the legitimate collector, or any party >>>eavesdropping on the >>>communication, would not be able to correlate individual >>>user's usage back >>>to that user. However, any form of anonymization that is a >>>1-to-1 function >>>of the original address space, and is completely specified, >>>implies that >>>anybody could go back and discover the true identity of the >>>"anonymized" >>>user. This would clearly be the case if one knows the >>>function applied to >>>anonymize the address, and it is a 1-to-1 function (because >> >>you may be >> >>>using, for instance, a 32-bit field to represent the "anonymized" IP >>>address). One would know the function, if as you suggest, >> >>the function >> >>>itself is completely specified. >>> >>>Why should it be a 1-to-1 function, you may ask? Well, it is >>>important that >>>the collector still be able to distinguish the identity of >>>the individual >>>user sessions - although not necessarily the user itself. But >>>it shouldn't >>>get mixed with other sessions. >>> >>>Why should you use the same field type for the anonymized >>>values? Well, >>>that's not mandatory - but it would make it possible for some >>>tools that are >>>designed for operating on IP addresses, for instance, to operate on >>>"anonymized" IP addresses. This is not mandatory, but may be useful. >>> >>>Now, anonymization at the device level does introduce another >>>problem - any >>>system downstream from the collector may not be able to >>>correlate back to >>>individual user session. Supposing, for instance, IP addresses are >>>dynamically assigned via DHCP or RADIUS (depending on access >>>technology) - >>>then another source of information will actually have the >>>user's identity >>>(be it MAC address for DHCP or user name/realm for RADIUS). >>>It will also be >>>the source that allows for distinguishing two users sessions >>>sharing the >>>same IP but at different times (from 9-10 user1 used IP1 >>>while the same IP1 >>>was used between 10:05 and 11 by user2). So any anonymization >>>in the device >>>would prevent downstream systems from recognizing that >>>different records >>>represent different users traffic altogether. >>> >>>This raises the questions: >>>- Is anonymization requirement well-defined? >>>- Is it even an important requirement for IPFIX? >>> >>>I don't recall that there was much discussion ever about this >>>requirement. >>>Wouldn't encryption of the links to avoid eavesdropping serve >>>most of the >>>intended purpose? Why do we require the devices to support this? >>> >>>Tal >>> >>>-----Original Message----- >>>From: majordomo listserver >>>[mailto:majordomo@mil.doit.wisc.edu]On Behalf >>>Of Simon Leinen >>>Sent: Sunday, June 29, 2003 1:40 PM >>>To: ipfix-reqs@net.doit.wisc.edu >>>Subject: [ipfix-reqs] Indicating Anonymization >>> >>> >>>While updating my protocol evaluation I-D, I found the requirements >>>I-D section on anonymization somewhat problematic. I apologize >>>bringing this up so late in the process. >>> >>>The current revision (-10) has the following to say about >>>anonymization: >>> >>> 6.7. Anonymization >>> >>> The exporting process MAY be capable of anonymizing source and >>> destination IP addresses in flow data before exporting them. It >>> MAY support anonymization of port numbers and other >>> fields. Please note that anonymization is not originally an >>> application requirement, but derived from general requirements >>> for treatment of measured traffic data within a network. >>> >>> When anonymized flow data is exported, this MUST be clearly >>> indicated to all receiving collecting processes, such that they >>> can distinguish anonymized data from non-anonymized data. >>> >>>Note that there is no single generally accepted method for >> >>anonymizing >> >>>flow export data (or even individual fields such as an IP address), >>>and different situations may require different levels of >>>anonymization. >>> >>>Because of this, I think that it is not sufficient that the >> >>collector >> >>>be able to "distinguish anonymized data from non-anonymized >> >>data", but >> >>>it must also know the method and "degree" of anonymization. This is >>>similar to sampling, where it is not sufficient to know >> >>whether there >> >>>is sampling going on or not, but one is also interested in sampling >>>parameters such as sampling method (e.g. pseudo-random, >>>packet/byte/time/flow-based) and parameters (e.g. sampling >> >>interval). >> >>>On the other hand, whether and how anonymization is >> >>performed will be >> >>>purely a matter of configuration of the exporting device, >> >>and will not >> >>>change during normal operation. This is in contrast to sampling, >>>where the parameters may change to adapt to the offered >> >>load. So one >> >>>could argue that it's not even necessary to report anonymization, >>>because of the general assumption that the collector can know the >>>static configuration of the exporting device by some other means. >>> >>>If we agree that collectors can obtain the necessary knowledge about >>>the configuration of anonymization by other means, then I >> >>suggest the >> >>>following replacement text. This is blatantly stolen from >> >>the current >> >>>text about sampling: >>> >>> 6.7. Anonymization >>> >>> The metering process MAY be capable of anonymizing source and >>> destination IP addresses in flow data before exporting them. It >>> MAY support anonymization of port numbers and other >>> fields. Please note that anonymization is not originally an >>> application requirement, but derived from general requirements >>> for treatment of measured traffic data within a network. >>> >>> If anonymization is supported, the anonymization configuration >>> MUST be well defined. The anonymization configuration includes >>> the anonymization method and all its parameters. >>> >>>However, if we really think that the anonymization >> >>configuration must >> >>>be conveyed to the collector through the IPFIX protocol, I would >>>suggest the following wording (also stolen from the text on >> >>sampling, >> >>>but from the part on what happens when the sampling configuration >>>changes during operation): >>> >>> 6.7. Anonymization >>> >>> The metering process MAY be capable of anonymizing source and >>> destination IP addresses in flow data before exporting them. It >>> MAY support anonymization of port numbers and other >>> fields. Please note that anonymization is not originally an >>> application requirement, but derived from general requirements >>> for treatment of measured traffic data within a network. >>> >>> If anonymization is supported, the anonymization configuration >>> MUST be indicated to the collector. The anonymization >>> configuration includes the anonymization method and all its >>> parameters. >>>-- >>>Simon. >>> >>>-- >>>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/ > -- Sebastian Zander E-mail: zander@fokus.fraunhofer.de Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fraunhofer.de/usr/sebastian.zander -- 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 Jul 9 18:19:17 2003 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 SAA26515 for ; Wed, 9 Jul 2003 18:19:17 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19aN0m-0006OO-00 for ipfix-list@mil.doit.wisc.edu; Wed, 09 Jul 2003 17:02:04 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19aN0k-0006Nx-00 for ipfix@net.doit.wisc.edu; Wed, 09 Jul 2003 17:02:03 -0500 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h69M218W029850 for ; Thu, 10 Jul 2003 10:02:01 +1200 (NZST) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR) with ESMTP id ARZ36222; Thu, 10 Jul 2003 10:01:58 +1200 (NZST) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h69M1CN14576 for ipfix@net.doit.wisc.edu; Thu, 10 Jul 2003 10:01:12 +1200 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Thu, 10 Jul 2003 10:01:11 +1200 Message-ID: <1057788071.878c7a983def6@hotlava.auckland.ac.nz> Date: Thu, 10 Jul 2003 10:01:11 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Fwd: More on text conferencing at ietf57 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.167 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit ----- Forwarded message from dean.willis@softarmor.com ----- Date: Wed, 9 Jul 2003 16:18:16 -0500 From: Dean Willis Reply-To: Dean Willis Subject: More on text conferencing at ietf57 To: wgchairs@ietf.org As usual, Jiri Kuthan and the team at iptel.org are providing SIMPLE support for text messaging at IETF 57. There is a sip2jabber service that connects SIP users to jabber chat rooms. We've been using it for the last several meetings. More information can be found at: http://www.iptel.org/ietf57/ -- Dean > -----Original Message----- > From: owner-wgchairs@ietf.org > [mailto:owner-wgchairs@ietf.org] On Behalf Of Marshall Rose > Sent: Monday, July 07, 2003 4:09 PM > To: wgchairs@ietf.org > Subject: text conferencing at ietf57 > > > Remote Access for the 57th IETF meeting in Vienna: > Text Conferencing > > At each IETF meeting, two of the working group meeting rooms > are equipped for video multicast and remote participation. > That is, for every IETF meeting slot, two of the working > groups can see and hear the meeting. For the 57th IETF, in > *addition* to the usual network A/V, text conferencing will > be provided for every working group that meets. > > All of the conference rooms will be hosted on > > ietf.jabber.at > > and each is named using the official IETF abbreviation found > in the agenda (e.g., "apparea", "dhc", "forces", and so on > -- for all the examples that follow, we'll use "foobar" as > the abbreviation). > > Each conference room also has a 'bot which records everything > that gets sent. So, the minute taker can review this > information right after the meeting. > > In addition to the conference rooms for each wg that is > meeting, there are three others of general interest: bar, > hallway, and plenary. > > > 1. Before the meeting: > > 1.1. If you want to participate > > If you don't already have one, get yourself a Jabber client, > here are some > suggestions: > > platform suggestion > -------- ---------- > win32 http://exodus.jabberstudio.org > 'nix http://gabber.sf.net > macos http://jabberfox.sf.net > > When you start the client for the first time, it will > eventually ask if you want to register on a public server. Go > ahead and do that. > > If you want to find out more, instead of choosing these > defaults, here are pointers to some additional information: > > list of clients: http://www.jabber.org/user/clientlist.php > howto: http://www.jabber.org/user/userguide/ > server list: http://www.jabber.org/user/publicservers.php > > To make sure everything is running ok, do a "Join Group Chat" > with your Jabber client: > > Group/Room: testing > Server: conference.ietf.jabber.com > > This conference room is up and running right now (although > probably no one will be in it when you connect). > > 1.2. What the Chair does > > If you want to make text conferencing available, you'll need > to have a volunteer scribe in the meeting room. The scribe > will be typing in a running commentary as to what's going on > in the room (who's presenting, what question is being asked, etc.) > > So, why not send an email out on the mailing list now, before > the meeting, to ask for volunteers? > > > 2. At the meeting > > 2.1. What the Chair does > > When a session starts, the chair asks if someone in the room > is willing to act as "scribe". If no one volunteers, read no > further, we're done! > > Otherwise, the scribe should do a "Join Group Chat" with > their Jabber client, e.g., > > Group/Room: foobar > Server: conference.ietf.jabber.com > > > 2.2. What the Scribe does > > The scribe types in a running commentary as to what's going > on in the room. For example, if a speaker makes a > presentation, the scribe types in the URL for the > presentation (more on this in a bit). > > Simlarly, during question time, a remote participant can type > a question into the room and the scribe can pass it on to the speaker. > > > 2.3. What each Presenter does > > Each presenter should put a copy of their presentation on a > web server somewhere, so remote participants can follow along. > > > 2.4. Where to find the conference log > > [ tbd: i'm still working on this one... ] > > ####### > > ----- End forwarded message ----- ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- 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 Jul 9 20:42:49 2003 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 UAA01065 for ; Wed, 9 Jul 2003 20:42:48 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19aPBl-000337-00 for ipfix-list@mil.doit.wisc.edu; Wed, 09 Jul 2003 19:21:33 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19aPBk-000330-00 for ipfix-info@net.doit.wisc.edu; Wed, 09 Jul 2003 19:21:32 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel9.hp.com (Postfix) with ESMTP id BF94B1C00DE2; Wed, 9 Jul 2003 20:21:31 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 152791C00C77; Wed, 9 Jul 2003 20:21:31 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55) id <3F33RYF7>; Wed, 9 Jul 2003 20:21:30 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296015F@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Simon Leinen'" , ipfix-info@net.doit.wisc.edu Subject: RE: [ipfix-info] Typo in draft-ietf-ipfix-info-00.txt (field ID 1 1 used twice) Date: Wed, 9 Jul 2003 20:21:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver Simon, Thanks for noting the field id error. I'll follow your recommendation on changing from 11 to 2 to match current NFv9. In answer to your question, section 9 is auto generated from appendix A. Juergen also pointed out that the subsections are tedious to read, I'll try to make the sections a bit more compact. A summary table is a good idea, I'll see what I can do. Regards, Jeff Meeyr > -----Original Message----- > From: Simon Leinen [mailto:simon@limmat.switch.ch] > Sent: Wednesday, July 09, 2003 5:32 AM > To: ipfix-info@net.doit.wisc.edu > Subject: [ipfix-info] Typo in draft-ietf-ipfix-info-00.txt > (field ID 11 > used twice) > > > In draft-ietf-ipfix-info-00.txt, both `packetCount' and > `destinationPort' use field ID 11. I suggest to change the field ID > of `packetCount' to 2, because that's what NetFlow v9 seems to use. > > Just curious: Is the text in section 9 actually machine-generated from > the schema in Appendix A? That would explain why I find section 9 a > bit tedious to read (very repetitive). > > Maybe it would be useful to generate an additional short-hand section > containing an overview of all fields, maybe in tabular format. That > would make it easier to uncover problems such as this. > > Regards, > -- > Simon. > > *** draft-ietf-ipfix-info-00.txt 2003/07/09 12:24:13 1.1 > --- draft-ietf-ipfix-info-00-sl.txt 2003/07/09 12:24:41 > *************** > *** 959,965 **** > > 9.10.3 Field Id > > ! The field id is 11. > > 9.11 byteCount > > --- 959,965 ---- > > 9.10.3 Field Id > > ! The field id is 2. > > 9.11 byteCount > > *************** > *** 1609,1615 **** > packets > > > ! 11 > 2 > > > --- 1609,1615 ---- > packets > > > ! 2 > 2 > > > > > -- > 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 Jul 14 04:44:15 2003 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 EAA02237 for ; Mon, 14 Jul 2003 04:44:14 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19byTm-00054u-00 for ipfix-list@mil.doit.wisc.edu; Mon, 14 Jul 2003 03:14:38 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19byTl-00054m-00 for ipfix@net.doit.wisc.edu; Mon, 14 Jul 2003 03:14:37 -0500 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h6E8EanZ021924 for ; Mon, 14 Jul 2003 20:14:36 +1200 (NZST) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR) with ESMTP id ASD49316; Mon, 14 Jul 2003 20:14:35 +1200 (NZST) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h6E8EZ119629 for ipfix@net.doit.wisc.edu; Mon, 14 Jul 2003 20:14:35 +1200 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from 81.160.163.185 ([81.160.163.185]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Mon, 14 Jul 2003 20:14:35 +1200 Message-ID: <1058170475.eb4b1e3b58fff@hotlava.auckland.ac.nz> Date: Mon, 14 Jul 2003 20:14:35 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] General comments on the IPFIX drafts MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 81.160.163.185 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all: These are some comments from me covering issues which don't fit neatly into one or other of the IPFIX drafts. At this point we shouldn't be raising 'big' new issues; I hope these are small-scale enough for us to reach consensus on fairly quickly! Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand Ng1: Timestamp precision: flowCreationTime and flowEndTime, in -info draft, are in dateTime units, i.e. 'seconds normalized to GMT' (why not to UTC?). Is this sufficient precision? For example, RTFM used SNMP TimeTicks, i.e. centiseconds (of sysUpTime). There are three questions here: a) How many bytes do we really need? If seconds is precise enough, 4 bytes is fine. If we need more, or should we could go to 8? b) If we feel that we can afford 8-byte precision, what time base should we use, sysUpTime or time of day. Time of day would mean that collectors didn't have to convert from sysUpTime. Can we assume that Metering Processes will have a reliable time-of-day clock? c) Format of 8-byte times. The most common Unix one is (sec, usec). (sec, nsec) is also widely available. My favourite is (sec, binary fraction of sec) [NTP 64-bit timestamp, Section 3.1 of RFC 1305], because you can compute time differences with a single 64-bit subtraction. Ng2: Data representation in IPFIX packets. The info model defines the data types for each field (IPFIX attribute), I think we need the protocol document to specify how they're mapped into the packet, e.g. 'data values are placed in their fields within the packet in network byte order, i.e. most-significant byte first.' Which data types can be variable-length? If - as I suspect - it's only strings, could we agree to only have variable-length strings (i.e. no fixed-length strings)? Ng3: IANA Namespace for XML Namespace URIs. WG Chairs (probably Nevil) will follow up on this for the Info Model I-D. Ng4: Flow Sampling. This is mentioned in both the Requirements I-D and the AS I-D. We need to decide how it should be covered in the IPFIX drafts. ---------------------------------------------------------------------- ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- 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 Jul 14 05:31:41 2003 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 EAA02238 for ; Mon, 14 Jul 2003 04:44:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19byMe-0004g4-00 for ipfix-list@mil.doit.wisc.edu; Mon, 14 Jul 2003 03:07:16 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19byMd-0004ft-00 for ipfix-info@net.doit.wisc.edu; Mon, 14 Jul 2003 03:07:15 -0500 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h6E87CnZ021170 for ; Mon, 14 Jul 2003 20:07:12 +1200 (NZST) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR) with ESMTP id ASD49003; Mon, 14 Jul 2003 20:07:12 +1200 (NZST) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h6E87B119600 for ipfix-info@net.doit.wisc.edu; Mon, 14 Jul 2003 20:07:11 +1200 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from 81.160.163.185 ([81.160.163.185]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Mon, 14 Jul 2003 20:07:11 +1200 Message-ID: <1058170031.922d3f59d10d1@hotlava.auckland.ac.nz> Date: Mon, 14 Jul 2003 20:07:11 +1200 From: Nevil Brownlee To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] Comments on Info draft MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 81.160.163.185 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all: It's taken a while for me to catch up, but here are my comments on the Info Model draft. The draft itself is a good start, these are just the issues I spotted while reading it on the 'plane to Vienna. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand Ni1: Variable Length Data Type: The Protocol I-D has a section about 'variable-length data types' shouldn't that be here, in the Information Model I-D? Can anything other than a string be variable-length? Ni2: ipdr: types. Do we need to have the ipdr: prefix? The Info Model RFC will need an IANA Considerations section, so we'll need a Appendices listing the data types - can we not give them all simple names, and comment on which of them are identical to their ipdr: cousins? [Also, for the IANA Considerations, we'll need a list of all the Field Ids.] Ni3: Section 6, Extending the Info Model: typo in para 3, s/flow ids/field ids/ Ni4: Section 9.11, byteCount Para 2 says a flow can be bi-directional, in which case byteCount is the sum of both directions. How would a collector know whether a flow 1- or 2-directional? Ni5: Section 9.11, byteCount Is int big enough for this? (RTFM used unsignedLong) Ni6: Section 9.14 and 9.15, flowCreation- and EndTime Is seconds precision enough? Ni7: Section 9.20 sourceExporterAddress This is defined as an IPv4 address. What about IPv6 Exporters? Ni8: Sections 9.22 samplingInterval and 9.23 samplingAlgorithn. I think samplingAlgorithm should appear before samplingInterval. Maybe what's needed is samplingAlgorithm first, with values like 'count-based,' 'time-based' or 'content-based,' using the algorithm names from our Requirements I-D. That could have subsections for each of the algorithm's parameters, e.g. count-based would have samplingInterval = n meaning 'meter every nth packet within each flow.' ---------------------------------------------------------------------- ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- 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 Jul 14 09:01:38 2003 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 JAA16799 for ; Mon, 14 Jul 2003 09:01:38 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19c2gx-000027-00 for ipfix-list@mil.doit.wisc.edu; Mon, 14 Jul 2003 07:44:31 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19c2gw-0007ms-00 for ipfix-as@net.doit.wisc.edu; Mon, 14 Jul 2003 07:44:30 -0500 Received: from fokus.fraunhofer.de (tzs1.ietf57.telekom.at [81.160.196.114]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id h6ECh8v13469 for ; Mon, 14 Jul 2003 14:43:08 +0200 (MEST) Message-ID: <3F12A559.1020803@fokus.fraunhofer.de> Date: Mon, 14 Jul 2003 14:43:05 +0200 From: Tanja Zseby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: de-de, de, en-us MIME-Version: 1.0 To: ipfix-as@net.doit.wisc.edu Subject: [ipfix-as] middlebox considerations in applicability statement Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all, one thing that I would like to discuss in the IPFIX meeting is what should happen to the section on middlebox considerations in the IPFIX applicability draft. I think that this part does not really belong to the applicability statement because it rather proposes a specfic IPFIX behavior, which would influence architecture and/or protocol. So if we want to keep this part somewhere, then it would rather fit into the architecture document or it could become a separate draft, that proposes IPFIX extensions. Regards Tanja -- Dipl.-Ing. Tanja Zseby Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.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 Mon Jul 14 09:07:23 2003 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 JAA17077 for ; Mon, 14 Jul 2003 09:07:23 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19c2pZ-0000H8-00 for ipfix-list@mil.doit.wisc.edu; Mon, 14 Jul 2003 07:53:25 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19c2pY-0000DZ-00 for ipfix@net.doit.wisc.edu; Mon, 14 Jul 2003 07:53:24 -0500 Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel10.hp.com (Postfix) with ESMTP id 896C91C00FD6; Mon, 14 Jul 2003 05:52:01 -0700 (PDT) Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id 39CA71004BBC; Mon, 14 Jul 2003 05:52:01 -0700 (PDT) Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55) id <3LGRFV95>; Mon, 14 Jul 2003 05:52:01 -0700 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960188@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Nevil Brownlee'" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] General comments on the IPFIX drafts Date: Mon, 14 Jul 2003 05:52:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver Nevil, Some comments on the first three issues: Ng-1: I would suspect that second resolution time is insufficient for some applications. Millisecond resolution represented as a 64-bit integer counter since EPOCH is a type currently defined by IPDR. Having this information item encoded explicitly would certainly be more convenient from a collection (and info modelling) perspective than the current NF model, which is relative to boot time. Ng-2: Having the protocol spec define the mappings from the base type space in the info model makes sense. Network byte ordering would be my expectation for fixed width quantities. For the variable length fields, there seemed to be some discussion around the use of 1,2 or 4 byte length indicators. There also remains the question of whether or not padding is used for any sort of word alignment. Ng-3: The namespace URI would be worth advancing. RFC3470 which talks about use of XML in IETF drafts has some discussion in sections 4.9 and 4.17. Although it sounds like policy here is still being defined. Let me know if you would like me to contact the authors to better understand the current state of affairs w/ IANA or if you would like to do this. Regards, Jeff Meyer -----Original Message----- From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] Sent: Monday, July 14, 2003 1:15 AM To: ipfix@net.doit.wisc.edu Subject: [ipfix] General comments on the IPFIX drafts Hi all: These are some comments from me covering issues which don't fit neatly into one or other of the IPFIX drafts. At this point we shouldn't be raising 'big' new issues; I hope these are small-scale enough for us to reach consensus on fairly quickly! Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand Ng1: Timestamp precision: flowCreationTime and flowEndTime, in -info draft, are in dateTime units, i.e. 'seconds normalized to GMT' (why not to UTC?). Is this sufficient precision? For example, RTFM used SNMP TimeTicks, i.e. centiseconds (of sysUpTime). There are three questions here: a) How many bytes do we really need? If seconds is precise enough, 4 bytes is fine. If we need more, or should we could go to 8? b) If we feel that we can afford 8-byte precision, what time base should we use, sysUpTime or time of day. Time of day would mean that collectors didn't have to convert from sysUpTime. Can we assume that Metering Processes will have a reliable time-of-day clock? c) Format of 8-byte times. The most common Unix one is (sec, usec). (sec, nsec) is also widely available. My favourite is (sec, binary fraction of sec) [NTP 64-bit timestamp, Section 3.1 of RFC 1305], because you can compute time differences with a single 64-bit subtraction. Ng2: Data representation in IPFIX packets. The info model defines the data types for each field (IPFIX attribute), I think we need the protocol document to specify how they're mapped into the packet, e.g. 'data values are placed in their fields within the packet in network byte order, i.e. most-significant byte first.' Which data types can be variable-length? If - as I suspect - it's only strings, could we agree to only have variable-length strings (i.e. no fixed-length strings)? Ng3: IANA Namespace for XML Namespace URIs. WG Chairs (probably Nevil) will follow up on this for the Info Model I-D. Ng4: Flow Sampling. This is mentioned in both the Requirements I-D and the AS I-D. We need to decide how it should be covered in the IPFIX drafts. ---------------------------------------------------------------------- ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- 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 Jul 14 09:20:29 2003 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 JAA18301 for ; Mon, 14 Jul 2003 09:20:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19c34O-0000oB-00 for ipfix-list@mil.doit.wisc.edu; Mon, 14 Jul 2003 08:08:44 -0500 Received: from smtp.ietf57.telekom.at ([81.160.16.8]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19c34N-0000md-00 for ipfix-as@net.doit.wisc.edu; Mon, 14 Jul 2003 08:08:43 -0500 Received: from [81.160.167.172] ([81.160.167.172]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with ESMTP id h6ED7uk09806; Mon, 14 Jul 2003 15:07:56 +0200 (MEST) Date: Mon, 14 Jul 2003 15:08:08 +0200 From: Juergen Quittek To: Tanja Zseby , ipfix-as@net.doit.wisc.edu Subject: Re: [ipfix-as] middlebox considerations in applicability statement Message-ID: <2147483647.1058195288@[81.160.167.172]> In-Reply-To: <3F12A559.1020803@fokus.fraunhofer.de> References: <3F12A559.1020803@fokus.fraunhofer.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Tanja, I agree. The section on middleboxes does certainly not fit into the applicability document. It nakes statements what an IPFIX implemetation MUST/SHOULD support. We could turn it into a nice section of the architecture document. If it became a separate document, I would rather see it as a document on implementing IPFIX on middleboxes than as a document on IPFIX extensions. Juergen --On Montag, 14. Juli 2003 14:43 Uhr +0200 Tanja Zseby wrote: > Hi all, > > one thing that I would like to discuss in the IPFIX meeting is what should happen to the section on middlebox considerations in the IPFIX applicability draft. I think that this part does not really belong to the applicability statement because it > rather proposes a specfic IPFIX behavior, which would influence architecture and/or protocol. So if we want to keep this part somewhere, then it would rather fit into the architecture document or it could become a separate draft, that proposes IPFIX > extensions. > > Regards > Tanja > > -- > Dipl.-Ing. Tanja Zseby > Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.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/ -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Jul 14 11:33:09 2003 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 LAA28952 for ; Mon, 14 Jul 2003 11:33:09 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19c59k-00059e-00 for ipfix-list@mil.doit.wisc.edu; Mon, 14 Jul 2003 10:22:24 -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 19c59j-00059I-00 for ipfix-reqs@net.doit.wisc.edu; Mon, 14 Jul 2003 10:22:23 -0500 Received: from cisco.com (dhcp-144-254-19-210.cisco.com [144.254.19.210]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h6EFM7p02459; Mon, 14 Jul 2003 17:22:07 +0200 (CEST) Message-ID: <3F12CA9F.5060507@cisco.com> Date: Mon, 14 Jul 2003 17:22:07 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Leinen CC: Ganesh Sadasivan , "Harrington, David" , ipfix-reqs@net.doit.wisc.edu Subject: Re: [ipfix-reqs] Flow definition References: <6D745637A7E0F94DA070743C55CDA9BA603331@NHROCMBX1.ets.enterasys.com> <3EF7337F.9321FD8C@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010006000804020006060805" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------010006000804020006060805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Simon Leinen wrote: >Ganesh Sadasivan writes: > > >>Thanks David. I re-read the charter & agree that the charter does >>not mention about MPLS flows. But the question is if flow collection >>is done on MPLS encapsulated IP packet ? If so should we not >>explicitly include them in the flow definition. >> >> The charter doesn't speak about MPLS but the requirement draft does: 2.1. IP Traffic Flow There are several definitions of the term 'flow' being used by the Internet community. Within this document we use the following one: A flow is defined as a set of IP packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of: 1. one or more packet header field (e.g. destination IP address), transport header field (e.g. destination port number), or application header field (e.g. RTP header fields [RFC1889]) 2. one or more characteristics of the packet itself (_e.g. number of MPLS labels_, etc...) 4.4. MPLS Label If the observation point is located at a device supporting Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering process MUST be able to separate flows by the MPLS label. >I would say no, we shouldn't. > What's next? So maybe the proposal #2 from Ganesh (below) makes sense? From I have the following proposal: 1. "A flow is defined as a set of IP packets or a sub-IP encapsulated IP packets passing an observation point in the network during a certain time interval." 2. In the section on MPLS there should be a statement telling that for MPLS packets, the metering process has to dig into the packet or by some other means find out if the encapsulated packet is an IP packet. Regards, Benoit. --------------010006000804020006060805 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Simon Leinen wrote:
Ganesh Sadasivan writes:
  
Thanks David. I re-read the charter & agree that the charter does
not mention about MPLS flows. But the question is if flow collection
is done on MPLS encapsulated IP packet ? If so should we not
explicitly include them in the flow definition.
The charter doesn't speak about MPLS but the requirement draft does:
2.1.  IP Traffic Flow

   There are several definitions of the term 'flow' being used by the
   Internet community. Within this document we use the following one:

   A flow is defined as a set of IP packets passing an observation point
   in the network during a certain time interval. All packets belonging
   to a particular flow have a set of common properties. Each property
   is defined as the result of applying a function to the values of:

      1. one or more packet header field (e.g. destination IP address),
         transport header field (e.g. destination port number), or
         application header field (e.g. RTP header fields [RFC1889])

      2. one or more characteristics of the packet itself (e.g. number
         of MPLS labels, etc...)

4.4.  MPLS Label

   If the observation point is located at a device supporting
   Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering
   process MUST be able to separate flows by the MPLS label.


I would say no, we shouldn't.

What's next? So maybe the proposal #2 from Ganesh (below) makes sense?

From I have the following proposal:
1. "A flow is defined as a set of IP packets or a sub-IP encapsulated IP
packets passing an observation point in the network during a certain time interval."
2.
In the section on MPLS there should be  a statement telling that for
MPLS packets, the  metering process has to dig into the packet or by some other means
find out if the encapsulated packet is an IP packet.

Regards, Benoit.


--------------010006000804020006060805-- -- 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 Jul 15 04:43:16 2003 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 EAA05426 for ; Tue, 15 Jul 2003 04:43:16 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19cKvl-0006R1-00 for ipfix-list@mil.doit.wisc.edu; Tue, 15 Jul 2003 03:13:01 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19cKvk-0006Qp-00; Tue, 15 Jul 2003 03:13:00 -0500 Received: from fokus.fraunhofer.de (tzs1.ietf57.telekom.at [81.160.196.114]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id h6F8Cqv26205; Tue, 15 Jul 2003 10:12:52 +0200 (MEST) Message-ID: <3F13B781.6060702@fokus.fraunhofer.de> Date: Tue, 15 Jul 2003 10:12:49 +0200 From: Tanja Zseby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: de-de, de, en-us MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix-as@net.doit.wisc.edu, ipfix-chairs@net.doit.wisc.edu Subject: [ipfix-as] Re: Ipfix and middlebox presentation References: <0A11633F61BD9F40B43ABCC694004F930218F01E@zsc3c026.us.nortel.com> Content-Type: multipart/alternative; boundary="------------040909030404060907090001" Precedence: bulk Sender: majordomo listserver --------------040909030404060907090001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Reinaldo, this is o.k. with me. I do not need much time for the update on the AS draft. So I propose that I give a short update and then hand over to you. Regards Tanja Reinaldo Penno wrote: > Hello Tanja > > Here it goes the presentation for your revision. I would like to > present it if you and the chairs do not mind so I can drive any > discussions. It won't take mode than 5 minutes. > > Regards, > > Reinaldo > > > -- Dipl.-Ing. Tanja Zseby Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.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) -------------------------------------------------------------------------------------- --------------040909030404060907090001 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Reinaldo,

this is o.k. with me. I do not need much time for the update on the AS draft. So I propose that I give a short update and then hand over to you.

Regards
Tanja

Reinaldo Penno wrote:
Ipfix and middlebox presentation

Hello Tanja

Here it goes the presentation for your revision. I would like to present it if you and the chairs do not mind so I can drive any discussions. It won't take mode than 5 minutes.

Regards,

Reinaldo

  


-- 
Dipl.-Ing. Tanja Zseby			    	      	
Fraunhofer Institute FOKUS			Email: zseby@fokus.fraunhofer.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)
--------------------------------------------------------------------------------------

--------------040909030404060907090001-- -- 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 Jul 15 10:39:42 2003 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 KAA22152 for ; Tue, 15 Jul 2003 10:39:42 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19cQoi-00058d-00 for ipfix-list@mil.doit.wisc.edu; Tue, 15 Jul 2003 09:30:08 -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 19cQoh-00058X-00 for ipfix-as@net.doit.wisc.edu; Tue, 15 Jul 2003 09:30:07 -0500 Received: from cisco.com (dhcp-144-254-19-210.cisco.com [144.254.19.210]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h6FETsp04568; Tue, 15 Jul 2003 16:29:54 +0200 (CEST) Message-ID: <3F140FE1.7050003@cisco.com> Date: Tue, 15 Jul 2003 16:29:53 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Tanja Zseby , ipfix-as@net.doit.wisc.edu Subject: Re: [ipfix-as] middlebox considerations in applicability statement References: <3F12A559.1020803@fokus.fraunhofer.de> <2147483647.1058195288@[81.160.167.172]> In-Reply-To: <2147483647.1058195288@[81.160.167.172]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Tanja and Juergen, > Tanja, > > I agree. > > The section on middleboxes does certainly not fit into the > applicability document. It nakes statements what an IPFIX > implemetation MUST/SHOULD support. We could turn it into > a nice section of the architecture document. If it became > a separate document, I would rather see it as a document on > implementing IPFIX on middleboxes than as a document on IPFIX > extensions. I personally think that a separate document on IPFIX on middleboxes is more appropriate. We don't speak a single time about NAT, traffic conditioners or VPNs in the requirement draft. By putting all these cases in the architecture draft, one could think that IPFIX is designed mainly for midlleboxes... which is not true! Regards, Benoit. > > > Juergen > > --On Montag, 14. Juli 2003 14:43 Uhr +0200 Tanja Zseby > wrote: > >> Hi all, >> >> one thing that I would like to discuss in the IPFIX meeting is what >> should happen to the section on middlebox considerations in the IPFIX >> applicability draft. I think that this part does not really belong to >> the applicability statement because it >> rather proposes a specfic IPFIX behavior, which would influence >> architecture and/or protocol. So if we want to keep this part >> somewhere, then it would rather fit into the architecture document or >> it could become a separate draft, that proposes IPFIX >> extensions. >> >> Regards >> Tanja >> >> -- >> Dipl.-Ing. Tanja Zseby >> Fraunhofer Institute FOKUS Email: >> zseby@fokus.fraunhofer.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 Jul 16 06:18:27 2003 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 GAA24052 for ; Wed, 16 Jul 2003 06:18:27 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19cisk-0005Bb-00 for ipfix-list@mil.doit.wisc.edu; Wed, 16 Jul 2003 04:47:30 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19cisj-0005BV-00 for ipfix@net.doit.wisc.edu; Wed, 16 Jul 2003 04:47:29 -0500 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h6G9lQnb007780 for ; Wed, 16 Jul 2003 21:47:27 +1200 (NZST) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR) with ESMTP id ASF96956; Wed, 16 Jul 2003 21:47:26 +1200 (NZST) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h6G9lQD03625 for ipfix@net.doit.wisc.edu; Wed, 16 Jul 2003 21:47:26 +1200 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from 81.160.139.211 ([81.160.139.211]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Wed, 16 Jul 2003 21:47:26 +1200 Message-ID: <1058348846.b47926d706da9@hotlava.auckland.ac.nz> Date: Wed, 16 Jul 2003 21:47:26 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] We need a jabber scribe for this sfternoon's IPFIX meeting <<< MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 81.160.139.211 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all: At this stage we haven't found anyone to be our jabber scribe at the IPFIX mee4ting, 1530 today. Of course we can ask in the meeting, but is there anyone here in Vienna who'd care to volunteer now? Thanks, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- 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 Jul 16 10:48:12 2003 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 KAA04597 for ; Wed, 16 Jul 2003 10:48:12 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19cnOQ-0007fC-00 for ipfix-list@mil.doit.wisc.edu; Wed, 16 Jul 2003 09:36:30 -0500 Received: from central.switch.ch ([130.59.4.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19cnOP-0007f4-00 for ipfix@net.doit.wisc.edu; Wed, 16 Jul 2003 09:36:29 -0500 Received: from shabaka ([130.59.4.25]) by central.switch.ch with esmtp (Exim 3.20 #1) id 19cnON-0004Oz-00 for ipfix@net.doit.wisc.edu; Wed, 16 Jul 2003 16:36:27 +0200 Message-ID: <16149.25323.423345.683540@limmat.switch.ch> Date: Wed, 16 Jul 2003 16:36:27 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="RNEhlK5NEY" Content-Transfer-Encoding: 7bit From: Simon Leinen To: ipfix@net.doit.wisc.edu Subject: [ipfix] My slide from the ipfix meeting at IETF57 X-Mailer: VM 7.07 under Emacs 21.2.90.1 X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` Precedence: bulk Sender: majordomo listserver --RNEhlK5NEY Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Here's my slide about draft-leinen-ipfix-eval-contrib-01.txt, in ASCII (art) and PDF formats +---------------------------------------------+ | draft-leinen-ipfix-eval-contrib-01.txt | | | | Purpose | | Document IPFIX protocol evaluation | | | | Changes from -00 | | Put back "Conclusions" section | | Recommends NetFlow v9 as starting point | | Added missing text on a few requirements | | | | Suggested way forward | | Adopt as a WG item | | WG Last-Call soon | | Request publication as Informational RFC | +---------------------------------------------+ -- Simon. --RNEhlK5NEY Content-Type: application/pdf Content-Disposition: attachment; filename="eval.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nK1WyW7bMBC96yuIXJoexHJfjq3bFAGCInUMtFdFll21WhxJjtO/75AibSV1 EB8Mw5I55CzvzUI/IIIpIu4T3nmdPCQf5gKt+4QStEsoKhNJECUESQM/DGMEdUVylzyA0OuEV16j TwvQtYiixSohiDMsUOqfBGmKBSEMCYvBFkeLOrlE7xe/E4KZ1tZaOLNYJpfLLlsNaVWUTdGk5WZV PqXFY1aledsMXXmfEoqHp8Epflmg74mFEA0VWHvTFDvTQiLNrTkxSotS59sSLPTR+BDjDod/ghmq Mddvwrjddpu2L9xOut9KKWacEelPHNNCe1yUE4uU1OBFO5/+exqg5+EKhRkyQAwlykf7uc23ddEM 3pfAhsvg/Pr26vqnlzIMQQXppmuHNm8rv8Enx11WttlQto0HSRk2lGkEaKXVgk9AMkwFwESLGyd4 9xL07FfWrIs+xMNMEK+6tg7qTEdhSoj3piAQ5fjk4hQ2GVMCW3EOQpmgWIOpKaW325FNOuHtPsv/ hPB5lF3M2iavtj1w1l/4TYUFF2G3L/LIJsRisKsX9wSfimN+vOTMFOs5BCNfUlFkATGTEtXPlxUs ucJU7iVMUgX9wyE8My6MNn4nT8alBO6gt6Ki4VER7MaFO2skNpNtRSa6fnGw65YHn6PiIaBJvPkp KT5Ct5WYOH1H97zI2xqaZtnHrAkVSPtWDFdVuwvtYUVsj0cbSoLvE5z1/4n6IeuGslkHdSl1bLu2 bIYj44fBjNPqzfEzSaWG0ldnqfzR9bTwPy6XxTLETlV0Xpd9f8CkVMQ0FE+xT0w82zaRkyjJAh6o ggOeVbGLmnvuuuJhW3aFm2X9OIIEDBodRpClwpw8gu62a5hAQ8ACiZdxZ5f9DQaIjClftd0u65be J1wGlp8+iLhm5EyDiBvnW7zIR7sZQrzG0tfr7ijJP76OqmFZDkXtMRosYIDa01EKwiWGtJ8BpYCe NGBqivJFnDdZP6SzrKriDcJ47K42XE4aS6NGBAQyYE7BwIzCkp8Fg4DBAKamGOZQvFBxIWT3xyj0 /fa+KnN/re5r0byex+sGirH2x7MqzKaDwvxqtsfjPv8AO5ouyGVuZHN0cmVhbQplbmRvYmoKNyAw IG9iago4MjQKZW5kb2JqCjUgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0 Ml0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4 dF0KL0V4dEdTdGF0ZSAxMCAwIFIKL0ZvbnQgMTEgMCBSCj4+Ci9Db250ZW50cyA2IDAgUgo+Pgpl bmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwo1IDAgUgpdIC9Db3VudCAxCi9S b3RhdGUgOTA+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUgo+ PgplbmRvYmoKNCAwIG9iago8PC9UeXBlL0V4dEdTdGF0ZS9OYW1lL1I0L1RSL0lkZW50aXR5Pj4K ZW5kb2JqCjEwIDAgb2JqCjw8L1I0CjQgMCBSPj4KZW5kb2JqCjExIDAgb2JqCjw8L1I5CjkgMCBS Pj4KZW5kb2JqCjkgMCBvYmoKPDwvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9IZWx2ZXRpY2EvVHlw ZS9Gb250L05hbWUvUjk+PgplbmRvYmoKOCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0Zv bnROYW1lL0hlbHZldGljYT4+CmVuZG9iagoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdOVSBHaG9zdHNj cmlwdCA3LjA3KQovQ3JlYXRvcihtZ3AycHMpCi9UaXRsZShldmFsLm1ncCk+PmVuZG9iagp4cmVm CjAgMTIKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDAxMTU4IDAwMDAwIG4gCjAwMDAwMDE0NTEg MDAwMDAgbiAKMDAwMDAwMTA4OSAwMDAwMCBuIAowMDAwMDAxMjA2IDAwMDAwIG4gCjAwMDAwMDA5 MjggMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAwMDAwOTA5IDAwMDAwIG4gCjAwMDAw MDEzOTIgMDAwMDAgbiAKMDAwMDAwMTMyMSAwMDAwMCBuIAowMDAwMDAxMjYxIDAwMDAwIG4gCjAw MDAwMDEyOTEgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAxMiAvUm9vdCAxIDAgUiAvSW5mbyAy IDAgUgo+PgpzdGFydHhyZWYKMTUzNQolJUVPRgo= --RNEhlK5NEY-- -- 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 Jul 16 11:52:27 2003 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 LAA06719 for ; Wed, 16 Jul 2003 11:52:26 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19coPW-00023C-00 for ipfix-list@mil.doit.wisc.edu; Wed, 16 Jul 2003 10:41:42 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19coPU-00022y-00 for ipfix@net.doit.wisc.edu; Wed, 16 Jul 2003 10:41:40 -0500 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h6GFfcnZ014000 for ; Thu, 17 Jul 2003 03:41:38 +1200 (NZST) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR) with ESMTP id ASG19748; Thu, 17 Jul 2003 03:41:37 +1200 (NZST) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h6GFfbG05207 for ipfix@net.doit.wisc.edu; Thu, 17 Jul 2003 03:41:37 +1200 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from 81.160.139.211 ([81.160.139.211]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Thu, 17 Jul 2003 03:41:37 +1200 Message-ID: <1058370097.e05a136863252@hotlava.auckland.ac.nz> Date: Thu, 17 Jul 2003 03:41:37 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Couldn't find a jabber scribe, sorry MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 81.160.139.211 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all: In spite of determined efforts, finishing with asking those present at the meeting, we weren't able to find a jabber scribe. All I can say to those who weren't able to be here is "Sorry, we tried hard." The (draft) meeting minutes will be available tomorrow. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- 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 Jul 17 08:03:44 2003 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 IAA02299 for ; Thu, 17 Jul 2003 08:03:44 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19d77J-0004Gb-00 for ipfix-list@mil.doit.wisc.edu; Thu, 17 Jul 2003 06:40:09 -0500 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19d77I-0004GV-00 for ipfix@net.doit.wisc.edu; Thu, 17 Jul 2003 06:40:08 -0500 Date: Thu, 17 Jul 2003 06:40:08 -0500 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna Message-ID: <20030717064008.A15788@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jI8keyz6grp/JLjh" X-Mailer: Mutt 1.0.1i X-Organization: University of Wisconsin-Madison, DoIT Network Services X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL) X-URL: http://net.doit.wisc.edu/~plonka/ X-VMS-Error: %SYSTEM-W-VASFULL, virtual address space is full X-Shakespearean-Insult: Thou loggerheaded plume-plucked flirt-gill Precedence: bulk Sender: majordomo listserver --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii IPFIXers, Please review the attached DRAFT minutes of the IPFIX meeting yesterday. Please send any follow-up comments/suggestions/corrections to the list. The minutes can also be found here: http://ipfix.doit.wisc.edu/IETF57/minutes.txt Thanks, Dave P.S. The slide shows (and also the draft minutes) are available at: http://ipfix.doit.wisc.edu/IETF57/ -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI --jI8keyz6grp/JLjh Content-Type: text/plain Content-Disposition: attachment; filename="minutes.txt" DRAFT Minutes of the IP Flow Information eXport (IPFIX) WG IETF 57, Vienna, Wednesday July 16, 2003 58 people in attendance Reported by Dave Plonka & Nevil Brownlee (co-chairs) based on notes from Greg Ruth. The meeting agenda and slides are available here: http://ipfix.doit.wisc.edu/IETF57/ [please see the agenda slides there for the sequence of topics: http://ipfix.doit.wisc.edu/IETF57/IETF57_IPFIX_agenda.ppt] -- Juergen Quittek presented the requirements draft "draft-ietf-ipfix-reqs-10.txt" and differences from -09 to -10. [see slides for details: http://ipfix.doit.wisc.edu/IETF57/IPFIX-reqs-IETF57.ppt] The draft says that confidentiality SHOULD be implemented and that anonymization MAY be. Current practice by the flow-export user community does not depend upon these features, hence the meeting's consensus was that the IPFIX requirements draft does not require them to be implemented. We discussed Allison Mankin's (Transport Area Director) suggestion that IPFIX make confidentiality and anonymization to both be REQUIRED (MUST). One participant noted that export restrictions (of encryption technology) might restrict the distribution of such an implementation. The few issues remaining will be discussed on the mailing list to produce the next revision in August. [If the changes continue to be minor edits, it will not require another WG last call.] -- Simon Leinen presented the changes to the individual draft "draft-leinen-ipfix-eval-contrib-01.txt" and differences from -00 to -01. [see slides for details: http://ipfix.doit.wisc.edu/IETF57/eval.pdf] His suggestion was that we accept this a Working Group document, go to WG last call soon, and submit it with a request to publish it as an Information RFC. This proposal met with agreement amongst those in attendence. [This would not be submitted until the requirements draft is resubmitted to IESG] -- Status of the four new WG drafts was reported by their respective editors: * Tanja Zseby presented the Applicability Statement draft. This is now a working group draft, based on her previous individual draft. [see slides for details: http://ipfix.doit.wisc.edu/IETF57/ipfix-as-ietf57.ppt] Reinaldo Penno presented the sub-topic of middleboxes. [see slides for details: http://ipfix.doit.wisc.edu/IETF57/ipfix_middleboxes.ppt] We discussed where this middlebox-related content should reside. It was suggested that perhaps it should be in a seperate draft. The chairs suggested that a "few [middlebox-related] paragraphs" should then be added to the architecture draft and that the seperate draft be initiated as the effort of an individual (to limit the amount of new work by the WG). A hum showed support for this. Juergen Quittek offered to write an individual draft. * Ganesh Sadasivan presented the Architecture draft: draft-ietf-ipfix-arch-01.txt [see slides for details: http://ipfix.doit.wisc.edu/IETF57/IPFIX_Architecture.ppt] Ganesh noted that the flow definition was modified to include encapsulated IP packets. It was undecided as to whether this was an improvement; discussion should continue in the mailing list. It was mentioned that the Denial-of-Service section regarding "network under attack" is unclear. It is perhaps just one case which might invoke overload behavior. This section needs to be clarified or reworked. The editors asked for more review and input on this draft via the mailing list. * Juergen Quittek presented the Information Model draft. [see slides for details: http://ipfix.doit.wisc.edu/IETF57/IPFIX-info-IETF57.ppt] Juergen mentioned that the the definitions named with the "ipdr" prefix should change. XML is being used to define the information elements, which are then parsed and rendered in an ASCII representation for the draft. The editors have some potential improvements to this process, and the audience didn't raise any objections to its use. The draft proposes to provide extensibility by using separate namespaces for sets of vendor-specific extensions. Such extensions would be identified using IANA-defined Enterprise numbers, as was proposed in early drafts of DIAMETER. It was noted that such an approach will require a good way of encoding the Enterprise numbers in IPFIX templates. Regarding the type space, the issue was raised about whether it should be defined/duplicated within the info model draft or be defined in the Info Model draft, with encodings specified in the Protocol draft. Nevil believes the latter is preferable. Discussion should continue. * Benoit Claise presented the IPFIX protocol specification draft. [see slides for details: http://ipfix.doit.wisc.edu/IETF57/IPFIX-protocol-IETF57.ppt] It is currently just the initial version; Benoit asked that the participants please review it and provide input [via the mailing list]. Mentioned that terminology should be consistent throughout the drafts. We discussed the use of "sync" packets. Jurgen suggested that sync information should be exported in options data records. This suggestion was well received. -- Three short slide-shows by folks interested in IPFIX were presented. * On behalf of Luca Deri (who could not attend), Nevil Brownlee presenting slides on "nFlow". [see slides for details: http://ipfix.doit.wisc.edu/IETF57/IETF_Vienna-nFlow.pdf] * Chang Kim presented a slide show about "Per-packet Recond Export Proposal (pktId)". [awaiting slides] * Maurizio Molina presented a proposal to add Flow Sampling to IPFIX. [see slides for details] -- The chairs reviewed the proposed various updates to WG Milestones. No changes were suggested so these will be submitted as listed. [see slides for details] -- $Id: minutes.txt,v 1.5 2003/07/17 11:35:33 dplonka Exp $ --jI8keyz6grp/JLjh-- -- 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 Jul 17 08:58:54 2003 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 IAA04673 for ; Thu, 17 Jul 2003 08:58:53 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19d89P-0006Z6-00 for ipfix-list@mil.doit.wisc.edu; Thu, 17 Jul 2003 07:46:23 -0500 Received: from [81.160.153.194] (helo=snorre.uninett.no) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19d89O-0006Yw-00 for ipfix@net.doit.wisc.edu; Thu, 17 Jul 2003 07:46:22 -0500 Received: from snorre.uninett.no (localhost.localdomain [127.0.0.1]) by snorre.uninett.no (8.12.8/8.12.8) with ESMTP id h6HCjukv003239; Thu, 17 Jul 2003 14:46:02 +0200 Received: from snorre.uninett.no (oak@localhost) by snorre.uninett.no (8.12.8/8.12.8/Submit) with ESMTP id h6HCjsPb003234; Thu, 17 Jul 2003 14:45:55 +0200 Message-Id: <200307171245.h6HCjsPb003234@snorre.uninett.no> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" cc: "'Nevil Brownlee'" , ipfix@net.doit.wisc.edu From: Olav.Kvittem@uninett.no Subject: Re: [ipfix] General comments on the IPFIX drafts In-reply-to: Your message of "Mon, 14 Jul 2003 05:52:00 PDT." <1D3D2C371FCBD947A7897FABBD3533A502960188@xsun01.ptp.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 2003 14:45:54 +0200 Precedence: bulk Sender: majordomo listserver n.brownlee@auckland.ac.nz said: > Ng1: Timestamp precision: > flowCreationTime and flowEndTime, in -info draft, are in dateTime > units, i.e. 'seconds normalized to GMT' (why not to UTC?). > Is this sufficient precision? jeff.meyer2@hp.com said: > Ng-1: I would suspect that second resolution time is insufficient > for > some applications. A large proportions of flow will be lasting in the order of a second. I would like to measure performance per flow to diagnose the traffic at an observation point. jeff.meyer2@hp.com said: > Millisecond resolution represented as a 64-bit > integer counter since EPOCH is a type currently defined by IPDR. At Gigabits per second there could be millions of packets a second. User response times should be subsecond (csec) and our measures one order less = msec. Since some devices have GPS clocks aming for microsec timestamps is not that utopic. A solution to the accuracy problem could be to give the length of the flow in microsecs explisitely in a own field, as precision of the internal clock could be better than the clock accuracy ? (would keep reporting from wondering when changing to DST ?). For other reports a msec precision flowCreationTime could be ok which is roughly about the accuracy of NTP. flowEndTime (if needed) can be when the record was concluded (inlcuding timeout) and the length of the flow could be computed by time of the last packet ? regards Olav > Nevil, > > Some comments on the first three issues: > > Ng-1: I would suspect that second resolution time is insufficient for > some applications. Millisecond resolution represented as a 64-bit > integer counter since EPOCH is a type currently defined by IPDR. > > Having this information item encoded explicitly would certainly > be more convenient from a collection (and info modelling) perspective > than the current NF model, which is relative to boot time. > > Ng-2: Having the protocol spec define the mappings from the base > type space in the info model makes sense. Network byte ordering > would be my expectation for fixed width quantities. For the > variable length fields, there seemed to be some discussion around > the use of 1,2 or 4 byte length indicators. There also remains > the question of whether or not padding is used for any sort of > word alignment. > > Ng-3: The namespace URI would be worth advancing. RFC3470 which talks > about use of XML in IETF drafts has some discussion in sections 4.9 > and 4.17. Although it sounds like policy here is still being > defined. Let me know if you would like me to contact the authors > to better understand the current state of affairs w/ IANA or if > you would like to do this. > > > Regards, > > Jeff Meyer > > > -----Original Message----- > From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] > Sent: Monday, July 14, 2003 1:15 AM > To: ipfix@net.doit.wisc.edu > Subject: [ipfix] General comments on the IPFIX drafts > > > > Hi all: > > These are some comments from me covering issues which don't fit neatly > into one or other of the IPFIX drafts. At this point we shouldn't be > raising 'big' new issues; I hope these are small-scale enough for us > to reach consensus on fairly quickly! > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > > Ng1: Timestamp precision: > flowCreationTime and flowEndTime, in -info draft, are in dateTime > units, i.e. 'seconds normalized to GMT' (why not to UTC?). > Is this sufficient precision? For example, RTFM used SNMP TimeTicks, > i.e. centiseconds (of sysUpTime). > There are three questions here: > a) How many bytes do we really need? If seconds is precise enough, > 4 bytes is fine. If we need more, or should we could go to 8? > b) If we feel that we can afford 8-byte precision, what time base > should we use, sysUpTime or time of day. Time of day would mean > that collectors didn't have to convert from sysUpTime. Can we > assume that Metering Processes will have a reliable time-of-day > clock? > c) Format of 8-byte times. The most common Unix one is (sec, usec). > (sec, nsec) is also widely available. My favourite is > (sec, binary fraction of sec) [NTP 64-bit timestamp, Section > 3.1 of RFC 1305], because you > can compute time differences with a single 64-bit subtraction. > > Ng2: Data representation in IPFIX packets. > The info model defines the data types for each field (IPFIX attribute), > I think we need the protocol document to specify how they're mapped > into the packet, e.g. 'data values are placed in their fields within > the packet in network byte order, i.e. most-significant byte first.' > Which data types can be variable-length? > If - as I suspect - it's only strings, could we agree to only have > variable-length strings (i.e. no fixed-length strings)? > > Ng3: IANA Namespace for XML Namespace URIs. WG Chairs (probably Nevil) > will follow up on this for the Info Model I-D. > > Ng4: Flow Sampling. This is mentioned in both the Requirements I-D > and the AS I-D. We need to decide how it should be covered in the > IPFIX drafts. > > ---------------------------------------------------------------------- > > > ------------------------------------------------- > This mail sent through University of Auckland > http://www.auckland.ac.nz/ > > -- > 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 Thu Jul 17 11:04:03 2003 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 LAA10765 for ; Thu, 17 Jul 2003 11:04:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19dA8O-00031o-00 for ipfix-list@mil.doit.wisc.edu; Thu, 17 Jul 2003 09:53:28 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 19dA8N-00031g-00 for ipfix@net.doit.wisc.edu; Thu, 17 Jul 2003 09:53:27 -0500 Received: (qmail 32785 invoked from network); 17 Jul 2003 14:53:25 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 17 Jul 2003 14:53:25 -0000 X-pair-Authenticated: 207.237.37.137 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h6HErP922075; Thu, 17 Jul 2003 10:53:25 -0400 From: "Carter Bullard" To: , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" Cc: "'Nevil Brownlee'" , Subject: RE: [ipfix] General comments on the IPFIX drafts Date: Thu, 17 Jul 2003 10:53:12 -0400 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A64F@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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6617E007@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Olav, We've used uSec precision UTC in Argus IP flow records for over 8 years now, and the customer base is pushing us to use nSec precision, especially when measuring at contemporary network rates. Today, Argus is used by some to measure intra-LAN network events, such as single hop one-way delay and RTT. At common speeds (10/100 Mbps eth and 802.11a/b), these events are in the 20-100 uSec time domains. Epoch time is not a good idea, as it is pretty much impossible to correlate records with any other event that is generated by any other application, and eliminates any benefit that vendors could have if they were using GPS to sync up devices. At 10Gbps, interpacket arrival times can easily be in the order of once every 0.0000000768 seconds (48 byte packets, 50% link utilization), and at OC-768, we're looking at network flow behavior that manifests itself well below uSec granularity. since there are so many 1 packet flows out there in the big bad Internet, it would be nice to at least be able to sort flows in arrival order. At least that is my opinion. While widely available clocks are just barely accurate at this level, consider that even Windows 2000 provides a nanoSecond clock to kernel and applications, so it's a simple metric and should be readily available. The cost of goods for a crystal that can provide nSec level precision is around $2.5 US, so switch and router manufacturers should have no quarrel with the requirement, and the Unix timeval data structure, has enough space to hold the value. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > Olav.Kvittem@uninett.no > Sent: Thursday, July 17, 2003 8:46 AM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] General comments on the IPFIX drafts > > > > n.brownlee@auckland.ac.nz said: > > Ng1: Timestamp precision: > > flowCreationTime and flowEndTime, in -info draft, are > in dateTime > > units, i.e. 'seconds normalized to GMT' (why not to UTC?). > > Is this sufficient precision? > > jeff.meyer2@hp.com said: > > Ng-1: I would suspect that second resolution time is insufficient > > for > > some applications. > > A large proportions of flow will be lasting in the order of a second. > I would like to measure performance per flow to diagnose the > traffic at an observation point. > > > jeff.meyer2@hp.com said: > > Millisecond resolution represented as a 64-bit > > integer counter since EPOCH is a type currently > defined by IPDR. > > At Gigabits per second there could be millions of packets a second. > User response times should be subsecond (csec) and our measures one > order less = msec. > > Since some devices have GPS clocks aming for microsec > timestamps is not > that utopic. > > A solution to the accuracy problem could be to give the length of > the flow in microsecs explisitely in a own field, as precision > of the internal clock could be better than the clock accuracy ? > (would keep reporting from wondering when changing to DST ?). > > For other reports a msec precision flowCreationTime could be ok > which is roughly about the accuracy of NTP. > flowEndTime (if needed) can be when the record was concluded > (inlcuding > timeout) > and the length of the flow could be computed by time of the > last packet ? > > > regards > Olav > > > Nevil, > > > > Some comments on the first three issues: > > > > Ng-1: I would suspect that second resolution time is > insufficient for > > some applications. Millisecond resolution represented > as a 64-bit > > integer counter since EPOCH is a type currently > defined by IPDR. > > > > Having this information item encoded explicitly would > certainly > > be more convenient from a collection (and info > modelling) perspective > > than the current NF model, which is relative to boot time. > > > > Ng-2: Having the protocol spec define the mappings from the base > > type space in the info model makes sense. Network > byte ordering > > would be my expectation for fixed width quantities. For the > > variable length fields, there seemed to be some > discussion around > > the use of 1,2 or 4 byte length indicators. There > also remains > > the question of whether or not padding is used for any sort of > > word alignment. > > > > Ng-3: The namespace URI would be worth advancing. > RFC3470 which talks > > about use of XML in IETF drafts has some discussion in > sections 4.9 > > and 4.17. Although it sounds like policy here is still being > > defined. Let me know if you would like me to contact > the authors > > to better understand the current state of affairs w/ IANA or if > > you would like to do this. > > > > > > Regards, > > > > Jeff Meyer > > > > > > -----Original Message----- > > From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] > > Sent: Monday, July 14, 2003 1:15 AM > > To: ipfix@net.doit.wisc.edu > > Subject: [ipfix] General comments on the IPFIX drafts > > > > > > > > Hi all: > > > > These are some comments from me covering issues which don't > fit neatly > > into one or other of the IPFIX drafts. At this point we > shouldn't be > > raising 'big' new issues; I hope these are small-scale enough for us > > to reach consensus on fairly quickly! > > > > Cheers, Nevil > > > > > -------------------------------------------------------------- > --------- > > Nevil Brownlee Director, Technology Development > > Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland > > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > > > > > > Ng1: Timestamp precision: > > flowCreationTime and flowEndTime, in -info draft, are > in dateTime > > units, i.e. 'seconds normalized to GMT' (why not to UTC?). > > Is this sufficient precision? For example, RTFM used > SNMP TimeTicks, > > i.e. centiseconds (of sysUpTime). > > There are three questions here: > > a) How many bytes do we really need? If seconds is > precise enough, > > 4 bytes is fine. If we need more, or should we > could go to 8? > > b) If we feel that we can afford 8-byte precision, > what time base > > should we use, sysUpTime or time of day. Time of > day would mean > > that collectors didn't have to convert from > sysUpTime. Can we > > assume that Metering Processes will have a reliable > time-of-day > > clock? > > c) Format of 8-byte times. The most common Unix one > is (sec, usec). > > (sec, nsec) is also widely available. My favourite is > > (sec, binary fraction of sec) [NTP 64-bit timestamp, Section > > 3.1 of RFC 1305], because you > > can compute time differences with a single 64-bit > subtraction. > > > > Ng2: Data representation in IPFIX packets. > > The info model defines the data types for each field > (IPFIX attribute), > > I think we need the protocol document to specify how > they're mapped > > into the packet, e.g. 'data values are placed in their > fields within > > the packet in network byte order, i.e. > most-significant byte first.' > > Which data types can be variable-length? > > If - as I suspect - it's only strings, could we agree > to only have > > variable-length strings (i.e. no fixed-length strings)? > > > > Ng3: IANA Namespace for XML Namespace URIs. WG Chairs > (probably Nevil) > > will follow up on this for the Info Model I-D. > > > > Ng4: Flow Sampling. This is mentioned in both the Requirements I-D > > and the AS I-D. We need to decide how it should be > covered in the > > IPFIX drafts. > > > > > ---------------------------------------------------------------------- > > > > > > ------------------------------------------------- > > This mail sent through University of Auckland > > http://www.auckland.ac.nz/ > > > > -- > > 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 Thu Jul 17 11:14:00 2003 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 LAA11161 for ; Thu, 17 Jul 2003 11:13:59 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19dAKa-0003Vt-00 for ipfix-list@mil.doit.wisc.edu; Thu, 17 Jul 2003 10:06:04 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 19dAKZ-0003Vm-00 for ipfix@net.doit.wisc.edu; Thu, 17 Jul 2003 10:06:04 -0500 Received: (qmail 39099 invoked from network); 17 Jul 2003 15:06:03 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 17 Jul 2003 15:06:03 -0000 X-pair-Authenticated: 207.237.37.137 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h6HF62922099; Thu, 17 Jul 2003 11:06:02 -0400 From: "Carter Bullard" To: , Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna Date: Thu, 17 Jul 2003 11:05:53 -0400 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A650@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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6617DFBD@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Gentle people, Thanks Dave for the timely minutes. Since there was no jabber access to the meeting for us that could not attend, the minutes are extremely helpful. I'd like to add my $0.02 worth on the confidentiality issue. Argus has had SASL based wireline encryption and strong authentication support for data access built into its pull data model for about 3 years now, and the demand and use of this facility is less than 0.1% of the user base. Not to say that at some time in the future, someone will think its important, currently there is little demand. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Dave Plonka > Sent: Thursday, July 17, 2003 7:40 AM > To: ipfix@net.doit.wisc.edu > Subject: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna > > > > IPFIXers, > > Please review the attached DRAFT minutes of the IPFIX meeting > yesterday. > Please send any follow-up comments/suggestions/corrections to > the list. > > The minutes can also be found here: > http://ipfix.doit.wisc.edu/IETF57/minutes.txt Thanks, Dave P.S. The slide shows (and also the draft minutes) are available at: http://ipfix.doit.wisc.edu/IETF57/ -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- 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 Jul 17 22:34:13 2003 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 WAA00754 for ; Thu, 17 Jul 2003 22:34:13 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19dKi2-0002AW-00 for ipfix-list@mil.doit.wisc.edu; Thu, 17 Jul 2003 21:10:58 -0500 Received: from [61.144.161.2] (helo=mta1.huawei.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19dKi0-0002A0-00 for ipfix@net.doit.wisc.edu; Thu, 17 Jul 2003 21:10:58 -0500 Received: from m19684 (mta1.huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0HI700AED745ER@mta1.huawei.com> for ipfix@net.doit.wisc.edu; Fri, 18 Jul 2003 10:04:54 +0800 (CST) Date: Fri, 18 Jul 2003 10:11:41 +0800 From: Miao Fuyou Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna In-reply-to: <5C8959A16A71B449AE793CF52FBBED6607A650@ptah.newyork.qosient.com> To: "'Carter Bullard'" Cc: ipfix@net.doit.wisc.edu Message-id: <001401c34cd1$edefd6e0$41426e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7BIT Maybe we need TLS to protect data if confidentiality is required. Anyway SASL is not so popular, it may discourage users. -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Carter Bullard Sent: Thursday, July 17, 2003 11:06 PM To: plonka@doit.wisc.edu; ipfix@net.doit.wisc.edu Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna Gentle people, Thanks Dave for the timely minutes. Since there was no jabber access to the meeting for us that could not attend, the minutes are extremely helpful. I'd like to add my $0.02 worth on the confidentiality issue. Argus has had SASL based wireline encryption and strong authentication support for data access built into its pull data model for about 3 years now, and the demand and use of this facility is less than 0.1% of the user base. Not to say that at some time in the future, someone will think its important, currently there is little demand. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Dave Plonka > Sent: Thursday, July 17, 2003 7:40 AM > To: ipfix@net.doit.wisc.edu > Subject: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna > > > > IPFIXers, > > Please review the attached DRAFT minutes of the IPFIX meeting > yesterday. > Please send any follow-up comments/suggestions/corrections to > the list. > > The minutes can also be found here: > http://ipfix.doit.wisc.edu/IETF57/minutes.txt Thanks, Dave P.S. The slide shows (and also the draft minutes) are available at: http://ipfix.doit.wisc.edu/IETF57/ -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- 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 Thu Jul 17 22:55:07 2003 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 WAA01325 for ; Thu, 17 Jul 2003 22:55:07 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19dL5H-0002us-00 for ipfix-list@mil.doit.wisc.edu; Thu, 17 Jul 2003 21:34:59 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 19dL5G-0002ul-00 for ipfix@net.doit.wisc.edu; Thu, 17 Jul 2003 21:34:58 -0500 Received: (qmail 93503 invoked from network); 18 Jul 2003 02:34:57 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 18 Jul 2003 02:34:57 -0000 X-pair-Authenticated: 207.237.37.137 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h6I2Yu931366; Thu, 17 Jul 2003 22:34:56 -0400 From: "Carter Bullard" To: "'Miao Fuyou'" Cc: Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna Date: Thu, 17 Jul 2003 22:34:49 -0400 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607EB5C@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.4510 In-reply-to: <5C8959A16A71B449AE793CF52FBBED6617E34E@ptah.newyork.qosient.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Surely if users aren't interested in confidentiality provided by algorithm X, they aren't going to magically get interested in confidentiality if it's provided by algorithm Y. I have received no complaints about the use of SASL. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Miao Fuyou > Sent: Thursday, July 17, 2003 10:12 PM > To: 'Carter Bullard' > Cc: ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna > > > > Maybe we need TLS to protect data if confidentiality is > required. Anyway > SASL is not so popular, it may discourage users. > > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On > Behalf Of Carter Bullard > Sent: Thursday, July 17, 2003 11:06 PM > To: plonka@doit.wisc.edu; ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna > > > Gentle people, > Thanks Dave for the timely minutes. Since there > was no jabber access to the meeting for us that could > not attend, the minutes are extremely helpful. > > I'd like to add my $0.02 worth on the confidentiality > issue. Argus has had SASL based wireline encryption > and strong authentication support for data access > built into its pull data model for about 3 years now, > and the demand and use of this facility is less than > 0.1% of the user base. Not to say that at some time > in the future, someone will think its important, > currently there is little demand. > > Carter > > > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Dave Plonka > > Sent: Thursday, July 17, 2003 7:40 AM > > To: ipfix@net.doit.wisc.edu > > Subject: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna > > > > > > > > IPFIXers, > > > > Please review the attached DRAFT minutes of the IPFIX meeting > > yesterday. > > Please send any follow-up comments/suggestions/corrections to > > the list. > > > > The minutes can also be found here: > > > http://ipfix.doit.wisc.edu/IETF57/minutes.txt > > Thanks, > Dave > > P.S. The slide shows (and also the draft minutes) are available at: > http://ipfix.doit.wisc.edu/IETF57/ -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- 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 Thu Jul 17 23:05:45 2003 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 XAA01547 for ; Thu, 17 Jul 2003 23:05:44 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19dLEd-0003Jd-00 for ipfix-list@mil.doit.wisc.edu; Thu, 17 Jul 2003 21:44:39 -0500 Received: from [61.144.161.2] (helo=mta0.huawei.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19dLEb-0003JY-00 for ipfix@net.doit.wisc.edu; Thu, 17 Jul 2003 21:44:38 -0500 Received: from m19684 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HI700ALL8VXOS@mta0.huawei.com> for ipfix@net.doit.wisc.edu; Fri, 18 Jul 2003 10:43:11 +0800 (CST) Date: Fri, 18 Jul 2003 10:45:33 +0800 From: Miao Fuyou Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna In-reply-to: <5C8959A16A71B449AE793CF52FBBED6607EB5C@ptah.newyork.qosient.com> To: "'Carter Bullard'" Cc: ipfix@net.doit.wisc.edu Message-id: <001501c34cd6$a9622640$41426e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7BIT If I don't care X, I don't complain X. If a system provides algorithm Z I am not familiar with, I don't care Z. Actually confidentiality is not important in the most of scenarios, I agree. -----Original Message----- From: Carter Bullard [mailto:carter@qosient.com] Sent: Friday, July 18, 2003 10:35 AM To: 'Miao Fuyou' Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna Surely if users aren't interested in confidentiality provided by algorithm X, they aren't going to magically get interested in confidentiality if it's provided by algorithm Y. I have received no complaints about the use of SASL. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Miao Fuyou > Sent: Thursday, July 17, 2003 10:12 PM > To: 'Carter Bullard' > Cc: ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna > > > > Maybe we need TLS to protect data if confidentiality is > required. Anyway > SASL is not so popular, it may discourage users. > > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On > Behalf Of Carter Bullard > Sent: Thursday, July 17, 2003 11:06 PM > To: plonka@doit.wisc.edu; ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna > > > Gentle people, > Thanks Dave for the timely minutes. Since there > was no jabber access to the meeting for us that could > not attend, the minutes are extremely helpful. > > I'd like to add my $0.02 worth on the confidentiality issue. Argus > has had SASL based wireline encryption and strong authentication > support for data access built into its pull data model for about 3 > years now, and the demand and use of this facility is less than > 0.1% of the user base. Not to say that at some time > in the future, someone will think its important, > currently there is little demand. > > Carter > > > > > -----Original Message----- > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On > > Behalf Of Dave Plonka > > Sent: Thursday, July 17, 2003 7:40 AM > > To: ipfix@net.doit.wisc.edu > > Subject: [ipfix] DRAFT IPFIX meeting minutes, 57th IETF, Vienna > > > > > > > > IPFIXers, > > > > Please review the attached DRAFT minutes of the IPFIX meeting > > yesterday. Please send any follow-up > > comments/suggestions/corrections to the list. > > > > The minutes can also be found here: > > > http://ipfix.doit.wisc.edu/IETF57/minutes.txt > > Thanks, > Dave > > P.S. The slide shows (and also the draft minutes) are available at: > http://ipfix.doit.wisc.edu/IETF57/ -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- 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 Fri Jul 18 01:54:34 2003 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 BAA05685 for ; Fri, 18 Jul 2003 01:54:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19dNyp-0001HE-00 for ipfix-list@mil.doit.wisc.edu; Fri, 18 Jul 2003 00:40:31 -0500 Received: from [212.216.176.185] (helo=vsmtp9.tin.it) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19dNyo-0001H5-00 for ipfix@net.doit.wisc.edu; Fri, 18 Jul 2003 00:40:30 -0500 Received: from vsmtp13.tin.it (212.216.176.207) by vsmtp9.tin.it (6.7.016) id 3F02F6E40004AA31; Fri, 18 Jul 2003 07:38:27 +0200 Received: from truciolo (80.180.147.20) by vsmtp13.tin.it (6.7.016) id 3F143DB60031779E; Fri, 18 Jul 2003 07:38:27 +0200 From: "Fulvio Risso" To: "Carter Bullard" , , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" Cc: "'Nevil Brownlee'" , Subject: RE: [ipfix] General comments on the IPFIX drafts Date: Fri, 18 Jul 2003 07:38:29 +0200 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A64F@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi. > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Carter Bullard > Sent: giovedi 17 luglio 2003 16.53 > To: Olav.Kvittem@uninett.no; 'MEYER,JEFFREY D (HP-Cupertino,ex1)' > Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] General comments on the IPFIX drafts > > > Hey Olav, > We've used uSec precision UTC in Argus IP flow > records for over 8 years now, and the customer base > is pushing us to use nSec precision, especially > when measuring at contemporary network rates. > Today, Argus is used by some to measure intra-LAN > network events, such as single hop one-way delay > and RTT. At common speeds (10/100 Mbps eth and > 802.11a/b), these events are in the 20-100 uSec > time domains. > > Epoch time is not a good idea, as it is pretty > much impossible to correlate records with any > other event that is generated by any other application, > and eliminates any benefit that vendors could have > if they were using GPS to sync up devices. > > At 10Gbps, interpacket arrival times can easily > be in the order of once every 0.0000000768 seconds > (48 byte packets, 50% link utilization), and at > OC-768, we're looking at network flow behavior that > manifests itself well below uSec granularity. > since there are so many 1 packet flows out there > in the big bad Internet, it would be nice to at least > be able to sort flows in arrival order. At least > that is my opinion. > > While widely available clocks are just barely accurate > at this level, consider that even Windows 2000 provides > a nanoSecond clock to kernel and applications, so it's Yes, but the cost for getting a timestamp with nanoSec precision is several microseconds. So, it is pretty much useless. There is no way to get precise nanoseconds in PCs, unless you have a GPS receiver. In any case, I agree with you that the standard should specify this kind of precision, no matter of how precixe can be workstations and routers in getting the timestamp. Cheers, fulvio > a simple metric and should be readily available. The > cost of goods for a crystal that can provide nSec level > precision is around $2.5 US, so switch and router > manufacturers should have no quarrel with the requirement, > and the Unix timeval data structure, has enough space > to hold the value. > > > Carter > > > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > > Olav.Kvittem@uninett.no > > Sent: Thursday, July 17, 2003 8:46 AM > > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > > Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu > > Subject: Re: [ipfix] General comments on the IPFIX drafts > > > > > > > > n.brownlee@auckland.ac.nz said: > > > Ng1: Timestamp precision: > > > flowCreationTime and flowEndTime, in -info draft, are > > in dateTime > > > units, i.e. 'seconds normalized to GMT' (why not to UTC?). > > > Is this sufficient precision? > > > > jeff.meyer2@hp.com said: > > > Ng-1: I would suspect that second resolution time is insufficient > > > for > > > some applications. > > > > A large proportions of flow will be lasting in the order of a second. > > I would like to measure performance per flow to diagnose the > > traffic at an observation point. > > > > > > jeff.meyer2@hp.com said: > > > Millisecond resolution represented as a 64-bit > > > integer counter since EPOCH is a type currently > > defined by IPDR. > > > > At Gigabits per second there could be millions of packets a second. > > User response times should be subsecond (csec) and our measures one > > order less = msec. > > > > Since some devices have GPS clocks aming for microsec > > timestamps is not > > that utopic. > > > > A solution to the accuracy problem could be to give the length of > > the flow in microsecs explisitely in a own field, as precision > > of the internal clock could be better than the clock accuracy ? > > (would keep reporting from wondering when changing to DST ?). > > > > For other reports a msec precision flowCreationTime could be ok > > which is roughly about the accuracy of NTP. > > flowEndTime (if needed) can be when the record was concluded > > (inlcuding > > timeout) > > and the length of the flow could be computed by time of the > > last packet ? > > > > > > regards > > Olav > > > > > Nevil, > > > > > > Some comments on the first three issues: > > > > > > Ng-1: I would suspect that second resolution time is > > insufficient for > > > some applications. Millisecond resolution represented > > as a 64-bit > > > integer counter since EPOCH is a type currently > > defined by IPDR. > > > > > > Having this information item encoded explicitly would > > certainly > > > be more convenient from a collection (and info > > modelling) perspective > > > than the current NF model, which is relative to boot time. > > > > > > Ng-2: Having the protocol spec define the mappings from the base > > > type space in the info model makes sense. Network > > byte ordering > > > would be my expectation for fixed width quantities. For the > > > variable length fields, there seemed to be some > > discussion around > > > the use of 1,2 or 4 byte length indicators. There > > also remains > > > the question of whether or not padding is used for any sort of > > > word alignment. > > > > > > Ng-3: The namespace URI would be worth advancing. > > RFC3470 which talks > > > about use of XML in IETF drafts has some discussion in > > sections 4.9 > > > and 4.17. Although it sounds like policy here is still being > > > defined. Let me know if you would like me to contact > > the authors > > > to better understand the current state of affairs w/ IANA or if > > > you would like to do this. > > > > > > > > > Regards, > > > > > > Jeff Meyer > > > > > > > > > -----Original Message----- > > > From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] > > > Sent: Monday, July 14, 2003 1:15 AM > > > To: ipfix@net.doit.wisc.edu > > > Subject: [ipfix] General comments on the IPFIX drafts > > > > > > > > > > > > Hi all: > > > > > > These are some comments from me covering issues which don't > > fit neatly > > > into one or other of the IPFIX drafts. At this point we > > shouldn't be > > > raising 'big' new issues; I hope these are small-scale enough for us > > > to reach consensus on fairly quickly! > > > > > > Cheers, Nevil > > > > > > > > -------------------------------------------------------------- > > --------- > > > Nevil Brownlee Director, Technology Development > > > Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland > > > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > > > > > > > > > > Ng1: Timestamp precision: > > > flowCreationTime and flowEndTime, in -info draft, are > > in dateTime > > > units, i.e. 'seconds normalized to GMT' (why not to UTC?). > > > Is this sufficient precision? For example, RTFM used > > SNMP TimeTicks, > > > i.e. centiseconds (of sysUpTime). > > > There are three questions here: > > > a) How many bytes do we really need? If seconds is > > precise enough, > > > 4 bytes is fine. If we need more, or should we > > could go to 8? > > > b) If we feel that we can afford 8-byte precision, > > what time base > > > should we use, sysUpTime or time of day. Time of > > day would mean > > > that collectors didn't have to convert from > > sysUpTime. Can we > > > assume that Metering Processes will have a reliable > > time-of-day > > > clock? > > > c) Format of 8-byte times. The most common Unix one > > is (sec, usec). > > > (sec, nsec) is also widely available. My favourite is > > > (sec, binary fraction of sec) [NTP 64-bit timestamp, Section > > > 3.1 of RFC 1305], because you > > > can compute time differences with a single 64-bit > > subtraction. > > > > > > Ng2: Data representation in IPFIX packets. > > > The info model defines the data types for each field > > (IPFIX attribute), > > > I think we need the protocol document to specify how > > they're mapped > > > into the packet, e.g. 'data values are placed in their > > fields within > > > the packet in network byte order, i.e. > > most-significant byte first.' > > > Which data types can be variable-length? > > > If - as I suspect - it's only strings, could we agree > > to only have > > > variable-length strings (i.e. no fixed-length strings)? > > > > > > Ng3: IANA Namespace for XML Namespace URIs. WG Chairs > > (probably Nevil) > > > will follow up on this for the Info Model I-D. > > > > > > Ng4: Flow Sampling. This is mentioned in both the Requirements I-D > > > and the AS I-D. We need to decide how it should be > > covered in the > > > IPFIX drafts. > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > ------------------------------------------------- > > > This mail sent through University of Auckland > > > http://www.auckland.ac.nz/ > > > > > > -- > > > 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/ -- 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 Jul 18 02:43:29 2003 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 CAA19128 for ; Fri, 18 Jul 2003 02:43:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19dOey-0002mq-00 for ipfix-list@mil.doit.wisc.edu; Fri, 18 Jul 2003 01:24:04 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 19dOex-0002mj-00 for ipfix@net.doit.wisc.edu; Fri, 18 Jul 2003 01:24:03 -0500 Received: (qmail 33347 invoked from network); 18 Jul 2003 06:24:02 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 18 Jul 2003 06:24:02 -0000 X-pair-Authenticated: 207.237.37.137 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h6I6O1902261; Fri, 18 Jul 2003 02:24:02 -0400 From: "Carter Bullard" To: "'Fulvio Risso'" , , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" Cc: "'Nevil Brownlee'" , Subject: RE: [ipfix] General comments on the IPFIX drafts Date: Fri, 18 Jul 2003 02:23:51 -0400 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A652@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.4510 In-reply-to: <5C8959A16A71B449AE793CF52FBBED6617E418@ptah.newyork.qosient.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Buon Giorno Fulvio, Millie gracie!!! Precision is not really the number one thing here, IMHO. The real issue is that you need a non-recurring counter that can be used to order network events. This could be accomplished using a simple packet counter, but if you go that route, you lose the additional properties that you get from basing the counter on time. If you're microsecond delay in getting to the clock is a constant, then the number is valid for this ordering purpose. It may not be sync'd but its good enough to do nSec interpacket arrival times, and good enough to indicate that the ICMP packet came a few 100 nSecs after the TCP RST packet in the stream. At least one vendor is shipping nSec GPS sync'd packet capture devices today. A little pricey, yes, but if you want to do good stuff, you have to spend some money. IPFIX should at least support the current state of the art in flow record generation and reporting. Hope all is well!!! Ciao! Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Fulvio Risso > Sent: Friday, July 18, 2003 1:38 AM > To: Carter Bullard; Olav.Kvittem@uninett.no; 'MEYER,JEFFREY D > (HP-Cupertino,ex1)' > Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] General comments on the IPFIX drafts > > > Hi. > > > -----Original Message----- > > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > > Of Carter Bullard > > Sent: giovedi 17 luglio 2003 16.53 > > To: Olav.Kvittem@uninett.no; 'MEYER,JEFFREY D (HP-Cupertino,ex1)' > > Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu > > Subject: RE: [ipfix] General comments on the IPFIX drafts > > > > > > Hey Olav, > > We've used uSec precision UTC in Argus IP flow > > records for over 8 years now, and the customer base > > is pushing us to use nSec precision, especially > > when measuring at contemporary network rates. > > Today, Argus is used by some to measure intra-LAN > > network events, such as single hop one-way delay > > and RTT. At common speeds (10/100 Mbps eth and > > 802.11a/b), these events are in the 20-100 uSec > > time domains. > > > > Epoch time is not a good idea, as it is pretty > > much impossible to correlate records with any > > other event that is generated by any other application, > > and eliminates any benefit that vendors could have > > if they were using GPS to sync up devices. > > > > At 10Gbps, interpacket arrival times can easily > > be in the order of once every 0.0000000768 seconds > > (48 byte packets, 50% link utilization), and at > > OC-768, we're looking at network flow behavior that > > manifests itself well below uSec granularity. > > since there are so many 1 packet flows out there > > in the big bad Internet, it would be nice to at least > > be able to sort flows in arrival order. At least > > that is my opinion. > > > > While widely available clocks are just barely accurate > > at this level, consider that even Windows 2000 provides > > a nanoSecond clock to kernel and applications, so it's > > Yes, but the cost for getting a timestamp with nanoSec > precision is several > microseconds. > So, it is pretty much useless. > There is no way to get precise nanoseconds in PCs, unless you > have a GPS > receiver. > > In any case, I agree with you that the standard should > specify this kind of > precision, no matter of how precixe can be workstations and routers in > getting the timestamp. > > Cheers, > > fulvio > > > a simple metric and should be readily available. The > > cost of goods for a crystal that can provide nSec level > > precision is around $2.5 US, so switch and router > > manufacturers should have no quarrel with the requirement, > > and the Unix timeval data structure, has enough space > > to hold the value. > > > > > > Carter > > > > > > > > > -----Original Message----- > > > From: majordomo listserver > > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > > > Olav.Kvittem@uninett.no > > > Sent: Thursday, July 17, 2003 8:46 AM > > > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > > > Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu > > > Subject: Re: [ipfix] General comments on the IPFIX drafts > > > > > > > > > > > > n.brownlee@auckland.ac.nz said: > > > > Ng1: Timestamp precision: > > > > flowCreationTime and flowEndTime, in -info draft, are > > > in dateTime > > > > units, i.e. 'seconds normalized to GMT' (why not to UTC?). > > > > Is this sufficient precision? > > > > > > jeff.meyer2@hp.com said: > > > > Ng-1: I would suspect that second resolution time is > insufficient > > > > for > > > > some applications. > > > > > > A large proportions of flow will be lasting in the order > of a second. > > > I would like to measure performance per flow to diagnose the > > > traffic at an observation point. > > > > > > > > > jeff.meyer2@hp.com said: > > > > Millisecond resolution represented as a 64-bit > > > > integer counter since EPOCH is a type currently > > > defined by IPDR. > > > > > > At Gigabits per second there could be millions of packets > a second. > > > User response times should be subsecond (csec) and our > measures one > > > order less = msec. > > > > > > Since some devices have GPS clocks aming for microsec > > > timestamps is not > > > that utopic. > > > > > > A solution to the accuracy problem could be to give the length of > > > the flow in microsecs explisitely in a own field, as precision > > > of the internal clock could be better than the clock accuracy ? > > > (would keep reporting from wondering when changing to DST ?). > > > > > > For other reports a msec precision flowCreationTime could be ok > > > which is roughly about the accuracy of NTP. > > > flowEndTime (if needed) can be when the record was concluded > > > (inlcuding > > > timeout) > > > and the length of the flow could be computed by time of the > > > last packet ? > > > > > > > > > regards > > > Olav > > > > > > > Nevil, > > > > > > > > Some comments on the first three issues: > > > > > > > > Ng-1: I would suspect that second resolution time is > > > insufficient for > > > > some applications. Millisecond resolution represented > > > as a 64-bit > > > > integer counter since EPOCH is a type currently > > > defined by IPDR. > > > > > > > > Having this information item encoded explicitly would > > > certainly > > > > be more convenient from a collection (and info > > > modelling) perspective > > > > than the current NF model, which is relative to boot time. > > > > > > > > Ng-2: Having the protocol spec define the mappings > from the base > > > > type space in the info model makes sense. Network > > > byte ordering > > > > would be my expectation for fixed width > quantities. For the > > > > variable length fields, there seemed to be some > > > discussion around > > > > the use of 1,2 or 4 byte length indicators. There > > > also remains > > > > the question of whether or not padding is used for > any sort of > > > > word alignment. > > > > > > > > Ng-3: The namespace URI would be worth advancing. > > > RFC3470 which talks > > > > about use of XML in IETF drafts has some discussion in > > > sections 4.9 > > > > and 4.17. Although it sounds like policy here is > still being > > > > defined. Let me know if you would like me to contact > > > the authors > > > > to better understand the current state of affairs > w/ IANA or if > > > > you would like to do this. > > > > > > > > > > > > Regards, > > > > > > > > Jeff Meyer > > > > > > > > > > > > -----Original Message----- > > > > From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] > > > > Sent: Monday, July 14, 2003 1:15 AM > > > > To: ipfix@net.doit.wisc.edu > > > > Subject: [ipfix] General comments on the IPFIX drafts > > > > > > > > > > > > > > > > Hi all: > > > > > > > > These are some comments from me covering issues which don't > > > fit neatly > > > > into one or other of the IPFIX drafts. At this point we > > > shouldn't be > > > > raising 'big' new issues; I hope these are small-scale > enough for us > > > > to reach consensus on fairly quickly! > > > > > > > > Cheers, Nevil > > > > > > > > > > > -------------------------------------------------------------- > > > --------- > > > > Nevil Brownlee Director, > Technology Development > > > > Phone: +64 9 373 7599 x88941 ITSS, The > University of Auckland > > > > FAX: +64 9 373 7021 Private Bag 92019, > Auckland, New Zealand > > > > > > > > > > > > > > > > Ng1: Timestamp precision: > > > > flowCreationTime and flowEndTime, in -info draft, are > > > in dateTime > > > > units, i.e. 'seconds normalized to GMT' (why not to UTC?). > > > > Is this sufficient precision? For example, RTFM used > > > SNMP TimeTicks, > > > > i.e. centiseconds (of sysUpTime). > > > > There are three questions here: > > > > a) How many bytes do we really need? If seconds is > > > precise enough, > > > > 4 bytes is fine. If we need more, or should we > > > could go to 8? > > > > b) If we feel that we can afford 8-byte precision, > > > what time base > > > > should we use, sysUpTime or time of day. Time of > > > day would mean > > > > that collectors didn't have to convert from > > > sysUpTime. Can we > > > > assume that Metering Processes will have a reliable > > > time-of-day > > > > clock? > > > > c) Format of 8-byte times. The most common Unix one > > > is (sec, usec). > > > > (sec, nsec) is also widely available. My favourite is > > > > (sec, binary fraction of sec) [NTP 64-bit > timestamp, Section > > > > 3.1 of RFC 1305], because you > > > > can compute time differences with a single 64-bit > > > subtraction. > > > > > > > > Ng2: Data representation in IPFIX packets. > > > > The info model defines the data types for each field > > > (IPFIX attribute), > > > > I think we need the protocol document to specify how > > > they're mapped > > > > into the packet, e.g. 'data values are placed in their > > > fields within > > > > the packet in network byte order, i.e. > > > most-significant byte first.' > > > > Which data types can be variable-length? > > > > If - as I suspect - it's only strings, could we agree > > > to only have > > > > variable-length strings (i.e. no fixed-length strings)? > > > > > > > > Ng3: IANA Namespace for XML Namespace URIs. WG Chairs > > > (probably Nevil) > > > > will follow up on this for the Info Model I-D. > > > > > > > > Ng4: Flow Sampling. This is mentioned in both the > Requirements I-D > > > > and the AS I-D. We need to decide how it should be > > > covered in the > > > > IPFIX drafts. > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > ------------------------------------------------- > > > > This mail sent through University of Auckland > > > > http://www.auckland.ac.nz/ > > > > > > > > -- > > > > 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/ > > > -- > 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 Thu Jul 24 22:17:42 2003 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 WAA08673 for ; Thu, 24 Jul 2003 22:17:41 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19frgp-0003Wq-00 for ipfix-list@mil.doit.wisc.edu; Thu, 24 Jul 2003 20:48:11 -0500 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19frgo-0003Wj-00 for ipfix@net.doit.wisc.edu; Thu, 24 Jul 2003 20:48:10 -0500 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19frgn-000Iej-4v; Thu, 24 Jul 2003 18:48:09 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2003 18:48:08 -0700 To: Allison Mankin Cc: ipfix wg Subject: [ipfix] Re: IPFIX: Requirements draft back to IESG References: Message-Id: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > They don't make anonymization and confidentiality features > mandatory-to-implement requirements of the eventual IPFIX > protocol. I find the language they do provide to be an > avoidance of acknowledgement that there's a stronger than SHOULD > or MAY _implement_ requirement for these features for IPFIX. > ... > The change made for my comment on usage-based accounting is > perfect, but I took some time to think over the other two > changes and I think they do not work. The document still leaves > it the case that ipfix implementations will generally have a > strong option not to implement anonymization, and will have some > choice not to implement confidentiality. These are not > mandatory-to-use, but the requirements should be indicating they > are recommended or mandatory-to-implement. From what I know of > data sets in measurement research, I find it very hard to > believe that these requirements should be set so loosely on the > protocol overall (yes, for many apps of the protocol, they will > be looser, and they will not be used). allison, as far as i can see, your point is valid and worth fixing, and have held the doc awaiting a new rev. 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 Wed Jul 30 13:13:54 2003 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 NAA08675 for ; Wed, 30 Jul 2003 13:13:54 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19huBl-0005Fp-00 for ipfix-list@mil.doit.wisc.edu; Wed, 30 Jul 2003 11:52:33 -0500 Received: from [130.216.191.4] (helo=mailhost2.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19huBj-0005Fd-00 for ipfix@net.doit.wisc.edu; Wed, 30 Jul 2003 11:52:31 -0500 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h6UGqTaB010513 for ; Thu, 31 Jul 2003 04:52:29 +1200 (NZST) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR) with ESMTP id ASV18385; Thu, 31 Jul 2003 04:52:29 +1200 (NZST) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h6UGqSx09272 for ipfix@net.doit.wisc.edu; Thu, 31 Jul 2003 04:52:28 +1200 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from dyn54.caida.org (dyn54.caida.org [192.172.226.54]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Thu, 31 Jul 2003 04:52:28 +1200 Message-ID: <1059583948.419d0eb2488eb@hotlava.auckland.ac.nz> Date: Thu, 31 Jul 2003 04:52:28 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Requirements: Encryption and Anonymozation MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 192.172.226.54 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello all: I've been thinking about Allison's rejection of our Anonymization and Encrytpion SHOULD implement position. Allison (supported by Randy) believes that they should be 'MUST implement's, on the grounds that if they were, people would use them. My first thought was 'IPFIX charter says "standardize existing practice",' but I checked it, and it doesn't actually say that. It does say we'll * Identify and address any security privacy concerns affecting flow data. Determine technology for securing the flow information export data, e.g. TLS. so we clearly have to address encryption. We didn't mention anonymization in the charter though, it just crept in to the Requirements draft. In an attempt to move forward, I've had some email discussions with the Requirements Draft editors and co-chairs. Based on that, I propose the following: a) A fair proportion of users probably would use encryption to get their IPFIX data safely across the Internet. We've said all along that we'd use IPSEC or IPSEC for that, rather than try to do it at the application layer in IPFIX. So ... we should write a 'requirements' sentence saying that "IPFIX implementations MUST provide for encryption of exported IPFIX data, e.g. by using IPSEC or TLS." [We need to verify that TLS would be suitable for this.] b) For anonymization, we should remove any mention of it from the Requirements Draft, because: - IPFIX data will normally be collected by network operators for traffic engineering and/or accounting purposes. In both these cases raw (un-anonymized) data is needed; again, since IPFIX data can be encrypted in transit, there is no operational need for further privacy protection. - Although it may be useful for operators to anonymize traffic data before giving researchers access to it, that is easily done (as at present) using anonymization tools. - At this stage there are several anonymoization tools one could use. tcpdpriv is the most common, but it has known vulnerabilities. Crypto-PaN is probably better, but has high processor demands. Overall, good algorithms for anonymization are still a research issue, not something which is ready to go into production network devices. In a more detailed comment on 'privacy' vs 'security', Sebastian Zander said: > I think that IPFIX must deal with privacy issues somehow. Afterall we > are standardizing something which could be used to get a detailed log > of a users activities. > > Different countries may have completly different laws on privacy. But > there are laws (e.g. in the EU). So what may be a privacy violation in one > country may not be a privacy violation in another. > > In general i agree to your proposal. However i think some of the arguments > against a MUST are not too strong. If i have a flat rate why would my > provider need to record my flow data? What would prevent someone to give > a 3rd party access to ipfix informtion? Technically nothing... > (but there are laws). > > I think there are differences between security and privacy which justify > a different treatment IMO: > - Security/encryption can *always* be used for ipfix although it means > using more resources etc. whereas privacy/anonymization can *not* be > used in any case (e.g. in case of accounting srcip must not be > anonymized). > - We have to assume that in those cases the people who use ipfix comply to > the relevant privacy laws. Privacy can't be enforced by the protocol > itself, only by laws or social norms. > - The scenarios where people would like to access ipfix data and can do > this only through the use of anonymization are currently rare and out > of scope(?). > - Encryption techniques are more mature and widely understood whereas > anonymization techniques are still research and therefore its more > difficult to put them into a standard now. > - I think its not the scope of this group to develop and/or standard > anonymization techniques. There are standards for encryption but for > anonymization? > > Maybe it would be a good idea to have some text on privacy considerations > in the draft (similar to security considerations). I like the idea of a 'privacy considerations' section, probably in the Architecture draft (rather than the Requirements draft). What do you think? Lets have some feedback on the list, please, just a line saying 'yes for encryption, no for anonymization' would be fine. But we want to get the Requirements Draft finished, so please respond quickly! Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- 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 Jul 30 13:21:26 2003 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 NAA09186 for ; Wed, 30 Jul 2003 13:21:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19huKK-0005b3-00 for ipfix-list@mil.doit.wisc.edu; Wed, 30 Jul 2003 12:01:24 -0500 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19huKJ-0005ax-00 for ipfix@net.doit.wisc.edu; Wed, 30 Jul 2003 12:01:24 -0500 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19huKH-0008Uj-Gz; Wed, 30 Jul 2003 10:01:21 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 Jul 2003 10:01:21 -0700 To: Nevil Brownlee Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Requirements: Encryption and Anonymozation References: <1059583948.419d0eb2488eb@hotlava.auckland.ac.nz> Message-Id: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > I've been thinking about Allison's rejection of our Anonymization > and Encrytpion SHOULD implement position. > Allison (supported by Randy) believes that they should be 'MUST > implement's, on the grounds that if they were, people would use them. s/would/could be assured that they could if they wished to/ this is the key point with mandatory to implement but not mandatory to use 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 Wed Jul 30 13:39:23 2003 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 NAA09812 for ; Wed, 30 Jul 2003 13:39:22 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19huYH-00066Y-00 for ipfix-list@mil.doit.wisc.edu; Wed, 30 Jul 2003 12:15:49 -0500 Received: from atlrel8.hp.com ([156.153.255.206]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19huYG-00066T-00 for ipfix@net.doit.wisc.edu; Wed, 30 Jul 2003 12:15:48 -0500 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel8.hp.com (Postfix) with ESMTP id EB36A1C01162; Wed, 30 Jul 2003 13:15:47 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id A3EE81C00B97; Wed, 30 Jul 2003 13:15:47 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Jul 2003 13:15:47 -0400 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960214@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Nevil Brownlee'" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Requirements: Encryption and Anonymozation Date: Wed, 30 Jul 2003 13:15:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver Nevil, I agree with statements on anonymization. I.e. it is still a research area. The flows are staying w/in the operators domain, so what they collect must have privacy considerations addressed before sharing (providing aggregate summaries to other parties is one way to effectively remove individual information). I agree with the approach on encryption of communication, although I am less certain how frequently it will be used. Regards, Jeff Meyer -----Original Message----- From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] Sent: Wednesday, July 30, 2003 9:52 AM To: ipfix@net.doit.wisc.edu Subject: [ipfix] Requirements: Encryption and Anonymozation Hello all: I've been thinking about Allison's rejection of our Anonymization and Encrytpion SHOULD implement position. Allison (supported by Randy) believes that they should be 'MUST implement's, on the grounds that if they were, people would use them. My first thought was 'IPFIX charter says "standardize existing practice",' but I checked it, and it doesn't actually say that. It does say we'll * Identify and address any security privacy concerns affecting flow data. Determine technology for securing the flow information export data, e.g. TLS. so we clearly have to address encryption. We didn't mention anonymization in the charter though, it just crept in to the Requirements draft. In an attempt to move forward, I've had some email discussions with the Requirements Draft editors and co-chairs. Based on that, I propose the following: a) A fair proportion of users probably would use encryption to get their IPFIX data safely across the Internet. We've said all along that we'd use IPSEC or IPSEC for that, rather than try to do it at the application layer in IPFIX. So ... we should write a 'requirements' sentence saying that "IPFIX implementations MUST provide for encryption of exported IPFIX data, e.g. by using IPSEC or TLS." [We need to verify that TLS would be suitable for this.] b) For anonymization, we should remove any mention of it from the Requirements Draft, because: - IPFIX data will normally be collected by network operators for traffic engineering and/or accounting purposes. In both these cases raw (un-anonymized) data is needed; again, since IPFIX data can be encrypted in transit, there is no operational need for further privacy protection. - Although it may be useful for operators to anonymize traffic data before giving researchers access to it, that is easily done (as at present) using anonymization tools. - At this stage there are several anonymoization tools one could use. tcpdpriv is the most common, but it has known vulnerabilities. Crypto-PaN is probably better, but has high processor demands. Overall, good algorithms for anonymization are still a research issue, not something which is ready to go into production network devices. In a more detailed comment on 'privacy' vs 'security', Sebastian Zander said: > I think that IPFIX must deal with privacy issues somehow. Afterall we > are standardizing something which could be used to get a detailed log > of a users activities. > > Different countries may have completly different laws on privacy. But > there are laws (e.g. in the EU). So what may be a privacy violation in one > country may not be a privacy violation in another. > > In general i agree to your proposal. However i think some of the arguments > against a MUST are not too strong. If i have a flat rate why would my > provider need to record my flow data? What would prevent someone to give > a 3rd party access to ipfix informtion? Technically nothing... > (but there are laws). > > I think there are differences between security and privacy which justify > a different treatment IMO: > - Security/encryption can *always* be used for ipfix although it means > using more resources etc. whereas privacy/anonymization can *not* be > used in any case (e.g. in case of accounting srcip must not be > anonymized). > - We have to assume that in those cases the people who use ipfix comply to > the relevant privacy laws. Privacy can't be enforced by the protocol > itself, only by laws or social norms. > - The scenarios where people would like to access ipfix data and can do > this only through the use of anonymization are currently rare and out > of scope(?). > - Encryption techniques are more mature and widely understood whereas > anonymization techniques are still research and therefore its more > difficult to put them into a standard now. > - I think its not the scope of this group to develop and/or standard > anonymization techniques. There are standards for encryption but for > anonymization? > > Maybe it would be a good idea to have some text on privacy considerations > in the draft (similar to security considerations). I like the idea of a 'privacy considerations' section, probably in the Architecture draft (rather than the Requirements draft). What do you think? Lets have some feedback on the list, please, just a line saying 'yes for encryption, no for anonymization' would be fine. But we want to get the Requirements Draft finished, so please respond quickly! Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- 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 Jul 30 14:05:43 2003 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 OAA11089 for ; Wed, 30 Jul 2003 14:05:43 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19hvCt-0007aV-00 for ipfix-list@mil.doit.wisc.edu; Wed, 30 Jul 2003 12:57:47 -0500 Received: from login.caida.org ([192.172.226.78]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19hvCs-0007aM-00 for ipfix@net.doit.wisc.edu; Wed, 30 Jul 2003 12:57:46 -0500 Received: from login.caida.org (localhost [127.0.0.1]) by login.caida.org (8.12.9/8.12.9) with ESMTP id h6UHvg2e082870 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 30 Jul 2003 10:57:42 -0700 (PDT) Received: (from dmoore@localhost) by login.caida.org (8.12.9/8.12.9/Submit) id h6UHvgu6082868; Wed, 30 Jul 2003 10:57:42 -0700 (PDT) Date: Wed, 30 Jul 2003 10:57:42 -0700 From: David Moore To: Nevil Brownlee Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Requirements: Encryption and Anonymozation Message-ID: <20030730105742.Z78801@login.caida.org> References: <1059583948.419d0eb2488eb@hotlava.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1059583948.419d0eb2488eb@hotlava.auckland.ac.nz> User-Agent: Mutt/1.3.23i Precedence: bulk Sender: majordomo listserver On Thu, Jul 31, 2003 at 04:52:28AM +1200, Nevil Brownlee wrote: > a) A fair proportion of users probably would use encryption to > get their IPFIX data safely across the Internet. We've said > all along that we'd use IPSEC or IPSEC for that, rather than > try to do it at the application layer in IPFIX. So ... > we should write a 'requirements' sentence saying that "IPFIX > implementations MUST provide for encryption of exported IPFIX > data, e.g. by using IPSEC or TLS." [We need to verify that > TLS would be suitable for this.] How do IPSEC and TLS interact with not using TCP as the transport protocol? For IPSEC, I presume you just tunnel SCTP in it since it is packet based, but I have no idea how you'd do TLS with SCTP. Probably saying that they MUST provide for encryption is fine. It's just likely that the preferred format may come down related to if there is a mandatory minimal transport protocol to be supported. Also, as written, implementations might chose to do encryption in some proprietary way and therefore prevent interoperability. Although, obviously one would hope they wouldn't. > b) For anonymization, we should remove any mention of it from > the Requirements Draft, because: In a perfect world, I'd like to see ipfix support anonymization, but I'm not sure what the right approach to suggest is. And I'm not sure that I really like the idea that by having a 'MUST support anonymization", that every vendor will go off an implement an ad-hoc anonymization scheme. -- david -- 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 Jul 30 15:03:57 2003 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 PAA13015 for ; Wed, 30 Jul 2003 15:03:57 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19hw5K-0001fJ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 30 Jul 2003 13:54:02 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19hw5J-0001f7-00 for ipfix@net.doit.wisc.edu; Wed, 30 Jul 2003 13:54:01 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h6UIrsLX003092; Wed, 30 Jul 2003 13:53:54 -0500 (CDT) Message-ID: <3F281441.C8ABC33E@alcatel.com> Date: Wed, 30 Jul 2003 13:53:53 -0500 From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: "'Nevil Brownlee'" , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Requirements: Encryption and Anonymozation References: <1D3D2C371FCBD947A7897FABBD3533A502960214@xsun01.ptp.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I am not sure if the issue is having IPFIX anonymize the packets in the collected flows. I think the real issue is: can IPFIX handle anonymized packets? It may be be able to. I just don't know. Regards, Alex. "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: > Nevil, > > I agree with statements on anonymization. I.e. it is still a research > area. The flows are staying w/in the operators domain, so what they collect > must have privacy considerations addressed before sharing (providing > aggregate summaries to other parties is one way to effectively remove > individual information). > > I agree with the approach on encryption of communication, although I am > less certain how frequently it will be used. > > Regards, > > Jeff Meyer > > -----Original Message----- > From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] > Sent: Wednesday, July 30, 2003 9:52 AM > To: ipfix@net.doit.wisc.edu > Subject: [ipfix] Requirements: Encryption and Anonymozation > > Hello all: > > I've been thinking about Allison's rejection of our Anonymization > and Encrytpion SHOULD implement position. > Allison (supported by Randy) believes that they should be 'MUST > implement's, on the grounds that if they were, people would use them. > > My first thought was 'IPFIX charter says "standardize existing > practice",' but I checked it, and it doesn't actually say that. > It does say we'll > * Identify and address any security privacy concerns affecting > flow data. Determine technology for securing the flow information > export data, e.g. TLS. > so we clearly have to address encryption. We didn't mention > anonymization in the charter though, it just crept in to the > Requirements draft. > > In an attempt to move forward, I've had some email discussions > with the Requirements Draft editors and co-chairs. Based on that, > I propose the following: > > a) A fair proportion of users probably would use encryption to > get their IPFIX data safely across the Internet. We've said > all along that we'd use IPSEC or IPSEC for that, rather than > try to do it at the application layer in IPFIX. So ... > we should write a 'requirements' sentence saying that "IPFIX > implementations MUST provide for encryption of exported IPFIX > data, e.g. by using IPSEC or TLS." [We need to verify that > TLS would be suitable for this.] > > b) For anonymization, we should remove any mention of it from > the Requirements Draft, because: > - IPFIX data will normally be collected by network operators > for traffic engineering and/or accounting purposes. In both > these cases raw (un-anonymized) data is needed; again, since > IPFIX data can be encrypted in transit, there is no operational > need for further privacy protection. > - Although it may be useful for operators to anonymize traffic > data before giving researchers access to it, that is easily done > (as at present) using anonymization tools. > - At this stage there are several anonymoization tools one could > use. tcpdpriv is the most common, but it has known > vulnerabilities. Crypto-PaN is probably better, but has high > processor demands. Overall, good algorithms for anonymization > are still a research issue, not something which is ready to go > into production network devices. > > In a more detailed comment on 'privacy' vs 'security', Sebastian Zander > said: > > > I think that IPFIX must deal with privacy issues somehow. Afterall we > > are standardizing something which could be used to get a detailed log > > of a users activities. > > > > Different countries may have completly different laws on privacy. But > > there are laws (e.g. in the EU). So what may be a privacy violation in one > > country may not be a privacy violation in another. > > > > In general i agree to your proposal. However i think some of the arguments > > against a MUST are not too strong. If i have a flat rate why would my > > provider need to record my flow data? What would prevent someone to give > > a 3rd party access to ipfix informtion? Technically nothing... > > (but there are laws). > > > > I think there are differences between security and privacy which justify > > a different treatment IMO: > > - Security/encryption can *always* be used for ipfix although it means > > using more resources etc. whereas privacy/anonymization can *not* be > > used in any case (e.g. in case of accounting srcip must not be > > anonymized). > > - We have to assume that in those cases the people who use ipfix comply to > > the relevant privacy laws. Privacy can't be enforced by the protocol > > itself, only by laws or social norms. > > - The scenarios where people would like to access ipfix data and can do > > this only through the use of anonymization are currently rare and out > > of scope(?). > > - Encryption techniques are more mature and widely understood whereas > > anonymization techniques are still research and therefore its more > > difficult to put them into a standard now. > > - I think its not the scope of this group to develop and/or standard > > anonymization techniques. There are standards for encryption but for > > anonymization? > > > > Maybe it would be a good idea to have some text on privacy considerations > > in the draft (similar to security considerations). > > I like the idea of a 'privacy considerations' section, probably in the > Architecture draft (rather than the Requirements draft). > > What do you think? Lets have some feedback on the list, please, just > a line saying 'yes for encryption, no for anonymization' would be fine. > But we want to get the Requirements Draft finished, so please respond > quickly! > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > ------------------------------------------------- > This mail sent through University of Auckland > http://www.auckland.ac.nz/ > > -- > 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 Jul 30 15:40:54 2003 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 PAA15146 for ; Wed, 30 Jul 2003 15:40:53 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19hwdY-0002u3-00 for ipfix-list@mil.doit.wisc.edu; Wed, 30 Jul 2003 14:29:24 -0500 Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 19hwdX-0002ty-00 for ipfix@net.doit.wisc.edu; Wed, 30 Jul 2003 14:29:23 -0500 Received: (qmail 7109 invoked from network); 30 Jul 2003 19:29:22 -0000 Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 30 Jul 2003 19:29:22 -0000 X-pair-Authenticated: 207.237.37.137 Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h6UJTL923410; Wed, 30 Jul 2003 15:29:21 -0400 Reply-To: From: "Carter Bullard" To: , "'MEYER,JEFFREY D \(HP-Cupertino,ex1\)'" Cc: "'Nevil Brownlee'" , Subject: RE: [ipfix] Requirements: Encryption and Anonymozation Date: Wed, 30 Jul 2003 15:29:21 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A65F@ptah.newyork.qosient.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6618898B@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver IPSEC compatibility requires nothing of IPFIX but anonymization indication support requires at least a bit in the IPFIX header to indicate that the addresses, time, ports, protocols, whatever, are not real. A MUST for IPSEC requires nothing of the protocol and is completely unenforceable, so it will be an extremely weird statement in the RFC. Sounds like religion or better yet, marketing instead of anything else. A MUST for anonymization indication support is appropriate, but the IETF should NOT try to define an anoymization algorithm. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Alex Audu > Sent: Wednesday, July 30, 2003 1:54 PM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] Requirements: Encryption and Anonymozation > > > I am not sure if the issue is having IPFIX anonymize the > packets in the collected > > flows. I think the real issue is: can IPFIX handle anonymized > packets? It may be > be able to. I just don't know. > > Regards, > Alex. > > "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: > > > Nevil, > > > > I agree with statements on anonymization. I.e. it is > still a research > > area. The flows are staying w/in the operators domain, so > what they collect > > must have privacy considerations addressed before sharing (providing > > aggregate summaries to other parties is one way to > effectively remove > > individual information). > > > > I agree with the approach on encryption of communication, > although I am > > less certain how frequently it will be used. > > > > Regards, > > > > Jeff Meyer > > > > -----Original Message----- > > From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] > > Sent: Wednesday, July 30, 2003 9:52 AM > > To: ipfix@net.doit.wisc.edu > > Subject: [ipfix] Requirements: Encryption and Anonymozation > > > > Hello all: > > > > I've been thinking about Allison's rejection of our Anonymization > > and Encrytpion SHOULD implement position. > > Allison (supported by Randy) believes that they should be 'MUST > > implement's, on the grounds that if they were, people would > use them. > > > > My first thought was 'IPFIX charter says "standardize existing > > practice",' but I checked it, and it doesn't actually say that. > > It does say we'll > > * Identify and address any security privacy concerns affecting > > flow data. Determine technology for securing the flow > information > > export data, e.g. TLS. > > so we clearly have to address encryption. We didn't mention > > anonymization in the charter though, it just crept in to the > > Requirements draft. > > > > In an attempt to move forward, I've had some email discussions > > with the Requirements Draft editors and co-chairs. Based on that, > > I propose the following: > > > > a) A fair proportion of users probably would use encryption to > > get their IPFIX data safely across the Internet. We've said > > all along that we'd use IPSEC or IPSEC for that, rather than > > try to do it at the application layer in IPFIX. So ... > > we should write a 'requirements' sentence saying that "IPFIX > > implementations MUST provide for encryption of exported IPFIX > > data, e.g. by using IPSEC or TLS." [We need to verify that > > TLS would be suitable for this.] > > > > b) For anonymization, we should remove any mention of it from > > the Requirements Draft, because: > > - IPFIX data will normally be collected by network operators > > for traffic engineering and/or accounting purposes. In both > > these cases raw (un-anonymized) data is needed; again, since > > IPFIX data can be encrypted in transit, there is no > operational > > need for further privacy protection. > > - Although it may be useful for operators to anonymize traffic > > data before giving researchers access to it, that is > easily done > > (as at present) using anonymization tools. > > - At this stage there are several anonymoization tools one could > > use. tcpdpriv is the most common, but it has known > > vulnerabilities. Crypto-PaN is probably better, but has high > > processor demands. Overall, good algorithms for anonymization > > are still a research issue, not something which is ready to go > > into production network devices. > > > > In a more detailed comment on 'privacy' vs 'security', > Sebastian Zander > > said: > > > > > I think that IPFIX must deal with privacy issues somehow. > Afterall we > > > are standardizing something which could be used to get a > detailed log > > > of a users activities. > > > > > > Different countries may have completly different laws on > privacy. But > > > there are laws (e.g. in the EU). So what may be a privacy > violation in one > > > country may not be a privacy violation in another. > > > > > > In general i agree to your proposal. However i think some > of the arguments > > > against a MUST are not too strong. If i have a flat rate > why would my > > > provider need to record my flow data? What would prevent > someone to give > > > a 3rd party access to ipfix informtion? Technically nothing... > > > (but there are laws). > > > > > > I think there are differences between security and > privacy which justify > > > a different treatment IMO: > > > - Security/encryption can *always* be used for ipfix > although it means > > > using more resources etc. whereas > privacy/anonymization can *not* be > > > used in any case (e.g. in case of accounting srcip must not be > > > anonymized). > > > - We have to assume that in those cases the people who > use ipfix comply to > > > the relevant privacy laws. Privacy can't be enforced > by the protocol > > > itself, only by laws or social norms. > > > - The scenarios where people would like to access ipfix > data and can do > > > this only through the use of anonymization are > currently rare and out > > > of scope(?). > > > - Encryption techniques are more mature and widely > understood whereas > > > anonymization techniques are still research and > therefore its more > > > difficult to put them into a standard now. > > > - I think its not the scope of this group to develop > and/or standard > > > anonymization techniques. There are standards for > encryption but for > > > anonymization? > > > > > > Maybe it would be a good idea to have some text on > privacy considerations > > > in the draft (similar to security considerations). > > > > I like the idea of a 'privacy considerations' section, > probably in the > > Architecture draft (rather than the Requirements draft). > > > > What do you think? Lets have some feedback on the list, > please, just > > a line saying 'yes for encryption, no for anonymization' > would be fine. > > But we want to get the Requirements Draft finished, so > please respond > > quickly! > > > > Cheers, Nevil > > > > > -------------------------------------------------------------- > --------- > > Nevil Brownlee Director, Technology Development > > Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland > > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > > ------------------------------------------------- > > This mail sent through University of Auckland > > http://www.auckland.ac.nz/ > > > > -- > > 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 Jul 30 15:42:24 2003 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 PAA15171 for ; Wed, 30 Jul 2003 15:42:24 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19hwfi-0002x2-00 for ipfix-list@mil.doit.wisc.edu; Wed, 30 Jul 2003 14:31:38 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19hwfh-0002wx-00 for ipfix@net.doit.wisc.edu; Wed, 30 Jul 2003 14:31:37 -0500 Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel10.hp.com (Postfix) with ESMTP id D5B3C1C02E49; Wed, 30 Jul 2003 12:31:36 -0700 (PDT) Received: from xpabh2.ptp.hp.com (xpabh2.ptp.hp.com [15.1.28.61]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id 8017D1C00B5B; Wed, 30 Jul 2003 12:31:36 -0700 (PDT) Received: by xpabh2.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Jul 2003 12:31:36 -0700 Message-ID: <1D3D2C371FCBD947A7897FABBD3533A50296021A@xsun01.ptp.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'alex.audu@alcatel.com'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "'Nevil Brownlee'" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Requirements: Encryption and Anonymozation Date: Wed, 30 Jul 2003 12:31:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver Hi, I think anonymized identifiers could be defined as simply another element in the data model leaving the anonymization mechanism up to the implementation. This would imply the collector could do aggregation around anonymized identifiers, but would not be able to associate these with users. In practice I think Nevil raises the question whether such anonymization operations would likely find their way onto exporting systems. I think there is also the question of what the field type is for an anonymized identifier (e.g. does an anonymized v4 address still land in a 4 byte field or is it mapped to a larger space, using some crypto hash) Are any items other than IP (v4 or v6) addresses targets of anonymization? I would think not. But... One could argue that correlation techniques may allow for detection of anonymized identifiers via techniques such as sending sets of flows to known ports, or of known size or some other pattern to a target, thus allowing the IP address associated with an "anonymized" flow to be inferred from a set of flows. I fear that that such "attacks" on anonymization and attempting to address them would turn into a rathole... Or effectively render the anonymized flow useless. Aggregation (i.e. a post collection task) would address this. At the raw flow level, I have my doubts. -- Jeff -----Original Message----- From: Alex Audu [mailto:alex.audu@alcatel.com] Sent: Wednesday, July 30, 2003 11:54 AM To: MEYER,JEFFREY D (HP-Cupertino,ex1) Cc: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Requirements: Encryption and Anonymozation I am not sure if the issue is having IPFIX anonymize the packets in the collected flows. I think the real issue is: can IPFIX handle anonymized packets? It may be be able to. I just don't know. Regards, Alex. "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote: > Nevil, > > I agree with statements on anonymization. I.e. it is still a research > area. The flows are staying w/in the operators domain, so what they collect > must have privacy considerations addressed before sharing (providing > aggregate summaries to other parties is one way to effectively remove > individual information). > > I agree with the approach on encryption of communication, although I am > less certain how frequently it will be used. > > Regards, > > Jeff Meyer > > -----Original Message----- > From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] > Sent: Wednesday, July 30, 2003 9:52 AM > To: ipfix@net.doit.wisc.edu > Subject: [ipfix] Requirements: Encryption and Anonymozation > > Hello all: > > I've been thinking about Allison's rejection of our Anonymization > and Encrytpion SHOULD implement position. > Allison (supported by Randy) believes that they should be 'MUST > implement's, on the grounds that if they were, people would use them. > > My first thought was 'IPFIX charter says "standardize existing > practice",' but I checked it, and it doesn't actually say that. > It does say we'll > * Identify and address any security privacy concerns affecting > flow data. Determine technology for securing the flow information > export data, e.g. TLS. > so we clearly have to address encryption. We didn't mention > anonymization in the charter though, it just crept in to the > Requirements draft. > > In an attempt to move forward, I've had some email discussions > with the Requirements Draft editors and co-chairs. Based on that, > I propose the following: > > a) A fair proportion of users probably would use encryption to > get their IPFIX data safely across the Internet. We've said > all along that we'd use IPSEC or IPSEC for that, rather than > try to do it at the application layer in IPFIX. So ... > we should write a 'requirements' sentence saying that "IPFIX > implementations MUST provide for encryption of exported IPFIX > data, e.g. by using IPSEC or TLS." [We need to verify that > TLS would be suitable for this.] > > b) For anonymization, we should remove any mention of it from > the Requirements Draft, because: > - IPFIX data will normally be collected by network operators > for traffic engineering and/or accounting purposes. In both > these cases raw (un-anonymized) data is needed; again, since > IPFIX data can be encrypted in transit, there is no operational > need for further privacy protection. > - Although it may be useful for operators to anonymize traffic > data before giving researchers access to it, that is easily done > (as at present) using anonymization tools. > - At this stage there are several anonymoization tools one could > use. tcpdpriv is the most common, but it has known > vulnerabilities. Crypto-PaN is probably better, but has high > processor demands. Overall, good algorithms for anonymization > are still a research issue, not something which is ready to go > into production network devices. > > In a more detailed comment on 'privacy' vs 'security', Sebastian Zander > said: > > > I think that IPFIX must deal with privacy issues somehow. Afterall we > > are standardizing something which could be used to get a detailed log > > of a users activities. > > > > Different countries may have completly different laws on privacy. But > > there are laws (e.g. in the EU). So what may be a privacy violation in one > > country may not be a privacy violation in another. > > > > In general i agree to your proposal. However i think some of the arguments > > against a MUST are not too strong. If i have a flat rate why would my > > provider need to record my flow data? What would prevent someone to give > > a 3rd party access to ipfix informtion? Technically nothing... > > (but there are laws). > > > > I think there are differences between security and privacy which justify > > a different treatment IMO: > > - Security/encryption can *always* be used for ipfix although it means > > using more resources etc. whereas privacy/anonymization can *not* be > > used in any case (e.g. in case of accounting srcip must not be > > anonymized). > > - We have to assume that in those cases the people who use ipfix comply to > > the relevant privacy laws. Privacy can't be enforced by the protocol > > itself, only by laws or social norms. > > - The scenarios where people would like to access ipfix data and can do > > this only through the use of anonymization are currently rare and out > > of scope(?). > > - Encryption techniques are more mature and widely understood whereas > > anonymization techniques are still research and therefore its more > > difficult to put them into a standard now. > > - I think its not the scope of this group to develop and/or standard > > anonymization techniques. There are standards for encryption but for > > anonymization? > > > > Maybe it would be a good idea to have some text on privacy considerations > > in the draft (similar to security considerations). > > I like the idea of a 'privacy considerations' section, probably in the > Architecture draft (rather than the Requirements draft). > > What do you think? Lets have some feedback on the list, please, just > a line saying 'yes for encryption, no for anonymization' would be fine. > But we want to get the Requirements Draft finished, so please respond > quickly! > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > ------------------------------------------------- > This mail sent through University of Auckland > http://www.auckland.ac.nz/ > > -- > 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 Thu Jul 31 08:02:59 2003 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 IAA21769 for ; Thu, 31 Jul 2003 08:02:59 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19iBiy-0002z3-00 for ipfix-list@mil.doit.wisc.edu; Thu, 31 Jul 2003 06:36:00 -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 19iBix-0002yv-00 for ipfix@net.doit.wisc.edu; Thu, 31 Jul 2003 06:35:59 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-226.cisco.com [144.254.7.226]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h6VBZfp04217; Thu, 31 Jul 2003 13:35:42 +0200 (CEST) Message-ID: <3F28FF0C.9050407@cisco.com> Date: Thu, 31 Jul 2003 13:35:40 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nevil Brownlee CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Requirements: Encryption and Anonymozation References: <1059583948.419d0eb2488eb@hotlava.auckland.ac.nz> In-Reply-To: <1059583948.419d0eb2488eb@hotlava.auckland.ac.nz> Content-Type: multipart/alternative; boundary="------------020207020901040208020103" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------020207020901040208020103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nevil, I vote for 'yes for encryption (*), no for anonymization' (*) mandatory to implement but not mandatory to use Regards, Benoit. >Hello all: > >I've been thinking about Allison's rejection of our Anonymization >and Encrytpion SHOULD implement position. >Allison (supported by Randy) believes that they should be 'MUST >implement's, on the grounds that if they were, people would use them. > >My first thought was 'IPFIX charter says "standardize existing >practice",' but I checked it, and it doesn't actually say that. >It does say we'll > * Identify and address any security privacy concerns affecting > flow data. Determine technology for securing the flow information > export data, e.g. TLS. >so we clearly have to address encryption. We didn't mention >anonymization in the charter though, it just crept in to the >Requirements draft. > >In an attempt to move forward, I've had some email discussions >with the Requirements Draft editors and co-chairs. Based on that, >I propose the following: > > a) A fair proportion of users probably would use encryption to > get their IPFIX data safely across the Internet. We've said > all along that we'd use IPSEC or IPSEC for that, rather than > try to do it at the application layer in IPFIX. So ... > we should write a 'requirements' sentence saying that "IPFIX > implementations MUST provide for encryption of exported IPFIX > data, e.g. by using IPSEC or TLS." [We need to verify that > TLS would be suitable for this.] > > b) For anonymization, we should remove any mention of it from > the Requirements Draft, because: > - IPFIX data will normally be collected by network operators > for traffic engineering and/or accounting purposes. In both > these cases raw (un-anonymized) data is needed; again, since > IPFIX data can be encrypted in transit, there is no operational > need for further privacy protection. > - Although it may be useful for operators to anonymize traffic > data before giving researchers access to it, that is easily done > (as at present) using anonymization tools. > - At this stage there are several anonymoization tools one could > use. tcpdpriv is the most common, but it has known > vulnerabilities. Crypto-PaN is probably better, but has high > processor demands. Overall, good algorithms for anonymization > are still a research issue, not something which is ready to go > into production network devices. > > >In a more detailed comment on 'privacy' vs 'security', Sebastian Zander said: > > > >>I think that IPFIX must deal with privacy issues somehow. Afterall we >>are standardizing something which could be used to get a detailed log >>of a users activities. >> >>Different countries may have completly different laws on privacy. But >>there are laws (e.g. in the EU). So what may be a privacy violation in one >>country may not be a privacy violation in another. >> >>In general i agree to your proposal. However i think some of the arguments >>against a MUST are not too strong. If i have a flat rate why would my >>provider need to record my flow data? What would prevent someone to give >>a 3rd party access to ipfix informtion? Technically nothing... >>(but there are laws). >> >>I think there are differences between security and privacy which justify >>a different treatment IMO: >>- Security/encryption can *always* be used for ipfix although it means >> using more resources etc. whereas privacy/anonymization can *not* be >> used in any case (e.g. in case of accounting srcip must not be >> anonymized). >>- We have to assume that in those cases the people who use ipfix comply to >> the relevant privacy laws. Privacy can't be enforced by the protocol >> itself, only by laws or social norms. >>- The scenarios where people would like to access ipfix data and can do >> this only through the use of anonymization are currently rare and out >> of scope(?). >>- Encryption techniques are more mature and widely understood whereas >> anonymization techniques are still research and therefore its more >> difficult to put them into a standard now. >>- I think its not the scope of this group to develop and/or standard >> anonymization techniques. There are standards for encryption but for >> anonymization? >> >>Maybe it would be a good idea to have some text on privacy considerations >>in the draft (similar to security considerations). >> >> > >I like the idea of a 'privacy considerations' section, probably in the >Architecture draft (rather than the Requirements draft). > >What do you think? Lets have some feedback on the list, please, just >a line saying 'yes for encryption, no for anonymization' would be fine. >But we want to get the Requirements Draft finished, so please respond >quickly! > >Cheers, Nevil > >----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > >------------------------------------------------- >This mail sent through University of Auckland >http://www.auckland.ac.nz/ > >-- >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/ > > --------------020207020901040208020103 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Nevil,

I vote for 
'yes for encryption (*), no for anonymization'
(*) mandatory to implement but not mandatory to use

Regards, Benoit.

Hello all:

I've been thinking about Allison's rejection of our Anonymization
and Encrytpion SHOULD implement position.
Allison (supported by Randy) believes that they should be 'MUST 
implement's, on the grounds that if they were, people would use them.

My first thought was 'IPFIX charter says "standardize existing
practice",' but I checked it, and it doesn't actually say that.
It does say we'll
  * Identify and address any security privacy concerns affecting
    flow data.  Determine technology for securing the flow information
    export data, e.g. TLS.
so we clearly have to address encryption.  We didn't mention
anonymization in the charter though, it just crept in to the 
Requirements draft.

In an attempt to move forward, I've had some email discussions
with the Requirements Draft editors and co-chairs.  Based on that, 
I propose the following:

 a) A fair proportion of users probably would use encryption to
    get their IPFIX data safely across the Internet.  We've said
    all along that we'd use IPSEC or IPSEC for that, rather than
    try to do it at the application layer in IPFIX.  So ...
    we should write a 'requirements' sentence saying that "IPFIX
    implementations MUST provide for encryption of exported IPFIX
    data, e.g. by using IPSEC or TLS."  [We need to verify that
    TLS would be suitable for this.]

 b) For anonymization, we should remove any mention of it from
    the Requirements Draft, because:
    - IPFIX data will normally be collected by network operators
      for traffic engineering and/or accounting purposes.  In both
      these cases raw (un-anonymized) data is needed; again, since
      IPFIX data can be encrypted in transit, there is no operational
      need for further privacy protection.  
    - Although it may be useful for operators to anonymize traffic
      data before giving researchers access to it, that is easily done
      (as at present) using anonymization tools.
    - At this stage there are several anonymoization tools one could
      use.  tcpdpriv is the most common, but it has known
      vulnerabilities.  Crypto-PaN is probably better, but has high
      processor demands.  Overall, good algorithms for anonymization
      are still a research issue, not something which is ready to go
      into production network devices.


In a more detailed comment on 'privacy' vs 'security', Sebastian Zander said:

  
I think that IPFIX must deal with privacy issues somehow. Afterall we
are standardizing something which could be used to get a detailed log
of a users activities.

Different countries may have completly different laws on privacy. But
there are laws (e.g. in the EU). So what may be a privacy violation in one
country may not be a privacy violation in another.

In general i agree to your proposal. However i think some of the arguments
against a MUST are not too strong. If i have a flat rate why would my
provider need to record my flow data? What would prevent someone to give
a 3rd party access to ipfix informtion? Technically nothing...
(but there are laws).

I think there are differences between security and privacy which justify
a different treatment IMO:
- Security/encryption can *always* be used for ipfix although it means
   using more resources etc. whereas privacy/anonymization can *not* be
   used in any case (e.g. in case of accounting srcip must not be
   anonymized).
- We have to assume that in those cases the people who use ipfix comply to
   the relevant privacy laws. Privacy can't be enforced by the protocol
   itself, only by laws or social norms.
- The scenarios where people would like to access ipfix data and can do
   this only through the use of anonymization are currently rare and out
 of scope(?).
- Encryption techniques are more mature and widely understood whereas
   anonymization techniques are still research and therefore its more
   difficult to put them into a standard now.
- I think its not the scope of this group to develop and/or standard
   anonymization techniques. There are standards for encryption but for
   anonymization?

Maybe it would be a good idea to have some text on privacy considerations
in the draft (similar to security considerations).
    

I like the idea of a 'privacy considerations' section, probably in the
Architecture draft (rather than the Requirements draft).

What do you think?  Lets have some feedback on the list, please, just
a line saying 'yes for encryption, no for anonymization' would be fine.
But we want to get the Requirements Draft finished, so please respond
quickly!

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
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/

--------------020207020901040208020103-- -- 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 Jul 31 13:00:50 2003 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 NAA04324 for ; Thu, 31 Jul 2003 13:00:49 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19iGZJ-0004z4-00 for ipfix-list@mil.doit.wisc.edu; Thu, 31 Jul 2003 11:46:21 -0500 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19iGZI-0004yy-00 for ipfix@net.doit.wisc.edu; Thu, 31 Jul 2003 11:46:20 -0500 Received: from Givoly ([192.168.0.101]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h6VGsL116441; Thu, 31 Jul 2003 09:54:21 -0700 From: "Tal Givoly" To: "Benoit Claise" , "Nevil Brownlee" Cc: Subject: RE: [ipfix] Requirements: Encryption and Anonymozation Date: Thu, 31 Jul 2003 09:46:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C35748.91DBF880" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3F28FF0C.9050407@cisco.com> Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C35748.91DBF880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I second the motion. As discussed in previous postings, anonymization is not well defined and, as others have stated, a research item. Not something ready for standardization in context here. Once it is better understood and defined and its use rationalized, it could be specified for future versions. Tal -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Benoit Claise Sent: Thursday, July 31, 2003 4:36 AM To: Nevil Brownlee Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Requirements: Encryption and Anonymozation Nevil, I vote for 'yes for encryption (*), no for anonymization' (*) mandatory to implement but not mandatory to use Regards, Benoit. Hello all: I've been thinking about Allison's rejection of our Anonymization and Encrytpion SHOULD implement position. Allison (supported by Randy) believes that they should be 'MUST implement's, on the grounds that if they were, people would use them. My first thought was 'IPFIX charter says "standardize existing practice",' but I checked it, and it doesn't actually say that. It does say we'll * Identify and address any security privacy concerns affecting flow data. Determine technology for securing the flow information export data, e.g. TLS. so we clearly have to address encryption. We didn't mention anonymization in the charter though, it just crept in to the Requirements draft. In an attempt to move forward, I've had some email discussions with the Requirements Draft editors and co-chairs. Based on that, I propose the following: a) A fair proportion of users probably would use encryption to get their IPFIX data safely across the Internet. We've said all along that we'd use IPSEC or IPSEC for that, rather than try to do it at the application layer in IPFIX. So ... we should write a 'requirements' sentence saying that "IPFIX implementations MUST provide for encryption of exported IPFIX data, e.g. by using IPSEC or TLS." [We need to verify that TLS would be suitable for this.] b) For anonymization, we should remove any mention of it from the Requirements Draft, because: - IPFIX data will normally be collected by network operators for traffic engineering and/or accounting purposes. In both these cases raw (un-anonymized) data is needed; again, since IPFIX data can be encrypted in transit, there is no operational need for further privacy protection. - Although it may be useful for operators to anonymize traffic data before giving researchers access to it, that is easily done (as at present) using anonymization tools. - At this stage there are several anonymoization tools one could use. tcpdpriv is the most common, but it has known vulnerabilities. Crypto-PaN is probably better, but has high processor demands. Overall, good algorithms for anonymization are still a research issue, not something which is ready to go into production network devices. In a more detailed comment on 'privacy' vs 'security', Sebastian Zander said: I think that IPFIX must deal with privacy issues somehow. Afterall we are standardizing something which could be used to get a detailed log of a users activities. Different countries may have completly different laws on privacy. But there are laws (e.g. in the EU). So what may be a privacy violation in one country may not be a privacy violation in another. In general i agree to your proposal. However i think some of the arguments against a MUST are not too strong. If i have a flat rate why would my provider need to record my flow data? What would prevent someone to give a 3rd party access to ipfix informtion? Technically nothing... (but there are laws). I think there are differences between security and privacy which justify a different treatment IMO: - Security/encryption can *always* be used for ipfix although it means using more resources etc. whereas privacy/anonymization can *not* be used in any case (e.g. in case of accounting srcip must not be anonymized). - We have to assume that in those cases the people who use ipfix comply to the relevant privacy laws. Privacy can't be enforced by the protocol itself, only by laws or social norms. - The scenarios where people would like to access ipfix data and can do this only through the use of anonymization are currently rare and out of scope(?). - Encryption techniques are more mature and widely understood whereas anonymization techniques are still research and therefore its more difficult to put them into a standard now. - I think its not the scope of this group to develop and/or standard anonymization techniques. There are standards for encryption but for anonymization? Maybe it would be a good idea to have some text on privacy considerations in the draft (similar to security considerations). I like the idea of a 'privacy considerations' section, probably in the Architecture draft (rather than the Requirements draft). What do you think? Lets have some feedback on the list, please, just a line saying 'yes for encryption, no for anonymization' would be fine. But we want to get the Requirements Draft finished, so please respond quickly! Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- 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_000_0004_01C35748.91DBF880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 second the motion.
 
As=20 discussed in previous postings, anonymization is not well defined and, = as others=20 have stated, a research item. Not something ready for standardization in = context=20 here. Once it is better understood and defined and its use rationalized, = it=20 could be specified for future versions.
 
Tal
-----Original Message-----
From: majordomo = listserver=20 [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Benoit=20 Claise
Sent: Thursday, July 31, 2003 4:36 AM
To: = Nevil=20 Brownlee
Cc: ipfix@net.doit.wisc.edu
Subject: Re: = [ipfix]=20 Requirements: Encryption and Anonymozation

Nevil,=20

I vote for 
'yes for encryption (*), no for =
anonymization'
(*) mandatory to implement but not mandatory to use

Regards, Benoit.

Hello all:

I've been thinking about Allison's rejection of our Anonymization
and Encrytpion SHOULD implement position.
Allison (supported by Randy) believes that they should be 'MUST=20
implement's, on the grounds that if they were, people would use them.

My first thought was 'IPFIX charter says "standardize existing
practice",' but I checked it, and it doesn't actually say that.
It does say we'll
  * Identify and address any security privacy concerns affecting
    flow data.  Determine technology for securing the flow information
    export data, e.g. TLS.
so we clearly have to address encryption.  We didn't mention
anonymization in the charter though, it just crept in to the=20
Requirements draft.

In an attempt to move forward, I've had some email discussions
with the Requirements Draft editors and co-chairs.  Based on that,=20
I propose the following:

 a) A fair proportion of users probably would use encryption to
    get their IPFIX data safely across the Internet.  We've said
    all along that we'd use IPSEC or IPSEC for that, rather than
    try to do it at the application layer in IPFIX.  So ...
    we should write a 'requirements' sentence saying that "IPFIX
    implementations MUST provide for encryption of exported IPFIX
    data, e.g. by using IPSEC or TLS."  [We need to verify that
    TLS would be suitable for this.]

 b) For anonymization, we should remove any mention of it from
    the Requirements Draft, because:
    - IPFIX data will normally be collected by network operators
      for traffic engineering and/or accounting purposes.  In both
      these cases raw (un-anonymized) data is needed; again, since
      IPFIX data can be encrypted in transit, there is no operational
      need for further privacy protection. =20
    - Although it may be useful for operators to anonymize traffic
      data before giving researchers access to it, that is easily done
      (as at present) using anonymization tools.
    - At this stage there are several anonymoization tools one could
      use.  tcpdpriv is the most common, but it has known
      vulnerabilities.  Crypto-PaN is probably better, but has high
      processor demands.  Overall, good algorithms for anonymization
      are still a research issue, not something which is ready to go
      into production network devices.


In a more detailed comment on 'privacy' vs 'security', Sebastian Zander =
said:

  
I think that IPFIX must =
deal with privacy issues somehow. Afterall we
are standardizing something which could be used to get a detailed log
of a users activities.

Different countries may have completly different laws on privacy. But
there are laws (e.g. in the EU). So what may be a privacy violation in =
one
country may not be a privacy violation in another.

In general i agree to your proposal. However i think some of the =
arguments
against a MUST are not too strong. If i have a flat rate why would my
provider need to record my flow data? What would prevent someone to give
a 3rd party access to ipfix informtion? Technically nothing...
(but there are laws).

I think there are differences between security and privacy which justify
a different treatment IMO:
- Security/encryption can *always* be used for ipfix although it means
   using more resources etc. whereas privacy/anonymization can *not* be
   used in any case (e.g. in case of accounting srcip must not be
   anonymized).
- We have to assume that in those cases the people who use ipfix comply =
to
   the relevant privacy laws. Privacy can't be enforced by the protocol
   itself, only by laws or social norms.
- The scenarios where people would like to access ipfix data and can do
   this only through the use of anonymization are currently rare and out
 of scope(?).
- Encryption techniques are more mature and widely understood whereas
   anonymization techniques are still research and therefore its more
   difficult to put them into a standard now.
- I think its not the scope of this group to develop and/or standard
   anonymization techniques. There are standards for encryption but for
   anonymization?

Maybe it would be a good idea to have some text on privacy =
considerations
in the draft (similar to security considerations).
    

I like the idea of a 'privacy considerations' section, probably in the
Architecture draft (rather than the Requirements draft).

What do you think?  Lets have some feedback on the list, please, just
a line saying 'yes for encryption, no for anonymization' would be fine.
But we want to get the Requirements Draft finished, so please respond
quickly!

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wis=
c.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/a=
rchive/

------=_NextPart_000_0004_01C35748.91DBF880-- -- 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 Jul 31 14:21:46 2003 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 OAA07008 for ; Thu, 31 Jul 2003 14:21:46 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19iHuj-00001T-00 for ipfix-list@mil.doit.wisc.edu; Thu, 31 Jul 2003 13:12:33 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19iHui-00001G-00 for ipfix@net.doit.wisc.edu; Thu, 31 Jul 2003 13:12:32 -0500 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6VICTPY011384; Thu, 31 Jul 2003 11:12:29 -0700 (PDT) Received: from cisco.com (dhcp-171-71-204-109.cisco.com [171.71.204.109]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA21547; Thu, 31 Jul 2003 11:12:28 -0700 (PDT) Message-ID: <3F295C0C.12757E09@cisco.com> Date: Thu, 31 Jul 2003 11:12:28 -0700 From: Ganesh Sadasivan Organization: Cisco Systems Inc X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nevil Brownlee CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Requirements: Encryption and Anonymozation References: <1059583948.419d0eb2488eb@hotlava.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I agree with "yes for encryption, no for anonymization". -Ganesh Nevil Brownlee wrote: > Hello all: > > I've been thinking about Allison's rejection of our Anonymization > and Encrytpion SHOULD implement position. > Allison (supported by Randy) believes that they should be 'MUST > implement's, on the grounds that if they were, people would use them. > > My first thought was 'IPFIX charter says "standardize existing > practice",' but I checked it, and it doesn't actually say that. > It does say we'll > * Identify and address any security privacy concerns affecting > flow data. Determine technology for securing the flow information > export data, e.g. TLS. > so we clearly have to address encryption. We didn't mention > anonymization in the charter though, it just crept in to the > Requirements draft. > > In an attempt to move forward, I've had some email discussions > with the Requirements Draft editors and co-chairs. Based on that, > I propose the following: > > a) A fair proportion of users probably would use encryption to > get their IPFIX data safely across the Internet. We've said > all along that we'd use IPSEC or IPSEC for that, rather than > try to do it at the application layer in IPFIX. So ... > we should write a 'requirements' sentence saying that "IPFIX > implementations MUST provide for encryption of exported IPFIX > data, e.g. by using IPSEC or TLS." [We need to verify that > TLS would be suitable for this.] > > b) For anonymization, we should remove any mention of it from > the Requirements Draft, because: > - IPFIX data will normally be collected by network operators > for traffic engineering and/or accounting purposes. In both > these cases raw (un-anonymized) data is needed; again, since > IPFIX data can be encrypted in transit, there is no operational > need for further privacy protection. > - Although it may be useful for operators to anonymize traffic > data before giving researchers access to it, that is easily done > (as at present) using anonymization tools. > - At this stage there are several anonymoization tools one could > use. tcpdpriv is the most common, but it has known > vulnerabilities. Crypto-PaN is probably better, but has high > processor demands. Overall, good algorithms for anonymization > are still a research issue, not something which is ready to go > into production network devices. > > In a more detailed comment on 'privacy' vs 'security', Sebastian Zander said: > > > I think that IPFIX must deal with privacy issues somehow. Afterall we > > are standardizing something which could be used to get a detailed log > > of a users activities. > > > > Different countries may have completly different laws on privacy. But > > there are laws (e.g. in the EU). So what may be a privacy violation in one > > country may not be a privacy violation in another. > > > > In general i agree to your proposal. However i think some of the arguments > > against a MUST are not too strong. If i have a flat rate why would my > > provider need to record my flow data? What would prevent someone to give > > a 3rd party access to ipfix informtion? Technically nothing... > > (but there are laws). > > > > I think there are differences between security and privacy which justify > > a different treatment IMO: > > - Security/encryption can *always* be used for ipfix although it means > > using more resources etc. whereas privacy/anonymization can *not* be > > used in any case (e.g. in case of accounting srcip must not be > > anonymized). > > - We have to assume that in those cases the people who use ipfix comply to > > the relevant privacy laws. Privacy can't be enforced by the protocol > > itself, only by laws or social norms. > > - The scenarios where people would like to access ipfix data and can do > > this only through the use of anonymization are currently rare and out > > of scope(?). > > - Encryption techniques are more mature and widely understood whereas > > anonymization techniques are still research and therefore its more > > difficult to put them into a standard now. > > - I think its not the scope of this group to develop and/or standard > > anonymization techniques. There are standards for encryption but for > > anonymization? > > > > Maybe it would be a good idea to have some text on privacy considerations > > in the draft (similar to security considerations). > > I like the idea of a 'privacy considerations' section, probably in the > Architecture draft (rather than the Requirements draft). > > What do you think? Lets have some feedback on the list, please, just > a line saying 'yes for encryption, no for anonymization' would be fine. > But we want to get the Requirements Draft finished, so please respond > quickly! > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > ------------------------------------------------- > This mail sent through University of Auckland > http://www.auckland.ac.nz/ > > -- > 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/