From ipfix-bounces@ietf.org Tue Jul 1 08:09:58 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB363A6862; Tue, 1 Jul 2008 08:09:58 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998E43A6862 for ; Tue, 1 Jul 2008 08:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMqqDd7UozWY for ; Tue, 1 Jul 2008 08:09:55 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 686263A6834 for ; Tue, 1 Jul 2008 08:09:55 -0700 (PDT) Received: from [127.0.0.1] (dhcp-3-152.nttv6.com [192.47.163.152]) by mail.nttv6.net (8.14.3/8.14.1) with ESMTP id m61FA2B2096774 for ; Wed, 2 Jul 2008 00:10:02 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 02 Jul 2008 00:08:57 +0900 From: Atsushi Kobayashi To: ipfix@ietf.org In-Reply-To: <20080630120001.82E543A6ACB@core3.amsl.com> References: <20080630120001.82E543A6ACB@core3.amsl.com> Message-Id: <20080702000342.C068.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Wed, 02 Jul 2008 00:10:02 +0900 (JST) Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, I have written up the first version IPFIX Mediation framework draft. Your comments are welcome at any time. Regards, Atsushi KOBAYASHI On Mon, 30 Jun 2008 05:00:01 -0700 (PDT) Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > > Title : IPFIX Mediation: Framework > Author(s) : A. Kobayashi, et al. > Filename : draft-ietf-ipfix-mediators-framework-00.txt > Pages : 25 > Date : 2008-06-30 > > This document describes a framework for an IPFIX Mediation. An IPFIX > Mediation device (IPFIX Mediator) is an intermediate device between > IPFIX Exporters and IPFIX Collectors. This framework describes an > architecture model, the components of the architecture, and > guidelines for the IPFIX protocol specifications for the IPFIX > Mediators. In addition, this document describes applicable examples > for IPFIX Mediation. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. teFrom ipfix-bounces@ietf.org Tue Jul 1 08:09:58 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB363A6862; Tue, 1 Jul 2008 08:09:58 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998E43A6862 for ; Tue, 1 Jul 2008 08:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMqqDd7UozWY for ; Tue, 1 Jul 2008 08:09:55 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 686263A6834 for ; Tue, 1 Jul 2008 08:09:55 -0700 (PDT) Received: from [127.0.0.1] (dhcp-3-152.nttv6.com [192.47.163.152]) by mail.nttv6.net (8.14.3/8.14.1) with ESMTP id m61FA2B2096774 for ; Wed, 2 Jul 2008 00:10:02 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 02 Jul 2008 00:08:57 +0900 From: Atsushi Kobayashi To: ipfix@ietf.org In-Reply-To: <20080630120001.82E543A6ACB@core3.amsl.com> References: <20080630120001.82E543A6ACB@core3.amsl.com> Message-Id: <20080702000342.C068.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Wed, 02 Jul 2008 00:10:02 +0900 (JST) Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, I have written up the first version IPFIX Mediation framework draft. Your comments are welcome at any time. Regards, Atsushi KOBAYASHI On Mon, 30 Jun 2008 05:00:01 -0700 (PDT) Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > > Title : IPFIX Mediation: Framework > Author(s) : A. Kobayashi, et al. > Filename : draft-ietf-ipfix-mediators-framework-00.txt > Pages : 25 > Date : 2008-06-30 > > This document describes a framework for an IPFIX Mediation. An IPFIX > Mediation device (IPFIX Mediator) is an intermediate device between > IPFIX Exporters and IPFIX Collectors. This framework describes an > architecture model, the components of the architecture, and > guidelines for the IPFIX protocol specifications for the IPFIX > Mediators. In addition, this document describes applicable examples > for IPFIX Mediation. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:l:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix +81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Jul 2 10:30:02 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707FE3A694A; Wed, 2 Jul 2008 10:30:02 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B7E143A694A; Wed, 2 Jul 2008 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080702173001.B7E143A694A@core3.amsl.com> Date: Wed, 2 Jul 2008 10:30:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Export per SCTP Stream Author(s) : B. Claise, P. Aitken, A. Johnson, G. Muenz Filename : draft-ietf-ipfix-export-per-sctp-stream-00.txt Pages : 20 Date : 2008-7-1 This document specifies an improvement to the use of SCTP as specified in the IPFIX specifications in order to be able to deduce the Data Record loss per Template Record in case of partially-reliable SCTP export. This specification offers several extra advantages: immediate export of the Template Withdrawal Message, immediate reuse of Template ID within a stream, and the Collecting Process's job is easier. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-export-per-sctp-stream-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-2102007.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Wed Jul 2 10:30:02 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707FE3A694A; Wed, 2 Jul 2008 10:30:02 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B7E143A694A; Wed, 2 Jul 2008 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080702173001.B7E143A694A@core3.amsl.com> Date: Wed, 2 Jul 2008 10:30:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Export per SCTP Stream Author(s) : B. Claise, P. Aitken, A. Johnson, G. Muenz Filename : draft-ietf-ipfix-export-per-sctp-stream-00.txt Pages : 20 Date : 2008-7-1 This document specifies an improvement to the use of SCTP as specified in the IPFIX specifications in order to be able to deduce the Data Record loss per Template Record in case of partially-reliable SCTP export. This specification offers several extra advantages: immediate export of the Template Withdrawal Message, immediate reuse of Template ID within a stream, and the Collecting Process's job is easier. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-export-per-sctp-stream-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-2102007.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Fri Jul 4 10:15:04 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52CBB3A6B23; Fri, 4 Jul 2008 10:15:04 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0AC793A6A0C; Fri, 4 Jul 2008 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080704171502.0AC793A6A0C@core3.amsl.com> Date: Fri, 4 Jul 2008 10:15:02 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Configuration Data Model for IPFIX and PSAMP Author(s) : G. Muenz, B. Claise Filename : draft-ietf-ipfix-configuration-model-00.txt Pages : 45 Date : 2008-07-04 This document specifies a data model for the configuration of caches, selection processes, exporting processes, and collecting processes of IPFIX and PSAMP compliant monitoring devices. The configuration data model is encoded in Extensible Markup Language (XML). The structure of the data model is specified in a YANG module to ensure compatibility with the NETCONF protocol. A YANG-to-XSD converter is available which allows generating an XML Schema Definition (XSD) of the data model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-configuration-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-04101044.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Fri Jul 4 10:15:04 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52CBB3A6B23; Fri, 4 Jul 2008 10:15:04 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0AC793A6A0C; Fri, 4 Jul 2008 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080704171502.0AC793A6A0C@core3.amsl.com> Date: Fri, 4 Jul 2008 10:15:02 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Configuration Data Model for IPFIX and PSAMP Author(s) : G. Muenz, B. Claise Filename : draft-ietf-ipfix-configuration-model-00.txt Pages : 45 Date : 2008-07-04 This document specifies a data model for the configuration of caches, selection processes, exporting processes, and collecting processes of IPFIX and PSAMP compliant monitoring devices. The configuration data model is encoded in Extensible Markup Language (XML). The structure of the data model is specified in a YANG module to ensure compatibility with the NETCONF protocol. A YANG-to-XSD converter is available which allows generating an XML Schema Definition (XSD) of the data model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-configuration-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-04101044.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Jul 7 16:44:58 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8093A6B8D; Mon, 7 Jul 2008 16:44:58 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681933A6B8D for ; Mon, 7 Jul 2008 16:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azJbL5mSOOYZ for ; Mon, 7 Jul 2008 16:44:56 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 57BD53A683E for ; Mon, 7 Jul 2008 16:44:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C32CC9C293 for ; Tue, 8 Jul 2008 11:45:03 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fCVJ+eZSfux for ; Tue, 8 Jul 2008 11:45:03 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9C2229C27A for ; Tue, 8 Jul 2008 11:45:03 +1200 (NZST) Message-ID: <4872AA7F.90803@auckland.ac.nz> Date: Tue, 08 Jul 2008 11:45:03 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] Proposal to update IPFIX milestones X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: Our last agenda item at the Philadelphia IETF was to revise the WG milestones; I said I'd post a suggestion for that - here (at last) it is. If you'd like to suggest any changes, please reply to the list. Cheers, Nevil IPFIX Milestones currently are: Dec 2007 Publish Internet draft on IPFIX Configuration Data Model Dec 2007 Publish Internet draft on Single SCTP Stream Reporting Done Publish Internet draft on IPFIX File Format Jan 2008 Publish Internet draft on IPFIX Mediation Problem Statement Jan 2008 Submit File Format draft to IESG for publication as Standards track RFC Mar 2008 Submit IPFIX MIB draft to IESG for publication as Standards track RFC Jun 2008 Submit Type Export draft to IESG for publication as Standards track RFC Jun 2008 Submit Single SCTP Stream draft to IESG for publication as Informational RFC Oct 2008 Submit Configuration Data Model draft to IESG for publication as Standards track RFC Oct 2008 Submit Mediation Problem draft to IESG for publication as Informational RFC Proposed new version From ipfix-bounces@ietf.org Mon Jul 7 16:44:58 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8093A6B8D; Mon, 7 Jul 2008 16:44:58 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681933A6B8D for ; Mon, 7 Jul 2008 16:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azJbL5mSOOYZ for ; Mon, 7 Jul 2008 16:44:56 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 57BD53A683E for ; Mon, 7 Jul 2008 16:44:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C32CC9C293 for ; Tue, 8 Jul 2008 11:45:03 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fCVJ+eZSfux for ; Tue, 8 Jul 2008 11:45:03 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9C2229C27A for ; Tue, 8 Jul 2008 11:45:03 +1200 (NZST) Message-ID: <4872AA7F.90803@auckland.ac.nz> Date: Tue, 08 Jul 2008 11:45:03 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] Proposal to update IPFIX milestones X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: Our last agenda item at the Philadelphia IETF was to revise the WG milestones; I said I'd post a suggestion for that - here (at last) it is. If you'd like to suggest any changes, please reply to the list. Cheers, Nevil IPFIX Milestones currently are: Dec 2007 Publish Internet draft on IPFIX Configuration Data Model Dec 2007 Publish Internet draft on Single SCTP Stream Reporting Done Publish Internet draft on IPFIX File Format Jan 2008 Publish Internet draft on IPFIX Mediation Problem Statement Jan 2008 Submit File Format draft to IESG for publication as Standards track RFC Mar 2008 Submit IPFIX MIB draft to IESG for publication as Standards track RFC Jun 2008 Submit Type Export draft to IESG for publication as Standards track RFC Jun 2008 Submit Single SCTP Stream draft to IESG for publication as Informational RFC Oct 2008 Submit Configuration Data Model draft to IESG for publication as Standards track RFC Oct 2008 Submit Mediation Problem draft to IESG for publication as Informational RFC Proposed new versiois: (* => changed date, + => new milestone) *Done Publish Internet draft on IPFIX Configuration Data Model *Done Publish Internet draft on Single SCTP Stream Reporting Done Publish Internet draft on IPFIX File Format *Done Publish Internet draft on IPFIX Mediation Problem Statement +Done Publish Internet draft on IPFIX Mediation Framework *Sep 2008 Submit File Format draft to IESG for publication as Standards track RFC *Oct 2008 Submit IPFIX MIB draft to IESG for publication as Standards track RFC *Sep 2008 Submit Type Export draft to IESG for publication as Standards track RFC *Oct 2008 Submit Single SCTP Stream draft to IESG for publication as Informational RFC *Nov 2008 Submit Configuration Data Model draft to IESG for publication as Standards track RFC *Apr 2009 Submit Mediation Problem Statement draft to IESG for publication as Informational RFC +Apr 2009 Submit Mediation Framework draft to IESG for publication as Informational RFC -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix n is: (* => changed date, + => new milestone) *Done Publish Internet draft on IPFIX Configuration Data Model *Done Publish Internet draft on Single SCTP Stream Reporting Done Publish Internet draft on IPFIX File Format *Done Publish Internet draft on IPFIX Mediation Problem Statement +Done Publish Internet draft on IPFIX Mediation Framework *Sep 2008 Submit File Format draft to IESG for publication as Standards track RFC *Oct 2008 Submit IPFIX MIB draft to IESG for publication as Standards track RFC *Sep 2008 Submit Type Export draft to IESG for publication as Standards track RFC *Oct 2008 Submit Single SCTP Stream draft to IESG for publication as Informational RFC *Nov 2008 Submit Configuration Data Model draft to IESG for publication as Standards track RFC *Apr 2009 Submit Mediation Problem Statement draft to IESG for publication as Informational RFC +Apr 2009 Submit Mediation Framework draft to IESG for publication as Informational RFC -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Jul 7 17:37:01 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4867328C37E; Mon, 7 Jul 2008 17:37:01 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14EC28C377 for ; Mon, 7 Jul 2008 17:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[AWL=2.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUztdqDrjNsx for ; Mon, 7 Jul 2008 17:36:59 -0700 (PDT) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 23F9528C14D for ; Mon, 7 Jul 2008 17:36:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 08492183F8 for ; Tue, 8 Jul 2008 12:37:05 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9kJChGpz4fC for ; Tue, 8 Jul 2008 12:37:04 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E1CEC183E0 for ; Tue, 8 Jul 2008 12:37:04 +1200 (NZST) Message-ID: <4872B6B0.50604@auckland.ac.nz> Date: Tue, 08 Jul 2008 12:37:04 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] DRAFT agenda for Dublin meeting X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've put the first draft of the agenda for the IPFIX session at the Dublin IETF meeting online at http://www.ietf.org/proceedings/08jul/agenda/ipfix.txt Please send me any requests for changes, or suuggestions for improvements. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Jul 7 17:37:01 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4867328C37E; Mon, 7 Jul 2008 17:37:01 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14EC28C377 for ; Mon, 7 Jul 2008 17:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[AWL=2.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUztdqDrjNsx for ; Mon, 7 Jul 2008 17:36:59 -0700 (PDT) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 23F9528C14D for ; Mon, 7 Jul 2008 17:36:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 08492183F8 for ; Tue, 8 Jul 2008 12:37:05 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9kJChGpz4fC for ; Tue, 8 Jul 2008 12:37:04 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E1CEC183E0 for ; Tue, 8 Jul 2008 12:37:04 +1200 (NZST) Message-ID: <4872B6B0.50604@auckland.ac.nz> Date: Tue, 08 Jul 2008 12:37:04 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] DRAFT agenda for Dublin meeting X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've put the first draft of the agenda for the IPFIX session at the Dublin IETF meeting online at http://www.ietf.org/proceedings/08jul/agenda/ipfix.txt Please send me any requests for changes, or suuggestions for improvements. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jul 10 09:52:59 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0AA3A6A17; Thu, 10 Jul 2008 09:52:59 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E0A3A6A17 for ; Thu, 10 Jul 2008 09:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtrPW0FFVjJV for ; Thu, 10 Jul 2008 09:52:56 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B46963A6A15 for ; Thu, 10 Jul 2008 09:52:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="14046011" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Jul 2008 16:53:08 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6AGr8JY025309 for ; Thu, 10 Jul 2008 18:53:08 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6AGr8Vu004806 for ; Thu, 10 Jul 2008 16:53:08 GMT Received: from [10.61.98.15] (dhcp-10-61-98-15.cisco.com [10.61.98.15]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6AGr7i00050 for ; Thu, 10 Jul 2008 17:53:07 +0100 (BST) Message-ID: <48763E72.8070905@cisco.com> Date: Thu, 10 Jul 2008 17:53:06 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: "ipfix@ietf.org" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23219; t=1215708788; x=1216572788; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-boschi-ipfix-anon-00.txt |Sender:=20; bh=C+oQ70zJZKOjAE8lhU7pdf4s777SVG1dTPt8RQ8t100=; b=JMpWwJDBv4W9PfxJsTmS3A7SA/GQYUcaLJAlus8E1lf/8JArnCLAjxd0MA EwRBCk9wEam5tok7u8KrTTwO4Ke/LyyTgHZ2+MyBw5wMz6jfp6HtMGzCsohg LLLL6A/iTz; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [IPFIX] review: draft-boschi-ipfix-anon-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear Brian and Elisa, An interesting and promising draft. Please find some comments inline. > IPFIX Working Group E. Boschi > Internet-Draft B. Trammell > Intended status: Experimental Hitachi Europe > Expires: January 8, 2009 July 7, 2008 > > > IP Flow Anonymisation Support > draft-boschi-ipfix-From ipfix-bounces@ietf.org Thu Jul 10 09:52:59 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0AA3A6A17; Thu, 10 Jul 2008 09:52:59 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E0A3A6A17 for ; Thu, 10 Jul 2008 09:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtrPW0FFVjJV for ; Thu, 10 Jul 2008 09:52:56 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B46963A6A15 for ; Thu, 10 Jul 2008 09:52:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="14046011" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Jul 2008 16:53:08 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6AGr8JY025309 for ; Thu, 10 Jul 2008 18:53:08 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6AGr8Vu004806 for ; Thu, 10 Jul 2008 16:53:08 GMT Received: from [10.61.98.15] (dhcp-10-61-98-15.cisco.com [10.61.98.15]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6AGr7i00050 for ; Thu, 10 Jul 2008 17:53:07 +0100 (BST) Message-ID: <48763E72.8070905@cisco.com> Date: Thu, 10 Jul 2008 17:53:06 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: "ipfix@ietf.org" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23219; t=1215708788; x=1216572788; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-boschi-ipfix-anon-00.txt |Sender:=20; bh=C+oQ70zJZKOjAE8lhU7pdf4s777SVG1dTPt8RQ8t100=; b=JMpWwJDBv4W9PfxJsTmS3A7SA/GQYUcaLJAlus8E1lf/8JArnCLAjxd0MA EwRBCk9wEam5tok7u8KrTTwO4Ke/LyyTgHZ2+MyBw5wMz6jfp6HtMGzCsohg LLLL6A/iTz; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [IPFIX] review: draft-boschi-ipfix-anon-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear Brian and Elisa, An interesting and promising draft. Please find some comments inline. > IPFIX Working Group E. Boschi > Internet-Draft B. Trammell > Intended status: Experimental Hitachi Europe > Expires: January 8, 2009 July 7, 2008 > > > IP Flow Anonymisation Support > draft-boschi-ipfianon-00.txt > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January 8, 2009. > > Abstract > > This document describes anonymisation techniques for IP flow data. > It provides a categorization of common anomymisation schemes and > defines the parameters needed to describe them. It describes support > for anonymization within the IPFIX protocol, providing the basis for > the definition of information models for configuring anonymisation > techniques within an IPFIX Metering or Exporting Process, and for > reporting the technique in use to an IPFIX Collecting Process. > > > > > > > > > Boschi & Trammell Expires January 8, 2009 [Page 1] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. IPFIX Protocol Overview . . . . . . . . . . . . . . . . . 3 > 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Categorisation of Anonymisation Techniques . . . . . . . . . . 5 > 4. Anonymisation of IP Flow Data . . . . . . . . . . . . . . . . 5 > 4.1. IP Address Anonymisation . . . . . . . . . . . . . . . . . 6 > 4.2. Timestamp Anonymisation . . . . . . . . . . . . . . . . . 6 > 4.3. Anonymisation of Other Flow Fields . . . . . . . . . . . . 7 > 5. Parameters for the Description of Anonymisation Techniques . . 7 > 6. Anonymisation Support in IPFIX . . . . . . . . . . . . . . . . 7 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 > 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 > Intellectual Property and Copyright Statements . . . . . . . . . . 10 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Boschi & Trammell Expires January 8, 2009 [Page 2] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > 1. Introduction > > The standardisation of an IP flow information export protocol > [RFC5101] and associated representations removes a technical barrier > to the sharing of IP flow data across organizational boundaries and > with network operations, security, and research communities for a > wide variety of purposes. However, with wider dissemination comes > greater risks to the privacy of the users of networks under > measurement, and to the security of those networks. While it is not > a complete solution to the issues posed by distribution of IP flow > information, anonymisation is an important tool for thx-anon-00.txt > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January 8, 2009. > > Abstract > > This document describes anonymisation techniques for IP flow data. > It provides a categorization of common anomymisation schemes and > defines the parameters needed to describe them. It describes support > for anonymization within the IPFIX protocol, providing the basis for > the definition of information models for configuring anonymisation > techniques within an IPFIX Metering or Exporting Process, and for > reporting the technique in use to an IPFIX Collecting Process. > > > > > > > > > Boschi & Trammell Expires January 8, 2009 [Page 1] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. IPFIX Protocol Overview . . . . . . . . . . . . . . . . . 3 > 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Categorisation of Anonymisation Techniques . . . . . . . . . . 5 > 4. Anonymisation of IP Flow Data . . . . . . . . . . . . . . . . 5 > 4.1. IP Address Anonymisation . . . . . . . . . . . . . . . . . 6 > 4.2. Timestamp Anonymisation . . . . . . . . . . . . . . . . . 6 > 4.3. Anonymisation of Other Flow Fields . . . . . . . . . . . . 7 > 5. Parameters for the Description of Anonymisation Techniques . . 7 > 6. Anonymisation Support in IPFIX . . . . . . . . . . . . . . . . 7 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 > 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 > Intellectual Property and Copyright Statements . . . . . . . . . . 10 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Boschi & Trammell Expires January 8, 2009 [Page 2] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > 1. Introduction > > The standardisation of an IP flow information export protocol > [RFC5101] and associated representations removes a technical barrier > to the sharing of IP flow data across organizational boundaries and > with network operations, security, and research communities for a > wide variety of purposes. However, with wider dissemination comes > greater risks to the privacy of the users of networks under > measurement, and to the security of those networks. While it is not > a complete solution to the issues posed by distribution of IP flow > information, anonymisation is an important tool for e protection of > privacy within network measurement infrastructures. Additionally, > various jurisdictions define data protection laws and regulations > that flow measurement activities must comply with, and anonymisation > may be a part of such compliance [IMC07, FloCon08]. > > This document presents a mechanism for representing anonymised data > within IPFIX and guidelines for using it. It begins with a > categorization of anonymisation techniques. It then describes > applicability of each technique to commonly anonymisable fields of IP > flow data, organized by information element data type and semantics > as in [RFC5102]; enumerates the parameters required by each of the > applicable anonymisation techniques; and provides guidelines for the > use of each of these techniques in accordance with best practices in > data protection. Finally, it specifies a mechanism for exporting > anonymised data and binding anonymisation metadata to templates using > IPFIX Options. > > 1.1. IPFIX Protocol Overview > > In the IPFIX protocol, { type, length, value } tuples are expressed > in templates containing { type, length } pairs, specifying which { > value } fields are present in data records conforming to the > Template, giving great flexibility as to what data is transmitted. > > Since Templates are sent very infrequently compared with Data > Records, this results in significant bandwidth savings. > > Different Data Records may be transmitted simply by sending new > Templates specifying the { type, length } pairs for the new data > format. See [RFC5101] for more information. > > The IPFIX information model [RFC5102] defines a large number of > standard Information Elements which provide the necessary { type } > information for Templates. > > The use of standard elements enables interoperability among different > vendors' implementations. Additionally, non-standard enterprise- > > > > Boschi & Trammell Expires January 8, 2009 [Page 3] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > specific elements may be defined for private use. > > 1.2. IPFIX Documents Overview > > "Specification of the IPFIX Protocol for the Exchange of IP Traffic > Flow Information" [RFC5101] (informally, the IPFIX Protocol document) I would prefer not to invent local names for these documents, but to use [RFC5101] throughout for clarity. Also so that automated tools can generate links correctly when parsing the text. > and its associated documents define the IPFIX Protocol, which > provides network engineers and administrators with access to IP > traffic flow information. > > "Architecture for IP Flow Information Export" [I-D.ietf-ipfix-arch] > (the IPFIX Architecture document) defines the architecture for the Again, please don't invent a local name for the document. > export of measured IP flow information out of an IPFIX Exporting > Process to an IPFIX Collecting Process, and the basic terminology > used to describe the elements of this architecture, per the > requirements defined in "Requirements for IP Flow Information Export" > [RFC3917]. The IPFIX Protocol document [RFC5101] then covers the > details of the method for transporting IPFIX Data Records and > Templates via a congestion-aware transport protocol from an IPFIX > Exporting Process to an IPFIX Collecting Process. > > "Information Model for IP Flow Information Export" [RFC5102] > (informally, the IPFIX Information Model document) describes the Tsk! > Information Elements used by IPFIX, including details on Information > Element naming, numbering, and data type encoding. Finally, "IPFIX > Applicability" [I-D.ietf-ipfix-as] describes the various applications > of the IPFIX protocol and their use of information exported via > IPFIX, and relates the IPFIX architecture to other measurement > architectures and frameworks. > > This document referencthe protection of > privacy within network measurement infrastructures. Additionally, > various jurisdictions define data protection laws and regulations > that flow measurement activities must comply with, and anonymisation > may be a part of such compliance [IMC07, FloCon08]. > > This document presents a mechanism for representing anonymised data > within IPFIX and guidelines for using it. It begins with a > categorization of anonymisation techniques. It then describes > applicability of each technique to commonly anonymisable fields of IP > flow data, organized by information element data type and semantics > as in [RFC5102]; enumerates the parameters required by each of the > applicable anonymisation techniques; and provides guidelines for the > use of each of these techniques in accordance with best practices in > data protection. Finally, it specifies a mechanism for exporting > anonymised data and binding anonymisation metadata to templates using > IPFIX Options. > > 1.1. IPFIX Protocol Overview > > In the IPFIX protocol, { type, length, value } tuples are expressed > in templates containing { type, length } pairs, specifying which { > value } fields are present in data records conforming to the > Template, giving great flexibility as to what data is transmitted. > > Since Templates are sent very infrequently compared with Data > Records, this results in significant bandwidth savings. > > Different Data Records may be transmitted simply by sending new > Templates specifying the { type, length } pairs for the new data > format. See [RFC5101] for more information. > > The IPFIX information model [RFC5102] defines a large number of > standard Information Elements which provide the necessary { type } > information for Templates. > > The use of standard elements enables interoperability among different > vendors' implementations. Additionally, non-standard enterprise- > > > > Boschi & Trammell Expires January 8, 2009 [Page 3] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > specific elements may be defined for private use. > > 1.2. IPFIX Documents Overview > > "Specification of the IPFIX Protocol for the Exchange of IP Traffic > Flow Information" [RFC5101] (informally, the IPFIX Protocol document) I would prefer not to invent local names for these documents, but to use [RFC5101] throughout for clarity. Also so that automated tools can generate links correctly when parsing the text. > and its associated documents define the IPFIX Protocol, which > provides network engineers and administrators with access to IP > traffic flow information. > > "Architecture for IP Flow Information Export" [I-D.ietf-ipfix-arch] > (the IPFIX Architecture document) defines the architecture for the Again, please don't invent a local name for the document. > export of measured IP flow information out of an IPFIX Exporting > Process to an IPFIX Collecting Process, and the basic terminology > used to describe the elements of this architecture, per the > requirements defined in "Requirements for IP Flow Information Export" > [RFC3917]. The IPFIX Protocol document [RFC5101] then covers the > details of the method for transporting IPFIX Data Records and > Templates via a congestion-aware transport protocol from an IPFIX > Exporting Process to an IPFIX Collecting Process. > > "Information Model for IP Flow Information Export" [RFC5102] > (informally, the IPFIX Information Model document) describes the Tsk! > Information Elements used by IPFIX, including details on Information > Element naming, numbering, and data type encoding. Finally, "IPFIX > Applicability" [I-D.ietf-ipfix-as] describes the various applications > of the IPFIX protocol and their use of information exported via > IPFIX, and relates the IPFIX architecture to other measurement > architectures and frameworks. > > This document referees the Protocol and Architecture documents for > terminology and extends the IPFIX Information Model to provide new > Information Elements for anonymisation metadata. Simply say: This document references the IPFIX Protocol [RFC5101] and IPIFX Architecture [I-D.ietf-ipfix-arch] for terminology and extends the IPFIX Information Model [RFC5102] to provide new Information Elements for anonymisation metadata. > > > 2. Terminology > > The terminology used in this document is fully aligned with the > terminology defined in [RFC5101]. Therefore, the terms defined in > the IPFIX terminology are capitalized in this document, as in other > IPFIX drafts ([RFC5101], [RFC5102]). RFCs aren't drafts! > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > > > > > Boschi & Trammell Expires January 8, 2009 [Page 4] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > 3. Categorisation of Anonymisation Techniques > > Anonymisation modifies a data set in order to protect the identity of > the people or entities described by the data set from disclosure. > With respect to network traffic data, anonymisation generally > attempts to preserve some set of properties of the network traffic > useful for a given application or applications, while ensuring the > data cannot be traced back to the specific networks, hosts, or users > generating the traffic. > > Anonymisation may be broadly split into three categories: > generalisation and reversible or irreversible substitution. When > generalisation is used, identifying information is grouped in sets, > and one single value is used to identify each set element. Note that > this may cause multiple records to become indistinguishable, thereby > aggregating them into a single record. Generalisation is an Aggregation of indistinguishable records may be optional, even overlooked. Yet without this step, it would be clear that the original data had come from different sources - so a small amount of anonymisation would be lost. So you should recommend that the data be post-processed to aggregate any indistinguishable records. > irreversible operation, in that the information needed to identify a > single record from its "generalised value" is lost. Another method is bracketisation, ie indicating that the value lies between specific min and max limits. This is often used for age groups, ie 0-10, 10-20, 30-40. In a way, an IP subnet is an example of this. However, it doubles the amount of data and so might be difficult to implement in IPFIX. > Substitution (or pseudonymization) substitutes a false identifier for > a real one, and can be reversible or irreversible. Reversible > substitution uses an invertible or otherwise reversible function, so > that the real identifier may be recovered later. Irreversible > substitution, likewise, uses a one-way or randomising function, so "likewise" is misleading. > that the real identifier cannot be recovered. > > While anonymisation is generally applied at the resolution of single > fields within a record, attacks against anonymisation use entire > records and relationships between records within a data set. > Therefore, fields which may not necessarily be identifying by > themselves may be anonymised in order to increase the anonymity of > the data set as a whole. > > > 4. Anonymisation of IP Flow Data > > Due to the restricted semantics of IP flow data, there are a > relatively limited set of specific anonymisation techniques available > on flow data, though each falls into the broad categories above. > Each type of field that may commonly appear in a flow record may have > its own applicable specific techniques. > > Of all the fields in an IP flow record, the most attentnces the Protocol and Architecture documents for > terminology and extends the IPFIX Information Model to provide new > Information Elements for anonymisation metadata. Simply say: This document references the IPFIX Protocol [RFC5101] and IPIFX Architecture [I-D.ietf-ipfix-arch] for terminology and extends the IPFIX Information Model [RFC5102] to provide new Information Elements for anonymisation metadata. > > > 2. Terminology > > The terminology used in this document is fully aligned with the > terminology defined in [RFC5101]. Therefore, the terms defined in > the IPFIX terminology are capitalized in this document, as in other > IPFIX drafts ([RFC5101], [RFC5102]). RFCs aren't drafts! > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > > > > > Boschi & Trammell Expires January 8, 2009 [Page 4] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > 3. Categorisation of Anonymisation Techniques > > Anonymisation modifies a data set in order to protect the identity of > the people or entities described by the data set from disclosure. > With respect to network traffic data, anonymisation generally > attempts to preserve some set of properties of the network traffic > useful for a given application or applications, while ensuring the > data cannot be traced back to the specific networks, hosts, or users > generating the traffic. > > Anonymisation may be broadly split into three categories: > generalisation and reversible or irreversible substitution. When > generalisation is used, identifying information is grouped in sets, > and one single value is used to identify each set element. Note that > this may cause multiple records to become indistinguishable, thereby > aggregating them into a single record. Generalisation is an Aggregation of indistinguishable records may be optional, even overlooked. Yet without this step, it would be clear that the original data had come from different sources - so a small amount of anonymisation would be lost. So you should recommend that the data be post-processed to aggregate any indistinguishable records. > irreversible operation, in that the information needed to identify a > single record from its "generalised value" is lost. Another method is bracketisation, ie indicating that the value lies between specific min and max limits. This is often used for age groups, ie 0-10, 10-20, 30-40. In a way, an IP subnet is an example of this. However, it doubles the amount of data and so might be difficult to implement in IPFIX. > Substitution (or pseudonymization) substitutes a false identifier for > a real one, and can be reversible or irreversible. Reversible > substitution uses an invertible or otherwise reversible function, so > that the real identifier may be recovered later. Irreversible > substitution, likewise, uses a one-way or randomising function, so "likewise" is misleading. > that the real identifier cannot be recovered. > > While anonymisation is generally applied at the resolution of single > fields within a record, attacks against anonymisation use entire > records and relationships between records within a data set. > Therefore, fields which may not necessarily be identifying by > themselves may be anonymised in order to increase the anonymity of > the data set as a whole. > > > 4. Anonymisation of IP Flow Data > > Due to the restricted semantics of IP flow data, there are a > relatively limited set of specific anonymisation techniques available > on flow data, though each falls into the broad categories above. > Each type of field that may commonly appear in a flow record may have > its own applicable specific techniques. > > Of all the fields in an IP flow record, the most atteion in the > literature has been paid to IP addresses [TODO: cite]. IP addresses > are structured identifiers, that is, partial IP address prefixes may > be used to identify networks just as full IP addresses identify > hosts. This leads to the application of prefix-preserving > anonymisation of IP address information [TODO: cite]. Prefix- > > > > Boschi & Trammell Expires January 8, 2009 [Page 5] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > preserving anonymisation is a (generally irreversible) substitution > technique which has the additional property that the structure of the > IP address space is maintained in the anonymised data. > > While not identifiers in and of themselves, timestamps are vulnerable > to fingerprinting attacks, wherein relationships between the start > and end timestamps of flows within a data set can be used to identify > hosts or networks [TODO: cite]. Therefore, a variety of > anonymisation techniques are available, including loss of precision > (a form of generalisation), or noise addition (substitution), which > may or may not preserve the sequencing of flows in the data set. > > Counters and other flow values can also be used to break > anonymisation in fingerprinting attacks, so the same techniques, > precision loss and noise addition, are available for these fields as > well. > > Of course, the simplest form of anomymisation and the most extreme > form of generalisation is black-marker anonymisation, or full > deletion of a field from each record of the flow data. The black > marker technique is available on any type of field in a flow record. However, this may seriously and negatively impact the usefulness of the data. > [TODO: This section is incomplete; the set of techniques should be > more exhaustive.] > > 4.1. IP Address Anonymisation > > The following table gives an overview of the schemes for IP address > anonymization described in this document and their categorization. > > +-----------------------+----------------+---------------+ > | Scheme | Action | Reversibility | > +-----------------------+----------------+---------------+ > | Truncation | Generalisation | N | > | Scrambling | Substitution | Y | > | Prefix-preserving | Substitution | Y | > | Random noise addition | Substitution | N | > +-----------------------+----------------+---------------+ > > [TODO: This section is incomplete; text here should expand on the > table.] > > 4.2. Timestamp Anonymisation > > [TODO: as section 4.1] > > [EDITOR'S NOTE: Counters might go here, since they are subject to the > same techniques for largely the same reasons.] > > > > Boschi & Trammell Expires January 8, 2009 [Page 6] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > 4.3. Anonymisation of Other Flow Fields > > [TODO: as section 4.1] > > [EDITOR'S NOTE: Port Numbers go here. Counters might, if not above. > It might make sense to split this into flow key anonymisation versus > flow value anonymisation.] While key fields are necessarily unique, non-key fields may also be unique depending on the observed traffic. Clearly it's the uniqueness rather than the key/non-key~ness that defines the need to anonymise the field. > > > 5. Parameters for the Description of Anonymisation Techniques > > [TODO: see corresponding section of draft-ietf-psamp-sample-tech for > the proposed structure of this section.] > > > 6. Anonymisation Support in IPFIX > > [TODO: Here we'll describe how the information specified above can be > transmitted on the wire using an option template. The idea is to > scope the option to the Template ID and for each field specify which > are anonymised, providing info on the ountion in the > literature has been paid to IP addresses [TODO: cite]. IP addresses > are structured identifiers, that is, partial IP address prefixes may > be used to identify networks just as full IP addresses identify > hosts. This leads to the application of prefix-preserving > anonymisation of IP address information [TODO: cite]. Prefix- > > > > Boschi & Trammell Expires January 8, 2009 [Page 5] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > preserving anonymisation is a (generally irreversible) substitution > technique which has the additional property that the structure of the > IP address space is maintained in the anonymised data. > > While not identifiers in and of themselves, timestamps are vulnerable > to fingerprinting attacks, wherein relationships between the start > and end timestamps of flows within a data set can be used to identify > hosts or networks [TODO: cite]. Therefore, a variety of > anonymisation techniques are available, including loss of precision > (a form of generalisation), or noise addition (substitution), which > may or may not preserve the sequencing of flows in the data set. > > Counters and other flow values can also be used to break > anonymisation in fingerprinting attacks, so the same techniques, > precision loss and noise addition, are available for these fields as > well. > > Of course, the simplest form of anomymisation and the most extreme > form of generalisation is black-marker anonymisation, or full > deletion of a field from each record of the flow data. The black > marker technique is available on any type of field in a flow record. However, this may seriously and negatively impact the usefulness of the data. > [TODO: This section is incomplete; the set of techniques should be > more exhaustive.] > > 4.1. IP Address Anonymisation > > The following table gives an overview of the schemes for IP address > anonymization described in this document and their categorization. > > +-----------------------+----------------+---------------+ > | Scheme | Action | Reversibility | > +-----------------------+----------------+---------------+ > | Truncation | Generalisation | N | > | Scrambling | Substitution | Y | > | Prefix-preserving | Substitution | Y | > | Random noise addition | Substitution | N | > +-----------------------+----------------+---------------+ > > [TODO: This section is incomplete; text here should expand on the > table.] > > 4.2. Timestamp Anonymisation > > [TODO: as section 4.1] > > [EDITOR'S NOTE: Counters might go here, since they are subject to the > same techniques for largely the same reasons.] > > > > Boschi & Trammell Expires January 8, 2009 [Page 6] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > 4.3. Anonymisation of Other Flow Fields > > [TODO: as section 4.1] > > [EDITOR'S NOTE: Port Numbers go here. Counters might, if not above. > It might make sense to split this into flow key anonymisation versus > flow value anonymisation.] While key fields are necessarily unique, non-key fields may also be unique depending on the observed traffic. Clearly it's the uniqueness rather than the key/non-key~ness that defines the need to anonymise the field. > > > 5. Parameters for the Description of Anonymisation Techniques > > [TODO: see corresponding section of draft-ietf-psamp-sample-tech for > the proposed structure of this section.] > > > 6. Anonymisation Support in IPFIX > > [TODO: Here we'll describe how the information specified above can be > transmitted on the wire using an option template. The idea is to > scope the option to the Template ID and for each field specify which > are anonymised, providing info on the tput characteristics of the > technique, and which ones aren't.] > > [EDITOR'S NOTE: Multiple anon. techniques applied on an IE at the > same time is indicated with multiple elements of the same type (in > application order as in PSAMP)] Can the anonymisation be changed by re-sending the anonymisation option? Either to change the kind of anonymisation being used, or to add or remove anonymisation from some or all elements? P. > > [EDITOR'S NOTE: for blackmarking we'll recommend not to export the > information at all following the data protection law principle that > only necessary information should be exported.] > > > 7. Security Considerations > > [TODO: write this section.] > > > 8. IANA Considerations > > This document contains no actions for IANA. > > > 9. References > > 9.1. Normative References > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > > > > Boschi & Trammell Expires January 8, 2009 [Page 7] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Flow Information", RFC 5101, January 2008. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > RFC 5102, January 2008. > > 9.2. Informative References > > [I-D.ietf-ipfix-arch] > Sadasivan, G. and N. Brownlee, "Architecture Model for IP > Flow Information Export", draft-ietf-ipfix-arch-02 (work > in progress), October 2003. > > [I-D.ietf-ipfix-as] > Zseby, T., "IPFIX Applicability", draft-ietf-ipfix-as-12 > (work in progress), July 2007. > > [I-D.ietf-ipfix-architecture] > Sadasivan, G., "Architecture for IP Flow Information > Export", draft-ietf-ipfix-architecture-12 (work in > progress), September 2006. > > [I-D.ietf-ipfix-reducing-redundancy] > Boschi, E., "Reducing Redundancy in IP Flow Information > Export (IPFIX) and Packet Sampling (PSAMP) Reports", > draft-ietf-ipfix-reducing-redundancy-04 (work in > progress), May 2007. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export (IPFIX)", > RFC 3917, October 2004. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > > Authors' Addresses > > Elisa Boschi > Hitachi Europe > c/o ETH Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 57 > Email: elisa.boschi@hitachi-eu.com > > > > > Boschi & Trammell Expires January 8, 2009 [Page 8] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Brian Trammell > Hitachi Europe > c/o ETH Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 13 > Email: trammell@tik.ee.ethz.ch > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Boschi & Trammell Expires January 8, 2009 [Page 9] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITEoutput characteristics of the > technique, and which ones aren't.] > > [EDITOR'S NOTE: Multiple anon. techniques applied on an IE at the > same time is indicated with multiple elements of the same type (in > application order as in PSAMP)] Can the anonymisation be changed by re-sending the anonymisation option? Either to change the kind of anonymisation being used, or to add or remove anonymisation from some or all elements? P. > > [EDITOR'S NOTE: for blackmarking we'll recommend not to export the > information at all following the data protection law principle that > only necessary information should be exported.] > > > 7. Security Considerations > > [TODO: write this section.] > > > 8. IANA Considerations > > This document contains no actions for IANA. > > > 9. References > > 9.1. Normative References > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > > > > Boschi & Trammell Expires January 8, 2009 [Page 7] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Flow Information", RFC 5101, January 2008. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > RFC 5102, January 2008. > > 9.2. Informative References > > [I-D.ietf-ipfix-arch] > Sadasivan, G. and N. Brownlee, "Architecture Model for IP > Flow Information Export", draft-ietf-ipfix-arch-02 (work > in progress), October 2003. > > [I-D.ietf-ipfix-as] > Zseby, T., "IPFIX Applicability", draft-ietf-ipfix-as-12 > (work in progress), July 2007. > > [I-D.ietf-ipfix-architecture] > Sadasivan, G., "Architecture for IP Flow Information > Export", draft-ietf-ipfix-architecture-12 (work in > progress), September 2006. > > [I-D.ietf-ipfix-reducing-redundancy] > Boschi, E., "Reducing Redundancy in IP Flow Information > Export (IPFIX) and Packet Sampling (PSAMP) Reports", > draft-ietf-ipfix-reducing-redundancy-04 (work in > progress), May 2007. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export (IPFIX)", > RFC 3917, October 2004. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > > Authors' Addresses > > Elisa Boschi > Hitachi Europe > c/o ETH Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 57 > Email: elisa.boschi@hitachi-eu.com > > > > > Boschi & Trammell Expires January 8, 2009 [Page 8] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Brian Trammell > Hitachi Europe > c/o ETH Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 13 > Email: trammell@tik.ee.ethz.ch > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Boschi & Trammell Expires January 8, 2009 [Page 9] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMID TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Boschi & Trammell Expires January 8, 2009 [Page 10] > -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix TED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Boschi & Trammell Expires January 8, 2009 [Page 10] > -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jul 10 09:53:02 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A40228C101; Thu, 10 Jul 2008 09:53:02 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760A228C0F5 for ; Thu, 10 Jul 2008 09:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfD0qVi1nbyN for ; Thu, 10 Jul 2008 09:52:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 95E7C3A6A27 for ; Thu, 10 Jul 2008 09:52:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="14046015" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Jul 2008 16:53:11 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6AGrBCu025316 for ; Thu, 10 Jul 2008 18:53:11 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6AGrBvq004816 for ; Thu, 10 Jul 2008 16:53:11 GMT Received: from [10.61.98.15] (dhcp-10-61-98-15.cisco.com [10.61.98.15]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6AGrAi00082 for ; Thu, 10 Jul 2008 17:53:10 +0100 (BST) Message-ID: <48763E75.3020305@cisco.com> Date: Thu, 10 Jul 2008 17:53:09 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: "ipfix@ietf.org" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23404; t=1215708791; x=1216572791; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-sommer-ipfix-richtemplate-00. txt |Sender:=20; bh=jQnx47WUlyBV2zv9FMJu1Z3RyKBT/SXu6PnQdFuoEo8=; b=pbYag9TrM0xsvhWMDS0IXyR8LhMeVWNBNOyKvJYQIjj+iC37GD+egdgAi3 FPkkgtlVKZf48XtW8/Fx9dG3ZWCjcBJ9recPPOmS+zw1LdOaN5+pLkxtwwCB l9A/JJMtMM; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [IPFIX] review: draft-sommer-ipfix-richtemplate-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Chaps, Interesting draft. Please find some feedback inline. > Network Working Group C. Sommer > Internet-Draft F. Dressler > Intended status: Informational Univ. Erlangen > Expires: January 8, 2009 G. Muenz > Univ. Tuebingen > July 7, 2008 > > > Rich Template Set Extension to the IPFIX Protocol > > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January 8, 2009. > > Abstract > > This draft describes the Rich Template Set, a Template Set for the > IPFIX Protocol, as well as its respective Template Records. One > possible application domain for this new Set is the transport of > IPFIX Flow Mediation selection criteria. In comparison to the use of > Common Properties, the use of Rich Template Sets reduces the overhead > of repeated transmissions and makes data transmissions more robust > against failures. > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 1] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Rich Template . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Use of the Rich Template in Flow Aggregation . . . . . . . . . 7 > 4. Security considerations . . . . . . . . . . . . . . . . . . . 9 > 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 > 6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 > Intellectual Property and Copyright Statements . . . . . . . . . . 11 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 2] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > 1. Introduction > > IPFIX supports the concept of a Mediator, a device that receives, > transforms, and exports data streams using IPFIX. A major > requirement of flow mediation is the reduction of the volume of IPFIX > traffic by discarding and aggregating received information. > [I-D.dressler-ipfix-aggregation] describes how pattern matching is > used for flow aggregation. The draft also outlines how to select > flows and subsequently communicate the selection criteria to an IPFIX > Collector, using Common Properties of the resulting Compound Flows to > describe these attributes. In order to avoid the overhead of the > repeated transmissions of all Common Properties (or their > identifiers) in all Flow Records, a new Template Set, the Rich > Template Set, is introduced. This Template Set allows an Exporting > Process to simultaneously declare and transmit Common Properties to a > receiver. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 3] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > 2. Rich Template > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 4 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Rich Template Record 1 | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | ... | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Rich Template Record N | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Padding (opt) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1: Rich Template Set Format > > The basic format of a Rich Template Set is shown in Figure 1. It is > the same as that of a Template Set defined in [RFC5101], except for a > different Set ID. I'd prefer to see the pertinent fields specified at this point rather than below figure 2. > > The format of individual Rich Template Records, however, differs from > that of Template Records and is shown in Figure 2. > > > > > > > > > > > > > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 4] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID (> 255) | Field Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data Count | Common Properties ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Field 1 Specifier | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | ... | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Field N Specifier | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Data 1 Specifier | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | ... | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Data M Specifier | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Data 1 Value | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | ... | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Data M Value | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2: Rich Template Record Format It might be more logical to put each "Data M Value" right after each "Data M Specifier" to make a list of {T,L,V} tuples, rather than {T,L}, {T,L}, {T,L}, .... {V}, {V}, {V}. > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 5] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > The Rich Template Set field definitions are as follows: > > Set ID > Type of this Template Set. A Set ID value of 4 is proposed for the > Rich Template Set. > > Length > Total length of this set in bytes, as defined in [RFC5101]. > > Padding > OPTIONAL padding, as defined in [RFC5101]. I'd prefer to move the above field definitions to above figure 2. > The Rich Template Record field definitions are as follows: > > Template ID > Template ID of this Rich Template Record. As defined in > [RFC5101], this value MUST be greater than 255. > > Field Count > Number of regular fields that will be sent in subsequent Data > Records using this Template, as defined in [RFC5101]. > > Data Count > Number of fixed-value fields that will be sent in this Template. > > Common Properties ID > Contains an identifier that can be referred to by > commonPropertiesId Information Elements, as introduced in > [I-D.ietf-ipfix-reducing-redundancy]. > > Field N Specifier > Information Element identifier, Field length and an Enterprise > Number (if applicable) of field N. Refer to [RFC5101] for more > information on Field Specifiers. > > Data M Specifier > Same as "Field N Specifier", but used for Common Properties of all > Data Records of this Template. Together with Data M Value, a > similar encoding like TLV (type-length-value) is achieved. > > Data M Value > Bit representation of a Common Property as would be transmitted in > a Data Record. > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 6] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > 3. Use of the Rich Template in Flow Aggregation > > The Rich Template is well-suited for use in flow aggregation, as > introduced in [I-D.dressler-ipfix-aggregation]. Table 1 illustrates > the relationship between a flow aggregator's field modifiers and > patterns on the one hand, and the resulting regular and fixed-value > fields in the Rich Template on the other hand. It can be seen that > the analyzer is able to deduce all instructions of the Aggregation > Rule considering the structure of the Rich Template, except the > combination "discard without pattern" that does not result in any > field. > > +----------+---------+------------------------+---------------------+ > | field | pattern | field in Flow Record | fixed-value field | > | modifier | | | in Rich Template | > +----------+---------+------------------------+---------------------+ > | discard | no | N/A | N/A | > | discard | yes | N/A | yes, contains | > | | | | pattern | > | keep | no | yes | N/A | > | keep | yes | yes, if pattern | yes, contains | > | | | specifies a range of | pattern | > | | | values | | > | mask | no | yes, IP network | N/A | > | | | address | | > | mask | yes | yes, IP network | yes, contains | > | | | address | pattern | > +----------+---------+------------------------+---------------------+ > > Table 1: Relation between field modifiers, Flow Records, and Rich > Templates > > Assume, for example, the concentrator was given the Aggregation Rule > shown in Table 2. > > +-------------------------+--------------+-------------+ > | IPFIX Field | Filtering | Aggregation | > +-------------------------+--------------+-------------+ > | sourceIPv4Address | 192.0.2.0/28 | discard | > | destinatonTransportPort | | keep | > | packetDeltaCount | | aggregate | > +-------------------------+--------------+-------------+ > > Table 2: Example Rule > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 7] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > Based on the Aggregation Rule, the concentrator would now first send > a corresponding Rich Template Record as shown in Table 3. > > +----------------------+------------------+ > | Field | Value | > +----------------------+------------------+ > | Template ID | 10001 | > | Field Count | 2 | > | Data Count | 2 | > | Common Properties ID | 0 | > | Field 1 Type | Destination Port | > | Field 2 Type | Packets | > | Data 1 Type | Source IP Prefix | > | Data 2 Type | Source IP Mask | > | Data 1 Value | 192.0.2.0 | > | Data 2 Value | 28 | > +----------------------+------------------+ > > Table 3: Rich Template used > > Assume further that the concentrator receives the Flow Records shown > in Table 4. > > +-------------+-----------+--------------+----------------+---------+ > | Source IP | Source | Destination | Destination | Packets | > | | Port | IP | Port | | > +-------------+-----------+--------------+----------------+---------+ > | 192.0.2.1 | 64235 | 192.0.2.101 | 80 | 10 | > | 192.0.2.2 | 64236 | 192.0.2.102 | 110 | 10 | > | 192.0.2.3 | 64237 | 192.0.2.103 | 80 | 10 | > | 192.0.2.101 | 64238 | 192.0.2.1 | 80 | 10 | > | 192.0.2.102 | 64239 | 192.0.2.2 | 80 | 10 | > +-------------+-----------+--------------+----------------+---------+ > > Table 4: Incoming Flows > > The concentrator would then export Data Records of this type, which > contain the Compound Flows resulting from aggregation. Note that the > Flows' Common Property, having a source IP address in 192.0.2.0/28, > was already transmitted in the Rich Template Record and is thus not > included in Data Records. > > > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 8] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > The exported Data Records, shown in Table 5, only contain the > aggregated packet counts and the destination port, the latter being > the only discriminating Flow Key property. > > +------------------+---------+ > | Destination Port | Packets | > +------------------+---------+ > | 80 | 20 | > | 110 | 10 | > +------------------+---------+ > > Table 5: Aggregated Flows > > Some example Rich Template Records would be perfect! P. > 4. Security considerations > > This document introduces a new IPFIX Template Set, a variation on the > Template Set and data types introduced in [RFC5101] and > [I-D.ietf-ipfix-reducing-redundancy]. No additional security > considerations apply. > > > 5. IANA Considerations > > Use of the Rich Template Set requires one new IPFIX Set ID to be > assigned. > > > 6. Normative References > > [I-D.dressler-ipfix-aggregation] > Dressler, F., "IPFIX Aggregation", > draft-dressler-ipfix-aggregation-05 (work in progress), > July 2008. > > [I-D.ietf-ipfix-reducing-redundancy] > Boschi, E., "Reducing Redundancy in IP Flow Information > Export (IPFIX) and Packet Sampling (PSAMP) Reports", > draft-ietf-ipfix-reducing-redundancy-04 (work in > progress), May 2007. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 9] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > Authors' Addresses > > Christoph Sommer > University of Erlangen-Nuremberg > Department of Computer Science 7 > Martensstr. 3 > Erlangen 91058 > Germany > > Phone: +49 9131 85-27993 > Email: christoph.sommer@informatik.uni-erlangen.de > URI: http://www7.informatik.uni-erlangen.de/~sommer/ > > > Falko Dressler > University of Erlangen-Nuremberg > Department of Computer Science 7 > Martensstr. 3 > Erlangen 91058 > Germany > > Phone: +49 9131 85-27914 > Email: dressler@informatik.uni-erlangen.de > URI: http://www7.informatik.uni-erlangen.de/ > > > Gerhard Muenz > University of Tuebingen > Computer Networks and Internet > Sand 13 > Tuebingen 72076 > Germany > > Phone: +49 7071 29-70534 > Email: muenz@informatik.uni-tuebingen.de > URI: http://net.informatik.uni-tuebingen.de/ > > > > > > > > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 10] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 11] > -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jul 10 09:53:02 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A40228C101; Thu, 10 Jul 2008 09:53:02 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760A228C0F5 for ; Thu, 10 Jul 2008 09:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfD0qVi1nbyN for ; Thu, 10 Jul 2008 09:52:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 95E7C3A6A27 for ; Thu, 10 Jul 2008 09:52:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,339,1212364800"; d="scan'208";a="14046015" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Jul 2008 16:53:11 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6AGrBCu025316 for ; Thu, 10 Jul 2008 18:53:11 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6AGrBvq004816 for ; Thu, 10 Jul 2008 16:53:11 GMT Received: from [10.61.98.15] (dhcp-10-61-98-15.cisco.com [10.61.98.15]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6AGrAi00082 for ; Thu, 10 Jul 2008 17:53:10 +0100 (BST) Message-ID: <48763E75.3020305@cisco.com> Date: Thu, 10 Jul 2008 17:53:09 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 MIME-Version: 1.0 To: "ipfix@ietf.org" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23404; t=1215708791; x=1216572791; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-sommer-ipfix-richtemplate-00. txt |Sender:=20; bh=jQnx47WUlyBV2zv9FMJu1Z3RyKBT/SXu6PnQdFuoEo8=; b=pbYag9TrM0xsvhWMDS0IXyR8LhMeVWNBNOyKvJYQIjj+iC37GD+egdgAi3 FPkkgtlVKZf48XtW8/Fx9dG3ZWCjcBJ9recPPOmS+zw1LdOaN5+pLkxtwwCB l9A/JJMtMM; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [IPFIX] review: draft-sommer-ipfix-richtemplate-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Chaps, Interesting draft. Please find some feedback inline. > Network Working Group C. Sommer > Internet-Draft F. Dressler > Intended status: Informational Univ. Erlangen > Expires: January 8, 2009 G. Muenz > Univ. Tuebingen > July 7, 2008 > > > Rich Template Set Extension to the IPFIX Protocol > > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January 8, 2009. > > Abstract > > This draft describes the Rich Template Set, a Template Set for the > IPFIX Protocol, as well as its respective Template Records. One > possible application domain for this new Set is the transport of > IPFIX Flow Mediation selection criteria. In comparison to the use of > Common Properties, the use of Rich Template Sets reduces the overhead > of repeated transmissions and makes data transmissions more robust > against failures. > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 1] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Rich Template . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Use of the Rich Template in Flow Aggregation . . . . . . . . . 7 > 4. Security considerations . . . . . . . . . . . . . . . . . . . 9 > 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 > 6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 > Intellectual Property and Copyright Statements . . . . . . . . . . 11 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 2] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > 1. Introduction > > IPFIX supports the concept of a Mediator, a device that receives, > transforms, and exports data streams using IPFIX. A major > requirement of flow mediation is the reduction of the volume of IPFIX > traffic by discarding and aggregating received information. > [I-D.dressler-ipfix-aggregation] describes how pattern matching is > used for flow aggregation. The draft also outlines how to select > flows and subsequently communicate the selection criteria to an IPFIX > Collector, using Common Properties of the resulting Compound Flows to > describe these attributes. In order to avoid the overhead of the > repeated transmissions of all Common Properties (or their > identifiers) in all Flow Records, a new Template Set, the Rich > Template Set, is introduced. This Template Set allows an Exporting > Process to simultaneously declare and transmit Common Properties to a > receiver. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 3] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > 2. Rich Template > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 4 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Rich Template Record 1 | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | ... | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Rich Template Record N | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Padding (opt) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1: Rich Template Set Format > > The basic format of a Rich Template Set is shown in Figure 1. It is > the same as that of a Template Set defined in [RFC5101], except for a > different Set ID. I'd prefer to see the pertinent fields specified at this point rather than below figure 2. > > The format of individual Rich Template Records, however, differs from > that of Template Records and is shown in Figure 2. > > > > > > > > > > > > > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 4] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID (> 255) | Field Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data Count | Common Properties ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Field 1 Specifier | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | ... | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Field N Specifier | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Data 1 Specifier | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | ... | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Data M Specifier | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Data 1 Value | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | ... | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Data M Value | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2: Rich Template Record Format It might be more logical to put each "Data M Value" right after each "Data M Specifier" to make a list of {T,L,V} tuples, rather than {T,L}, {T,L}, {T,L}, .... {V}, {V}, {V}. > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 5] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > The Rich Template Set field definitions are as follows: > > Set ID > Type of this Template Set. A Set ID value of 4 is proposed for the > Rich Template Set. > > Length > Total length of this set in bytes, as defined in [RFC5101]. > > Padding > OPTIONAL padding, as defined in [RFC5101]. I'd prefer to move the above field definitions to above figure 2. > The Rich Template Record field definitions are as follows: > > Template ID > Template ID of this Rich Template Record. As defined in > [RFC5101], this value MUST be greater than 255. > > Field Count > Number of regular fields that will be sent in subsequent Data > Records using this Template, as defined in [RFC5101]. > > Data Count > Number of fixed-value fields that will be sent in this Template. > > Common Properties ID > Contains an identifier that can be referred to by > commonPropertiesId Information Elements, as introduced in > [I-D.ietf-ipfix-reducing-redundancy]. > > Field N Specifier > Information Element identifier, Field length and an Enterprise > Number (if applicable) of field N. Refer to [RFC5101] for more > information on Field Specifiers. > > Data M Specifier > Same as "Field N Specifier", but used for Common Properties of all > Data Records of this Template. Together with Data M Value, a > similar encoding like TLV (type-length-value) is achieved. > > Data M Value > Bit representation of a Common Property as would be transmitted in > a Data Record. > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 6] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > 3. Use of the Rich Template in Flow Aggregation > > The Rich Template is well-suited for use in flow aggregation, as > introduced in [I-D.dressler-ipfix-aggregation]. Table 1 illustrates > the relationship between a flow aggregator's field modifiers and > patterns on the one hand, and the resulting regular and fixed-value > fields in the Rich Template on the other hand. It can be seen that > the analyzer is able to deduce all instructions of the Aggregation > Rule considering the structure of the Rich Template, except the > combination "discard without pattern" that does not result in any > field. > > +----------+---------+------------------------+---------------------+ > | field | pattern | field in Flow Record | fixed-value field | > | modifier | | | in Rich Template | > +----------+---------+------------------------+---------------------+ > | discard | no | N/A | N/A | > | discard | yes | N/A | yes, contains | > | | | | pattern | > | keep | no | yes | N/A | > | keep | yes | yes, if pattern | yes, contains | > | | | specifies a range of | pattern | > | | | values | | > | mask | no | yes, IP network | N/A | > | | | address | | > | mask | yes | yes, IP network | yes, contains | > | | | address | pattern | > +----------+---------+------------------------+---------------------+ > > Table 1: Relation between field modifiers, Flow Records, and Rich > Templates > > Assume, for example, the concentrator was given the Aggregation Rule > shown in Table 2. > > +-------------------------+--------------+-------------+ > | IPFIX Field | Filtering | Aggregation | > +-------------------------+--------------+-------------+ > | sourceIPv4Address | 192.0.2.0/28 | discard | > | destinatonTransportPort | | keep | > | packetDeltaCount | | aggregate | > +-------------------------+--------------+-------------+ > > Table 2: Example Rule > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 7] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > Based on the Aggregation Rule, the concentrator would now first send > a corresponding Rich Template Record as shown in Table 3. > > +----------------------+------------------+ > | Field | Value | > +----------------------+------------------+ > | Template ID | 10001 | > | Field Count | 2 | > | Data Count | 2 | > | Common Properties ID | 0 | > | Field 1 Type | Destination Port | > | Field 2 Type | Packets | > | Data 1 Type | Source IP Prefix | > | Data 2 Type | Source IP Mask | > | Data 1 Value | 192.0.2.0 | > | Data 2 Value | 28 | > +----------------------+------------------+ > > Table 3: Rich Template used > > Assume further that the concentrator receives the Flow Records shown > in Table 4. > > +-------------+-----------+--------------+----------------+---------+ > | Source IP | Source | Destination | Destination | Packets | > | | Port | IP | Port | | > +-------------+-----------+--------------+----------------+---------+ > | 192.0.2.1 | 64235 | 192.0.2.101 | 80 | 10 | > | 192.0.2.2 | 64236 | 192.0.2.102 | 110 | 10 | > | 192.0.2.3 | 64237 | 192.0.2.103 | 80 | 10 | > | 192.0.2.101 | 64238 | 192.0.2.1 | 80 | 10 | > | 192.0.2.102 | 64239 | 192.0.2.2 | 80 | 10 | > +-------------+-----------+--------------+----------------+---------+ > > Table 4: Incoming Flows > > The concentrator would then export Data Records of this type, which > contain the Compound Flows resulting from aggregation. Note that the > Flows' Common Property, having a source IP address in 192.0.2.0/28, > was already transmitted in the Rich Template Record and is thus not > included in Data Records. > > > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 8] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > The exported Data Records, shown in Table 5, only contain the > aggregated packet counts and the destination port, the latter being > the only discriminating Flow Key property. > > +------------------+---------+ > | Destination Port | Packets | > +------------------+---------+ > | 80 | 20 | > | 110 | 10 | > +------------------+---------+ > > Table 5: Aggregated Flows > > Some example Rich Template Records would be perfect! P. > 4. Security considerations > > This document introduces a new IPFIX Template Set, a variation on the > Template Set and data types introduced in [RFC5101] and > [I-D.ietf-ipfix-reducing-redundancy]. No additional security > considerations apply. > > > 5. IANA Considerations > > Use of the Rich Template Set requires one new IPFIX Set ID to be > assigned. > > > 6. Normative References > > [I-D.dressler-ipfix-aggregation] > Dressler, F., "IPFIX Aggregation", > draft-dressler-ipfix-aggregation-05 (work in progress), > July 2008. > > [I-D.ietf-ipfix-reducing-redundancy] > Boschi, E., "Reducing Redundancy in IP Flow Information > Export (IPFIX) and Packet Sampling (PSAMP) Reports", > draft-ietf-ipfix-reducing-redundancy-04 (work in > progress), May 2007. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 9] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > Authors' Addresses > > Christoph Sommer > University of Erlangen-Nuremberg > Department of Computer Science 7 > Martensstr. 3 > Erlangen 91058 > Germany > > Phone: +49 9131 85-27993 > Email: christoph.sommer@informatik.uni-erlangen.de > URI: http://www7.informatik.uni-erlangen.de/~sommer/ > > > Falko Dressler > University of Erlangen-Nuremberg > Department of Computer Science 7 > Martensstr. 3 > Erlangen 91058 > Germany > > Phone: +49 9131 85-27914 > Email: dressler@informatik.uni-erlangen.de > URI: http://www7.informatik.uni-erlangen.de/ > > > Gerhard Muenz > University of Tuebingen > Computer Networks and Internet > Sand 13 > Tuebingen 72076 > Germany > > Phone: +49 7071 29-70534 > Email: muenz@informatik.uni-tuebingen.de > URI: http://net.informatik.uni-tuebingen.de/ > > > > > > > > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 10] > > Internet-Draft Rich Template Set IPFIX Extension July 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Sommer, et al. draft-sommer-ipfix-richtemplate-00.txt [Page 11] > -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jul 10 22:11:22 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745FE3A6AF7; Thu, 10 Jul 2008 22:11:22 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BAE63A6AF7 for ; Thu, 10 Jul 2008 22:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyeC3UEF0mEe for ; Thu, 10 Jul 2008 22:11:20 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 7FCC03A6ADF for ; Thu, 10 Jul 2008 22:11:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 15FA6D9451; Fri, 11 Jul 2008 07:11:31 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UWzW2UFXKmzo; Fri, 11 Jul 2008 07:11:30 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id DF14ED933D; Fri, 11 Jul 2008 07:11:30 +0200 (MEST) In-Reply-To: <48763E72.8070905@cisco.com> References: <48763E72.8070905@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <01339BE7-9B53-42E6-AC7E-3D68F43414DB@tik.ee.ethz.ch> From: Brian Trammell Date: Fri, 11 Jul 2008 07:11:29 +0200 To: Paul Aitken X-Mailer: Apple Mail (2.753.1) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] review: draft-boschi-ipfix-anon-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, Thanks for the review! One specific tiny point inline, below; more substantive discussion will follow in a later message. On Jul 10, 2008, at 6:53 PM, Paul Aitken wrote: > Dear Brian and Elisa, > > An interesting and promising draft. Please find some comments inline. > > >> >> 1.2. IPFIX Documents Overview >> "Specification of the IPFIX Protocol for the Exchange of IP >> Traffic >> Flow Information" [RFC5101] (informally, the IPFIX Protocol >> document) > > I would prefer not to invent local names for these documents, but > to use > [RFC5101] throughout for clarity. Also so that automated tools can > generate links correctly when parsing the text. Would have preferred not to do so myself. This language is lifted from earlier revs of the file draft, which used informal local names before there was a short formal one (i.e., when everything was still draft-ietf-ipfix-longish-sort-of-name-rev). I'm getting file-02 ready for Dublin, and will make the changes you suggest for anon there, as well. We still have this problem a bit with other not-yet-RFCs, but since the informal names are mainly used only From ipfix-bounces@ietf.org Thu Jul 10 22:11:22 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745FE3A6AF7; Thu, 10 Jul 2008 22:11:22 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BAE63A6AF7 for ; Thu, 10 Jul 2008 22:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyeC3UEF0mEe for ; Thu, 10 Jul 2008 22:11:20 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 7FCC03A6ADF for ; Thu, 10 Jul 2008 22:11:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 15FA6D9451; Fri, 11 Jul 2008 07:11:31 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UWzW2UFXKmzo; Fri, 11 Jul 2008 07:11:30 +0200 (MEST) Received: from [82.130.103.156] (pb-4053.ethz.ch [82.130.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id DF14ED933D; Fri, 11 Jul 2008 07:11:30 +0200 (MEST) In-Reply-To: <48763E72.8070905@cisco.com> References: <48763E72.8070905@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <01339BE7-9B53-42E6-AC7E-3D68F43414DB@tik.ee.ethz.ch> From: Brian Trammell Date: Fri, 11 Jul 2008 07:11:29 +0200 To: Paul Aitken X-Mailer: Apple Mail (2.753.1) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] review: draft-boschi-ipfix-anon-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, Thanks for the review! One specific tiny point inline, below; more substantive discussion will follow in a later message. On Jul 10, 2008, at 6:53 PM, Paul Aitken wrote: > Dear Brian and Elisa, > > An interesting and promising draft. Please find some comments inline. > > >> >> 1.2. IPFIX Documents Overview >> "Specification of the IPFIX Protocol for the Exchange of IP >> Traffic >> Flow Information" [RFC5101] (informally, the IPFIX Protocol >> document) > > I would prefer not to invent local names for these documents, but > to use > [RFC5101] throughout for clarity. Also so that automated tools can > generate links correctly when parsing the text. Would have preferred not to do so myself. This language is lifted from earlier revs of the file draft, which used informal local names before there was a short formal one (i.e., when everything was still draft-ietf-ipfix-longish-sort-of-name-rev). I'm getting file-02 ready for Dublin, and will make the changes you suggest for anon there, as well. We still have this problem a bit with other not-yet-RFCs, but since the informal names are mainly used only inin this section, I'll see what I can do. Thanks for pointing this out, in any case; there's been a bit of linguistic drift in some of these documents over the years they've been in development, and it can be hard to see sometimes... Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix this section, I'll see what I can do. Thanks for pointing this out, in any case; there's been a bit of linguistic drift in some of these documents over the years they've been in development, and it can be hard to see sometimes... Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Jul 14 00:45:12 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5993A6784; Mon, 14 Jul 2008 00:45:11 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D561E3A685E; Mon, 14 Jul 2008 00:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714074501.D561E3A685E@core3.amsl.com> Date: Mon, 14 Jul 2008 00:45:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mib-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Definitions of Managed Objects for IP Flow Information Export Author(s) : T. Dietz, et al. Filename : draft-ietf-ipfix-mib-04.txt Pages : 63 Date : 2008-07-14 This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14003854.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Jul 14 00:45:12 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5993A6784; Mon, 14 Jul 2008 00:45:11 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D561E3A685E; Mon, 14 Jul 2008 00:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714074501.D561E3A685E@core3.amsl.com> Date: Mon, 14 Jul 2008 00:45:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mib-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Definitions of Managed Objects for IP Flow Information Export Author(s) : T. Dietz, et al. Filename : draft-ietf-ipfix-mib-04.txt Pages : 63 Date : 2008-07-14 This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14003854.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Jul 14 01:15:04 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36653A6B44; Mon, 14 Jul 2008 01:15:04 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8D4233A69A4; Mon, 14 Jul 2008 01:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714081501.8D4233A69A4@core3.amsl.com> Date: Mon, 14 Jul 2008 01:15:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-exporting-type-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Exporting Type Information for IPFIX Information Elements Author(s) : E. Boschi, et al. Filename : draft-ietf-ipfix-exporting-type-02.txt Pages : 20 Date : 2008-07-14 This document describes an extension to IPFIX to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise- specific Information Elements, facilitating interoperability and reusability among a wide variety of applications and tools. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-exporting-type-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-exporting-type-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14010415.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Jul 14 01:15:04 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36653A6B44; Mon, 14 Jul 2008 01:15:04 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8D4233A69A4; Mon, 14 Jul 2008 01:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714081501.8D4233A69A4@core3.amsl.com> Date: Mon, 14 Jul 2008 01:15:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-exporting-type-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Exporting Type Information for IPFIX Information Elements Author(s) : E. Boschi, et al. Filename : draft-ietf-ipfix-exporting-type-02.txt Pages : 20 Date : 2008-07-14 This document describes an extension to IPFIX to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise- specific Information Elements, facilitating interoperability and reusability among a wide variety of applications and tools. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-exporting-type-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-exporting-type-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14010415.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Jul 14 07:45:02 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698D93A6842; Mon, 14 Jul 2008 07:45:02 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DD1683A6842; Mon, 14 Jul 2008 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714144501.DD1683A6842@core3.amsl.com> Date: Mon, 14 Jul 2008 07:45:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-file-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : An IPFIX-Based File Format Author(s) : B. Trammell, et al. Filename : draft-ietf-ipfix-file-02.txt Pages : 53 Date : 2008-07-14 This document describes a file format for the storage of flow data based upon the IPFIX Message format. It proposes a set of requirements for flat-file, binary flow data file formats, then applies the IPFIX message format to these requirements to build a new file format. This IPFIX-based file format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-file-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-file-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14073434.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Jul 14 07:45:02 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698D93A6842; Mon, 14 Jul 2008 07:45:02 -0700 (PDT) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DD1683A6842; Mon, 14 Jul 2008 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714144501.DD1683A6842@core3.amsl.com> Date: Mon, 14 Jul 2008 07:45:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-file-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : An IPFIX-Based File Format Author(s) : B. Trammell, et al. Filename : draft-ietf-ipfix-file-02.txt Pages : 53 Date : 2008-07-14 This document describes a file format for the storage of flow data based upon the IPFIX Message format. It proposes a set of requirements for flat-file, binary flow data file formats, then applies the IPFIX message format to these requirements to build a new file format. This IPFIX-based file format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-file-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-file-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14073434.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Tue Jul 15 00:13:43 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC0B3A6881; Tue, 15 Jul 2008 00:13:43 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3B23A6976 for ; Tue, 15 Jul 2008 00:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQV-WmmTiULw for ; Tue, 15 Jul 2008 00:13:41 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id AB0793A6881 for ; Tue, 15 Jul 2008 00:13:41 -0700 (PDT) Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 96C744B00 for ; Tue, 15 Jul 2008 09:14:06 +0200 (MEST) Received: from [131.188.37.96] (faui7m16 [131.188.37.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTP id 764D9B0038 for ; Tue, 15 Jul 2008 09:14:06 +0200 (CEST) Message-ID: <487C4E3E.7070509@informatik.uni-erlangen.de> Date: Tue, 15 Jul 2008 09:14:06 +0200 From: Christoph Sommer User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: ipfix@ietf.org X-Enigmail-Version: 0.95.0 Subject: [IPFIX] IPFIX Flow Aggregation - draft-dressler-ipfix-aggregation-05.txt and draft-sommer-ipfix-mediator-ext-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all, based on your suggestions, aggregation techniques are now split up to form three separate drafts. New versions of these are now available, all quite mature. I'd really like to invite everybody to read and bash! The drafts are: - Flow Selection - Compound Flow Creation - New abstract data types: orderedList, orderedPair, portRanges - New data type: excludedPropertiesId - New flow template: Rich Template Cheers, Christoph _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Jul 15 00:13:43 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC0B3A6881; Tue, 15 Jul 2008 00:13:43 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3B23A6976 for ; Tue, 15 Jul 2008 00:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQV-WmmTiULw for ; Tue, 15 Jul 2008 00:13:41 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id AB0793A6881 for ; Tue, 15 Jul 2008 00:13:41 -0700 (PDT) Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 96C744B00 for ; Tue, 15 Jul 2008 09:14:06 +0200 (MEST) Received: from [131.188.37.96] (faui7m16 [131.188.37.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTP id 764D9B0038 for ; Tue, 15 Jul 2008 09:14:06 +0200 (CEST) Message-ID: <487C4E3E.7070509@informatik.uni-erlangen.de> Date: Tue, 15 Jul 2008 09:14:06 +0200 From: Christoph Sommer User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: ipfix@ietf.org X-Enigmail-Version: 0.95.0 Subject: [IPFIX] IPFIX Flow Aggregation - draft-dressler-ipfix-aggregation-05.txt and draft-sommer-ipfix-mediator-ext-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all, based on your suggestions, aggregation techniques are now split up to form three separate drafts. New versions of these are now available, all quite mature. I'd really like to invite everybody to read and bash! The drafts are: - Flow Selection - Compound Flow Creation - New abstract data types: orderedList, orderedPair, portRanges - New data type: excludedPropertiesId - New flow template: Rich Template Cheers, Christoph _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From refunds@IRS.gov Tue Jul 15 06:56:08 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A223A693A for ; Tue, 15 Jul 2008 06:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.349 X-Spam-Level: X-Spam-Status: No, score=-90.349 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FORGED_MUA_OUTLOOK=3.116, J_CHICKENPOX_71=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgsTbEbSElY1 for ; Tue, 15 Jul 2008 06:56:07 -0700 (PDT) Received: from beldico.be (24.182-136-217.adsl-static.isp.belgacom.be [217.136.182.24]) by core3.amsl.com (Postfix) with ESMTP id 5B0DD3A684A for ; Tue, 15 Jul 2008 06:56:05 -0700 (PDT) Received: from User ([67.205.91.201]) by beldico.be with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 15:47:40 +0200 Reply-To: From: "Internal Revenue Service" Subject: Second Notice : Tax Refund ID NHITENPWFC Date: Tue, 15 Jul 2008 09:45:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 15 Jul 2008 13:47:40.0140 (UTC) FILETIME=[592DC2C0:01C8E681] To: undisclosed-recipients:; Dear Applicant: After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund under section 501(c) (3) of the Internal Revenue Code. Tax refund value is $322.70.Please submit the tax refund request and allow us 3-6 days in order to IWP the data received. -If you distribute funds to other organization, your records must show wether they are exempt under section 497 (c) (15). In cases where the recipient org. is not exempt under section 497 (c) (15), you must have evidence the funds will be used for section 497 (c) (15) purposes. -If you distribute fund to individuals, you should keep case histories showing the recipient's name and address; the purpose of the award; the maner of section; and the realtionship of the recipient to any of your officers, directors, trustees, members, or major contributors. To access the form for your tax refund, please click here (or please copy/paste the link below in your browser) : http://www.whereisitnow.com.au:8080/Tax_Refund/IRS.gov/index.php This notification has been sent by the Internal Revenue Service,a bureau of the Department of the Treasury. ______________________________________________________________________________ Note: -If you received this message in your SPAM/BULK folder, that is because of the restrictions implemented by your ISP - For security reasons, we will record your ip address, the date and time. -Deliberate wrong imputs are criminally pursued and indicted. © Copyright 2008, Internal Revenue Service U.S.A. Tax ID : PCJUOQFVMBLIUBZOVJZUZRTYLOLIJVWEKLSRWI From ipfix-bounces@ietf.org Tue Jul 15 16:21:35 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5F43A699F; Tue, 15 Jul 2008 16:21:35 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE67A3A6A36 for ; Tue, 15 Jul 2008 16:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[AWL=1.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3WsZD6873SU for ; Tue, 15 Jul 2008 16:21:33 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id D0A673A696A for ; Tue, 15 Jul 2008 16:21:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 793F1480620 for ; Wed, 16 Jul 2008 11:21:30 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIrDAN8BiHyw for ; Wed, 16 Jul 2008 11:21:30 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 45DD348059B for ; Wed, 16 Jul 2008 11:21:30 +1200 (NZST) Message-ID: <487D30FA.5090801@auckland.ac.nz> Date: Wed, 16 Jul 2008 11:21:30 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] WG Agenda for Dublin X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've had several requests for changes to the agenda, they're all added into the revised version below (and on the meeting Agendas page). Please note that the times I've allocated for each item are only rough estimates, and that priority goes to the work we have in our WG charter. It's great to see that lots of works is being done that's generating new IPFIX-related drafts, but remember that the mailing list is the primary place for discussion of IPFIX matters. I, alas, won't be at the Dublin meeting, so Juergen will chair the session. He'll need a minute-taker and a Jabber Scribe (both vital roles, particularly for folk who can't attend in person). If you'll be at the Dublin meeting, do please consider volunteering for one of them! Last, if you're presenting, please send a copy of your slides to Juergen (and/or to me) so that we can get them onto the Meeting Materials page *before* the meeting. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373From ipfix-bounces@ietf.org Tue Jul 15 16:21:35 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5F43A699F; Tue, 15 Jul 2008 16:21:35 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE67A3A6A36 for ; Tue, 15 Jul 2008 16:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[AWL=1.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3WsZD6873SU for ; Tue, 15 Jul 2008 16:21:33 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id D0A673A696A for ; Tue, 15 Jul 2008 16:21:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 793F1480620 for ; Wed, 16 Jul 2008 11:21:30 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIrDAN8BiHyw for ; Wed, 16 Jul 2008 11:21:30 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 45DD348059B for ; Wed, 16 Jul 2008 11:21:30 +1200 (NZST) Message-ID: <487D30FA.5090801@auckland.ac.nz> Date: Wed, 16 Jul 2008 11:21:30 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] WG Agenda for Dublin X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've had several requests for changes to the agenda, they're all added into the revised version below (and on the meeting Agendas page). Please note that the times I've allocated for each item are only rough estimates, and that priority goes to the work we have in our WG charter. It's great to see that lots of works is being done that's generating new IPFIX-related drafts, but remember that the mailing list is the primary place for discussion of IPFIX matters. I, alas, won't be at the Dublin meeting, so Juergen will chair the session. He'll need a minute-taker and a Jabber Scribe (both vital roles, particularly for folk who can't attend in person). If you'll be at the Dublin meeting, do please consider volunteering for one of them! Last, if you're presenting, please send a copy of your slides to Juergen (and/or to me) so that we can get them onto the Meeting Materials page *before* the meeting. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand ====================================================== IP Flow Information Export WG (ipfix) IETF #72, Dublin Monday, 28 Jul 08 at 1740-1950 ====================================================== Chairs: Nevil Brownlee Juergen Quittek AGENDA: 1. Agenda review WG Status = 5 min 2. Internet-Draft status =10 min [In RFC Editor queue: - draft-ietf-ipfix-architecture-12.txt - draft-ietf-ipfix-as-12.txt - draft-ietf-ipfix-reducing-redundancy-04.txt - draft-ietf-ipfix-testing-04.txt ] - draft-ietf-psamp-framework-13.txt [Nick Duffield] Jun 08 - draft-ietf-psamp-sample-tech-10.txt [Tanja Zseby] Jun 07 - draft-ietf-psamp-protocol-09.txt [Benoit Claise] Dec 07 - draft-ietf-psamp-info-07.txt [Thomas Dietz] Oct 07 3. Information Element Registry status = 5 min IANA are working on this, it will have the IEs from RFC 5102 and draft-aitken-ipfix-new-infos-01.txt 3. Drafts from the old charter .. = 10 min a) IPFIX MIB (Thomas Dietz) - draft-dietz-ipfix-mib-04.txt Jul 08 4. New WG drafts = 55 min a) IPFIX File Format (Brian Trammell) ( 5 min) - draft-ietf-ipfix-file-02.txt Jul 08 b) Exporting Type Information for IPFIX IEs (Elisa Boschi) - draft-ietf-ipfix-exporting-type-02.txt Jul 08 ( 5 min) c) Configuration Data Model (10 min) - draft-ietf-ipfix-configuration-model-00.txt d) IPFIX Per-Stream SCTP reporting (Benoit CLaise) ( 5 min) - draft-ietf-ipfix-export-per-sctp-stream-00.txt e) IPFIX Mediation: Problem Statement (Kobayashi Atsushi) - draft-ietf-ipfix-mediators-problem-statement-00.txt - draft-ietf-ipfix-mediators-framework-00.txt (30 min) 6. Other Drafts =32 min a) Aggregation (Christophe Sommer) (16 min) - draft-dressler-ipfix-aggregation-05 - draft-sommer-ipfix-mediator-ext-01 - draft-sommer-ipfix-richtemplate-00 Jul 08 b) Compression (Gerhard Muenz) ( 8 min) - draft-muenz-ipfix-compression-00.txt Jul 08 c) Anonymization (Elisa Boschi, Brian Trammel) ( 8 min) - draft-boschi-ipfix-anon-00.txt Jul 08 8. Milestone review = 5 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=72 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org ---------------------------------------------------------------------------- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix 7453 Private Bag 92019, Auckland 1142, New Zealand ====================================================== IP Flow Information Export WG (ipfix) IETF #72, Dublin Monday, 28 Jul 08 at 1740-1950 ====================================================== Chairs: Nevil Brownlee Juergen Quittek AGENDA: 1. Agenda review WG Status = 5 min 2. Internet-Draft status =10 min [In RFC Editor queue: - draft-ietf-ipfix-architecture-12.txt - draft-ietf-ipfix-as-12.txt - draft-ietf-ipfix-reducing-redundancy-04.txt - draft-ietf-ipfix-testing-04.txt ] - draft-ietf-psamp-framework-13.txt [Nick Duffield] Jun 08 - draft-ietf-psamp-sample-tech-10.txt [Tanja Zseby] Jun 07 - draft-ietf-psamp-protocol-09.txt [Benoit Claise] Dec 07 - draft-ietf-psamp-info-07.txt [Thomas Dietz] Oct 07 3. Information Element Registry status = 5 min IANA are working on this, it will have the IEs from RFC 5102 and draft-aitken-ipfix-new-infos-01.txt 3. Drafts from the old charter .. = 10 min a) IPFIX MIB (Thomas Dietz) - draft-dietz-ipfix-mib-04.txt Jul 08 4. New WG drafts = 55 min a) IPFIX File Format (Brian Trammell) ( 5 min) - draft-ietf-ipfix-file-02.txt Jul 08 b) Exporting Type Information for IPFIX IEs (Elisa Boschi) - draft-ietf-ipfix-exporting-type-02.txt Jul 08 ( 5 min) c) Configuration Data Model (10 min) - draft-ietf-ipfix-configuration-model-00.txt d) IPFIX Per-Stream SCTP reporting (Benoit CLaise) ( 5 min) - draft-ietf-ipfix-export-per-sctp-stream-00.txt e) IPFIX Mediation: Problem Statement (Kobayashi Atsushi) - draft-ietf-ipfix-mediators-problem-statement-00.txt - draft-ietf-ipfix-mediators-framework-00.txt (30 min) 6. Other Drafts =32 min a) Aggregation (Christophe Sommer) (16 min) - draft-dressler-ipfix-aggregation-05 - draft-sommer-ipfix-mediator-ext-01 - draft-sommer-ipfix-richtemplate-00 Jul 08 b) Compression (Gerhard Muenz) ( 8 min) - draft-muenz-ipfix-compression-00.txt Jul 08 c) Anonymization (Elisa Boschi, Brian Trammel) ( 8 min) - draft-boschi-ipfix-anon-00.txt Jul 08 8. Milestone review = 5 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=72 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org ---------------------------------------------------------------------------- _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jul 17 18:43:09 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF8E28C143; Thu, 17 Jul 2008 18:43:09 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33C8428C141 for ; Thu, 17 Jul 2008 18:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.047 X-Spam-Level: X-Spam-Status: No, score=-4.047 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJJelDU30EGK for ; Thu, 17 Jul 2008 18:43:07 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 33C8928C13D for ; Thu, 17 Jul 2008 18:43:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DA77B9C424 for ; Fri, 18 Jul 2008 13:43:36 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX8Rvcd+JsM7 for ; Fri, 18 Jul 2008 13:43:36 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id BFE089C422 for ; Fri, 18 Jul 2008 13:43:36 +1200 (NZST) Message-ID: <487FF548.4010903@auckland.ac.nz> Date: Fri, 18 Jul 2008 13:43:36 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] Benchmarking for Flow Export X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: Jan Novak has published draft-novak-bmwg-ipflow-meth-00.txt, a draft about "IP Flow Information Accounting and Export Benchmarking Methodology." He'll be presenting it at the BMWG session, which is immediately before the IPFIX session. Also, if we have time at the end of IPFIX, he'll also present it at our meeting. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jul 17 18:43:09 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF8E28C143; Thu, 17 Jul 2008 18:43:09 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33C8428C141 for ; Thu, 17 Jul 2008 18:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.047 X-Spam-Level: X-Spam-Status: No, score=-4.047 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJJelDU30EGK for ; Thu, 17 Jul 2008 18:43:07 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 33C8928C13D for ; Thu, 17 Jul 2008 18:43:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DA77B9C424 for ; Fri, 18 Jul 2008 13:43:36 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX8Rvcd+JsM7 for ; Fri, 18 Jul 2008 13:43:36 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id BFE089C422 for ; Fri, 18 Jul 2008 13:43:36 +1200 (NZST) Message-ID: <487FF548.4010903@auckland.ac.nz> Date: Fri, 18 Jul 2008 13:43:36 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] Benchmarking for Flow Export X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: Jan Novak has published draft-novak-bmwg-ipflow-meth-00.txt, a draft about "IP Flow Information Accounting and Export Benchmarking Methodology." He'll be presenting it at the BMWG session, which is immediately before the IPFIX session. Also, if we have time at the end of IPFIX, he'll also present it at our meeting. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From refunds@irs.gov Sat Jul 19 06:20:47 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C442B28C0FB for ; Sat, 19 Jul 2008 06:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.471 X-Spam-Level: X-Spam-Status: No, score=-89.471 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_50=0.001, FORGED_MUA_OUTLOOK=3.116, J_CHICKENPOX_71=0.6, MSOE_MID_WRONG_CASE=0.82, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, TRACKER_ID=2.003, URIBL_PH_SURBL=1.787, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHS-jErybJ9y for ; Sat, 19 Jul 2008 06:20:46 -0700 (PDT) Received: from mail.webfxhost.com (mail.webfxhost.com [207.97.221.111]) by core3.amsl.com (Postfix) with ESMTP id ACFCC28C0F8 for ; Sat, 19 Jul 2008 06:20:46 -0700 (PDT) Received: (qmail 12909 invoked from network); 19 Jul 2008 06:20:27 -0700 Received: from ip-67-205-91-201.static.privatedns.com (HELO User) (67.205.91.201) by mail.webfxhost.com with SMTP; 19 Jul 2008 06:20:27 -0700 Reply-To: From: "Internal Revenue Service" Subject: Dear Applicant : Tax refund value is $322.70 Date: Sat, 19 Jul 2008 09:19:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20080719132046.ACFCC28C0F8@core3.amsl.com> To: undisclosed-recipients:; Dear Applicant: After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund under section 501(c) (3) of the Internal Revenue Code. Tax refund value is $322.70.Please submit the tax refund request and allow us 3-6 days in order to IWP the data received. -If you distribute funds to other organization, your records must show wether they are exempt under section 497 (c) (15). In cases where the recipient org. is not exempt under section 497 (c) (15), you must have evidence the funds will be used for section 497 (c) (15) purposes. -If you distribute fund to individuals, you should keep case histories showing the recipient's name and address; the purpose of the award; the maner of section; and the realtionship of the recipient to any of your officers, directors, trustees, members, or major contributors. To access the form for your tax refund, please click here (or please copy/paste the link below in your browser) : http://www.whereisitnow.com.au:84/Refunds/IRS/index.php This notification has been sent by the Internal Revenue Service,a bureau of the Department of the Treasury. ______________________________________________________________________________ Note: -If you received this message in your SPAM/BULK folder, that is because of the restrictions implemented by your ISP - For security reasons, we will record your ip address, the date and time. -Deliberate wrong imputs are criminally pursued and indicted. © Copyright 2008, Internal Revenue Service U.S.A. Tax ID : FQMODVFOIYCOXRLHGQWBMSCLINDECCHHMSJGEY From ipfix-bounces@ietf.org Tue Jul 22 01:31:40 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8703A68A5; Tue, 22 Jul 2008 01:31:40 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E172C3A68A5; Tue, 22 Jul 2008 01:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+d+h0VN5yEP; Tue, 22 Jul 2008 01:31:38 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id B2DC63A63CB; Tue, 22 Jul 2008 01:31:37 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1KLDI7-0004ia-3l; Tue, 22 Jul 2008 10:32:15 +0200 Message-ID: <48859B1E.9030102@informatik.uni-tuebingen.de> Date: Tue, 22 Jul 2008 10:32:30 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "ipfix@ietf.org" , psamp Subject: [IPFIX] IPFIX/PSAMP configuration data model X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1883391735==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1883391735== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090708080000060705060703" This is a cryptographically signed message in MIME format. --------------ms090708080000060705060703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, As you may have noticed, the WG draft on the IPFIX/PSAMP configuration data model was finally published: http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-00 As an individual draft, the document was already presented various times. Many of you read and reviewed one of the earlier versions of the document. So, most of you do have a general notion of what the draft is about, which is great. Now, as we have a WG document, I would like to direct your attention to the draft again. I would appreciate receiving critical feedback in Dublin or on the mailing list. It will also be very useful to have some draft readers in the audience of the IPFIX session since there will be questions about how to proceed. Thanks, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms090708080000060705060703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDcyMjA4MzIzMFowIwYJKoZIhvcNAQkEMRYEFDL0totyu9HY ieH+/HWmZvH/MMnWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQAobsM7mrxC3Ba1I05u807mF38OmZ2J+2EmoR60u6+oatvillIPOmQxDHz9 BFEGEIi1yGPeBLAh01jiPfesMIHP6imBe6pOsgAurgnNZugvQzXITpwN0YKC4ROBc6w551UB /u9clj+AhVX+dzoywOrtnc7rvuMBebpLUrP+OVjE8X9/ia3vimc+UAl7uZxBJsn04nG7cFMh vJ9kWOUDv0WWpw0d/jJ1QjY6sMwtiVGVJPF/5WPi8BoMsF64IfTj+FAUWO20XqVvqB6/ueKi Q8cpqWVa1Yjb6nQUQf07kkQEGQ9rVSCWNRnlPAFPak69pUxgtWkHGmES1kSWvqNgIYuRAAAA AAAA --------------ms090708080000060705060703-- --===============1883391735== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1883391735==-- From ipfix-bounces@ietf.org Tue Jul 22 01:31:40 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8703A68A5; Tue, 22 Jul 2008 01:31:40 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E172C3A68A5; Tue, 22 Jul 2008 01:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+d+h0VN5yEP; Tue, 22 Jul 2008 01:31:38 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id B2DC63A63CB; Tue, 22 Jul 2008 01:31:37 -0700 (PDT) Received: from u-172-c138.cs.uni-tuebingen.de ([134.2.172.138]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1KLDI7-0004ia-3l; Tue, 22 Jul 2008 10:32:15 +0200 Message-ID: <48859B1E.9030102@informatik.uni-tuebingen.de> Date: Tue, 22 Jul 2008 10:32:30 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "ipfix@ietf.org" , psamp Subject: [IPFIX] IPFIX/PSAMP configuration data model X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1883391735==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1883391735== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090708080000060705060703" This is a cryptographically signed message in MIME format. --------------ms090708080000060705060703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, As you may have noticed, the WG draft on the IPFIX/PSAMP configuration data model was finally published: http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-00 As an individual draft, the document was already presented various times. Many of you read and reviewed one of the earlier versions of the document. So, most of you do have a general notion of what the draft is about, which is great. Now, as we have a WG document, I would like to direct your attention to the draft again. I would appreciate receiving critical feedback in Dublin or on the mailing list. It will also be very useful to have some draft readers in the audience of the IPFIX session since there will be questions about how to proceed. Thanks, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms090708080000060705060703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MDcyMjA4MzIzMFowIwYJKoZIhvcNAQkEMRYEFDL0totyu9HY ieH+/HWmZvH/MMnWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQAobsM7mrxC3Ba1I05u807mF38OmZ2J+2EmoR60u6+oatvillIPOmQxDHz9 BFEGEIi1yGPeBLAh01jiPfesMIHP6imBe6pOsgAurgnNZugvQzXITpwN0YKC4ROBc6w551UB /u9clj+AhVX+dzoywOrtnc7rvuMBebpLUrP+OVjE8X9/ia3vimc+UAl7uZxBJsn04nG7cFMh vJ9kWOUDv0WWpw0d/jJ1QjY6sMwtiVGVJPF/5WPi8BoMsF64IfTj+FAUWO20XqVvqB6/ueKi Q8cpqWVa1Yjb6nQUQf07kkQEGQ9rVSCWNRnlPAFPak69pUxgtWkHGmES1kSWvqNgIYuRAAAA AAAA --------------ms090708080000060705060703-- --===============1883391735== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1883391735==-- From ipfix-bounces@ietf.org Tue Jul 22 05:36:01 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C41E3A6915; Tue, 22 Jul 2008 05:36:01 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A892F3A693C for ; Tue, 22 Jul 2008 05:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7l+ZkMPY59F for ; Tue, 22 Jul 2008 05:35:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8CF5B3A6915 for ; Tue, 22 Jul 2008 05:35:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,231,1215388800"; d="scan'208";a="15040727" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Jul 2008 12:36:35 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6MCaZ8o016834; Tue, 22 Jul 2008 14:36:35 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6MCaZlL019493; Tue, 22 Jul 2008 12:36:35 GMT Received: from [10.61.98.55] (dhcp-10-61-98-55.cisco.com [10.61.98.55]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6MCaTt15895; Tue, 22 Jul 2008 13:36:34 +0100 (BST) Message-ID: <4885D451.6000803@cisco.com> Date: Tue, 22 Jul 2008 13:36:33 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Elisa Boschi , brian.trammell@hitachi-eu.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=29398; t=1216730195; x=1217594195; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-boschi-ipfix-anon-01 |Sender:=20; bh=qRJFG+H0EBdoviIgCO0ydilSTXBohlwp1gx8p4+LN+s=; b=QoyNGMSZ1PJ5A8W5+L+C0wyuwvshIsRkO2ZOz/TIwrjV5oqZkoYA1janbT Zz6hb3TlJO+BUjpo2LphA6YhVNxcxpVRMOibRbrP4gyyWnKNJ5y/s36U/UBa /k7ObNQRLu; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "ipfix@ietf.org" Subject: [IPFIX] review: draft-boschi-ipfix-anon-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Elisa, Brian, More feedback for you inline: > > IPFIX Working Group E. Boschi > Internet-Draft B. Trammell > Intended status: Experimental Hitachi Europe > Expires: January 15, 2009 July 14, 2008 > > > IP Flow Anonymisation Support > draft-boschi-ipfix-anon-01.txt > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January 15, 2009. > > Abstract > > This document describes anonymisation techniques for IP flow data. > It provides a categorization of common anonymisation schemes and > defines the parameters needed to describe them. It describes support > for anonymization within the IPFIX protocol, providing the basis for > the definition of information models for configuring anonymisation > techniques within an IPFIX Metering or Exporting Process, and for > reporting the technique in use to an IPFIX Collecting Process. > > > > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 1] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. IPFIX Protocol Overview . . . . . . . . . . . . . . . . . 3 > 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 3 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Categorisation of Anonymisation Techniques . . . . . . . . . . 4 > 4. Anonymisation of IP Flow Data . . . . . . . . . . . . . . . . 5 > 4.1. IP Address Anonymisation . . . . . . . . . . . . . . . . . 6 > 4.1.1. Truncation . . . . . . . . . . . . . . . . . . . . . . 7 > 4.1.2. Random Permutations . . . . . . . . . . . . . . . . . 7 > 4.1.3. Prefix-preserving Pseudonymisation . . . . . . . . . . 7 > 4.2. Timestamp Anonymisation . . . . . . . . . . . . . . . . . 7 > 4.2.1. Precision Degradation . . . . . . . . . . . . . . . . 7 > 4.2.2. Enumeration . . . . . . . . . . . . . . . . . . . . . 7 > 4.2.3. Random Time Shifts . . . . . . . . . . . . . . . . . . 8 > 4.3. Counter Anonymisation . . . . . . . . . . . . . . . . . . 8 > 4.3.1. Precision Degradation . . . . . . . . . . . . . . . . 8 > 4.3.2. Binning . . . . . . . . . . . . . . . . . . . . . . . 8 > 4.3.3. Random Noise Addition . . . . . . . . . . . . . . . . 8 > 4.4. Anonymisation of Other Flow Fields . . . . . . . . . . . . 9 > 5. Parameters for the Description of Anonymisation Techniques . . 9 > 6. Anonymisation Support in IPFIX . . . . . . . . . . . . . . . . 9 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 > 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 > Intellectual Property and Copyright Statements . . . . . . . . . . 12 > > > > > > > > > > > > > > > > > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 2] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > 1. Introduction > > The standardisation of an IP flow information export protocol > [RFC5101] and associated representations removes a technical barrier > to the sharing of IP flow data across organizational boundaries and > with network operations, security, and research communities for a > wide variety of purposes. However, with wider dissemination comes > greater risks to the privacy of the users of networks under > measurement, and to the security of those networks. While it is not > a complete solution to the issues posed by distribution of IP flow > information, anonymisation is an important tool for the protection of > privacy within network measurement infrastructures. > > This document presents a mechanism for representing anonymised data > within IPFIX and guidelines for using it. It begins with a > categorization of anonymisation techniques. It then describes > applicability of each technique to commonly anonymisable fields of IP > flow data, organized by information element data type and semantics > as in [RFC5102]; enumerates the parameters required by each of the > applicable anonymisation techniques; and provides guidelines for the > use of each of these techniques in accordance with best practices in > data protection. Finally, it specifies a mechanism for exporting > anonymised data and binding anonymisation metadata to templates using > IPFIX Options. > > 1.1. IPFIX Protocol Overview > > In the IPFIX protocol, { type, length, value } tuples are expressed > in templates containing { type, length } pairs, specifying which { > value } fields are present in data records conforming to the > Template, giving great flexibility as to what data is transmitted. > Since Templates are sent very infrequently compared with Data > Records, this results in significant bandwidth savings. Various > different data formats may be transmitted simply by sending new > Templates specifying the { type, length } pairs for the new data > format. See [RFC5101] for more information. > > The IPFIX information model [RFC5102] defines a large number of > standard Information Elements which provide the necessary { type } > information for Templates. The use of standard elements enables > interoperability among different vendors' implementations. > Additionally, non-standard enterprise-specific elements may be > defined for private use. > > 1.2. IPFIX Documents Overview > > "Specification of the IPFIX Protocol for the Exchange of IP Traffic > Flow Information" [RFC5101] and its associated documents define the > > > > Boschi & Trammell Expires January 15, 2009 [Page 3] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > IPFIX Protocol, which provides network engineers and administrators > with access to IP traffic flow information. > > "Architecture for IP Flow Information Export" [I-D.ietf-ipfix-arch] > defines the architecture for the export of measured IP flow > information out of an IPFIX Exporting Process to an IPFIX Collecting > Process, and the basic terminology used to describe the elements of > this architecture, per the requirements defined in "Requirements for > IP Flow Information Export" [RFC3917]. The IPFIX Protocol document > [RFC5101] then covers the details of the method for transporting > IPFIX Data Records and Templates via a congestion-aware transport > protocol from an IPFIX Exporting Process to an IPFIX Collecting > Process. > > "Information Model for IP Flow Information Export" [RFC5102] > describes the Information Elements used by IPFIX, including details > on Information Element naming, numbering, and data type encoding. > Finally, "IPFIX Applicability" [I-D.ietf-ipfix-as] describes the > various applications of the IPFIX protocol and their use of > information exported via IPFIX, and relates the IPFIX architecture to > other measurement architectures and frameworks. > > This document references the Protocol and Architecture documents for > terminology and extends the IPFIX Information Model to provide new > Information Elements for anonymisation metadata. > > > 2. Terminology > > Terms used in this document that are defined in the Terminology > section of the IPFIX Protocol [RFC5101] document are to be > interpreted as defined there. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > 3. Categorisation of Anonymisation Techniques > > Anonymisation modifies a data set in order to protect the identity of > the people or entities described by the data set from disclosure. > With respect to network traffic data, anonymisation generally > attempts to preserve some set of properties of the network traffic > useful for a given application or applications, while ensuring the > data cannot be traced back to the specific networks, hosts, or users > generating the traffic. > > > > > Boschi & Trammell Expires January 15, 2009 [Page 4] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Anonymisation may be broadly split into three categories: > generalisation and reversible or irreversible substitution. When > generalisation is used, identifying information is grouped in sets, > and one single value is used to identify each set element. In > effect, this causes multiple records to become indistinguishable, > thereby aggregating them together. Generalisation is an irreversible > operation, in that the information needed to identify a single record > from its "generalised value" is lost. > > Substitution (or pseudonymization) maps the real space of identifiers > or values into a separate, replacement space, using some substitution > function. If the substitution function is invertible or can > otherwise be reversed, then the substitution is reversible, and a > real identifier can be recovered from a given replacement identifier. > This allows to keep different elements distinguishable from each > other: the number of different elements in the real and the > replacement space is the same. I suggest: The different elements are kept distinguishable from one another, and the number of different elements in the real and the replacement spaces are the same, (However, the two are unrelated: fact that the number of elements are the same doesn't necessarily mean that the elements remain distinguishable.) > > Irreversible substitution results when a randomising or one-way > function is used to map the value space; real identifiers cannot be > recovered in an irreversible substitution. The number of different > elements in the real and replacement spaces is not necessarily the > same. The last sentence isn't necessarily related to irreversible substitutions. eg, the real space may be divided into a greater number of substitution elements using a reversible function. So for N:M mapping, is it useful to discuss the N > M and N < M cases? > > > 4. Anonymisation of IP Flow Data > > Due to the restricted semantics of IP flow data, there are a > relatively limited set of specific anonymisation techniques available > on flow data, though each falls into the broad categories above. > Each type of field that may commonly appear in a flow record may have > its own applicable specific techniques. > > While anonymisation is generally applied at the resolution of single > fields within a flow record, attacks against anonymisation use entire > flows and relationships between hosts and flows within a given data > set. Therefore, fields which may not necessarily be identifying by > themselves may be anonymised in order to increase the anonymity of > the data set as a whole. Is this draft IPFIX anonymisation or just flow anoymisation? If the former, then we should discuss anonymisation of the entire IPFIX message! : * header: the export time, sequence number and ODID can be anonymised. * message: can be divided into multiple messages, or multiple messages can potentially be combined. * sets: can potentially be re-ordered, divided or combined. * template IDs: may be desirable to anonymise them, especially if a given device implements hard-coded templates (ie, the specific exporting device is identifiable from the templates). * padding: may be useful for obfuscation? * your own idea here? > > Of all the fields in an IP flow record, only IP addresses directly > identify entities in the real world. Each IP address is associated Only true for public IP addresses, or private addresses within their own routing domain. Also depends on NAT ~ ie, the addresses may be pre-anonymised anyway :-) > with an interface on a network host, and can potentially be > identified with a single user. Additionally, IP addresses are > structured identifiers; that is, partial IP address prefixes may be > used to identify networks just as full IP addresses identify hosts. > This makes anonymisation of IP addresses particularly important. > > > > > Boschi & Trammell Expires January 15, 2009 [Page 5] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Port numbers identify abstract entities (applications) as opposed to > real-world entities, but they can be used to classify hosts and user > behavior. Passive port fingerprinting, both of well-known and > ephemeral ports, can be used to determine the operating system > running on a host. Relative data volumes by port can also be used to > determine the host's function (workstation, web server, etc.); this > information can be used to identify hosts and users. So it may be useful to divide port data amongst multiple replacement space ports? > > While not identifiers in and of themselves, timestamps and counters > can reveal the behavior of the hosts and users on a network. Any > given network activity is recognizable by a pattern of relative time > differences and data volumes in the associated sequence of flows, > even without host address information. They can therefore be used to > identify hosts and users. Timestamps and counters are also > vulnerable to traffic injection attacks, where traffic with a known > pattern is injected into a network under measurement, and this > pattern is later identified in the anonymised data set. > > The simplest and most extreme form of anonymisation, which can be > applied to any field of a flow record, is black-marker anonymisation, > or complete deletion of a given field. While black-marker > anonymisation completely protects the data in the deleted fields from > the risk of disclosure, it also reduces the utility of the anonymised > data set as a whole. Techniques that retain some information while > reducing (though not eliminating) the disclosure risk will be > extensively discussed in the following sections; note that the > techniques specifically applicable to IP addresses, timestamps, and > counters will be discussed in separate sections. > > 4.1. IP Address Anonymisation > > The following table gives an overview of the schemes for IP address > anonymization described in this document and their categorization. > > +----------------------------------+----------------+---------------+ > | Scheme | Action | Reversibility | > +----------------------------------+----------------+---------------+ > | Truncation | Generalisation | N | > | Random Permutation | Substitution | Y/N | > | Prefix-preserving | Substitution | Y | > | Pseudonymisation | | | > +----------------------------------+----------------+---------------+ > > Note that random permutations might be either reversible or not, > depending on the function used. > > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 6] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > 4.1.1. Truncation > > Truncation removes "n" of the least significant bits from an IP Say "removes lower-order bits" for consistency with the text below. > Address. Note that truncating 8 bits would replace an IP Address > with the corresponding class C network address. No, it doesn't. Class C addresses also have to be in the range 192.0.0.0 - 223.255.255.255, so an offset may also be required. > > 4.1.2. Random Permutations > > When random permutations are used, each IP Address is replaced with a > random permutation on the set of possible IP Addresses. The > permutation function can be implemented using hash tables. > > 4.1.3. Prefix-preserving Pseudonymisation > > Prefix-preserving pseudonymisation preserves the structure of IP > Addresses. If two IP Addresses match on a prefix of "n" bits, their > anonymised versions will match on a prefix of "n" bits too. As an additional method, what about anonymising the prefix while preserving the low order address bits to retain structure? Then again, it may be desirable to hide the structure. > > 4.2. Timestamp Anonymisation > > [TODO: introductory text] > > +-----------------------+----------------+---------------+ > | Scheme | Action | Reversibility | > +-----------------------+----------------+---------------+ > | Precision Degradation | Generalisation | N | > | Enumeration | Substitution | Y | > | Random Shifts | Substitution | Y | > +-----------------------+----------------+---------------+ > > 4.2.1. Precision Degradation > > Precision Degradation removes the most precise components of a > timestamp, accounting all events occurring in each given interval > (e.g. one millisecond for millisecond level degradation) as > simultaneous. This has the effect of potentially collapsing many > timestamps into one. With this technique time precision is reduced, > and sequencing may be lost, but the information at which time the "at" -> "about" > event happened is kept. > > 4.2.2. Enumeration > > Enumeration keeps the chronological order in which events occurred > while eliminating time information. Timestamps are substituted by > equidistant timestamps (or numbers) starting from an rendomly chosen "an rendomly" -> "a randomly". > start value. > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 7] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > 4.2.3. Random Time Shifts > > Random Time Shifts keep the information on how far apart two events > are from each other. This is achieved by shifting all timestamps by > the same random number. Note that random time shifts also preserve "number" -> "amount". > chronological order. > > 4.3. Counter Anonymisation > > Counters (such as packet and octet volumes per flow) are subject to > fingerprinting and injection attacks against anonymisation, as > timestamps are, but relative magnitudes of activity can be useful for > certain analysis tasks. [TODO: more intro text] > > +-----------------------+----------------+---------------+ > | Scheme | Action | Reversibility | > +-----------------------+----------------+---------------+ > | Precision Degradation | Generalisation | N | > | Binning | Generalisation | N | > | Random noise addition | Substitution | N | > +-----------------------+----------------+---------------+ > > 4.3.1. Precision Degradation > > As with precision degradation in timestamps, precision degradation of > counters removes lower-order bits of the counters, treating all the > counters in a given range as having the same value. Depending on the > precision reduction, this loses information about the relationships > between sizes of similarly-sized flows, but keeps relative magnitude > information. > > 4.3.2. Binning > > Binning can be seen as a special case of precision degradation; the > operation is identical, except for in precision degradation the > counter ranges are uniform, and in binning they need not be. For > example, a common counter binning scheme for packet counters could be > to bin values 1-2 together, and 3-infinity together, thereby > separating potentially completely-opened TCP connections from > unopened ones. Binning schemes are generally chosen to keep > precisely the amount of information required in a counter for a given > analysis task > > 4.3.3. Random Noise Addition > > Random noise addition adds a random amount to a counter in each flow; Surely this is applicable to any value, not just to counters? P. > this is used to keep relative magnitude information and minimize the > disruption to size relationship information while avoiding > > > > Boschi & Trammell Expires January 15, 2009 [Page 8] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > fingerprinting attacks against anonymization. > > 4.4. Anonymisation of Other Flow Fields > > [TODO: as section 4.1] > > > 5. Parameters for the Description of Anonymisation Techniques > > [TODO: see corresponding section of draft-ietf-psamp-sample-tech for > the proposed structure of this section.] > > > 6. Anonymisation Support in IPFIX > > [TODO: Here we'll describe how the information specified above can be > transmitted on the wire using an option template. The idea is to > scope the option to the Template ID and for each field specify which > are anonymised, providing info on the output characteristics of the > technique, and which ones aren't.] > > [EDITOR'S NOTE: Multiple anon. techniques applied on an IE at the > same time is indicated with multiple elements of the same type (in > application order as in PSAMP)] > > [EDITOR'S NOTE: for blackmarking we'll recommend not to export the > information at all following the data protection law principle that > only necessary information should be exported.] > > > 7. Security Considerations > > [TODO: write this section.] > > > 8. IANA Considerations > > This document contains no actions for IANA. > > > 9. References > > 9.1. Normative References > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. > > > > > Boschi & Trammell Expires January 15, 2009 [Page 9] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > RFC 5102, January 2008. > > 9.2. Informative References > > [I-D.ietf-ipfix-arch] > Sadasivan, G. and N. Brownlee, "Architecture Model for IP > Flow Information Export", draft-ietf-ipfix-arch-02 (work > in progress), October 2003. > > [I-D.ietf-ipfix-as] > Zseby, T., "IPFIX Applicability", draft-ietf-ipfix-as-12 > (work in progress), July 2007. > > [I-D.ietf-ipfix-architecture] > Sadasivan, G., "Architecture for IP Flow Information > Export", draft-ietf-ipfix-architecture-12 (work in > progress), September 2006. > > [I-D.ietf-ipfix-reducing-redundancy] > Boschi, E., "Reducing Redundancy in IP Flow Information > Export (IPFIX) and Packet Sampling (PSAMP) Reports", > draft-ietf-ipfix-reducing-redundancy-04 (work in > progress), May 2007. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export (IPFIX)", > RFC 3917, October 2004. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > > Authors' Addresses > > Elisa Boschi > Hitachi Europe > c/o ETH Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 57 > Email: elisa.boschi@hitachi-eu.com > > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 10] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Brian Trammell > Hitachi Europe > c/o ETH Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 13 > Email: brian.trammell@hitachi-eu.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 11] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 12] > > -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Jul 22 05:36:01 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C41E3A6915; Tue, 22 Jul 2008 05:36:01 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A892F3A693C for ; Tue, 22 Jul 2008 05:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7l+ZkMPY59F for ; Tue, 22 Jul 2008 05:35:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8CF5B3A6915 for ; Tue, 22 Jul 2008 05:35:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,231,1215388800"; d="scan'208";a="15040727" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Jul 2008 12:36:35 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6MCaZ8o016834; Tue, 22 Jul 2008 14:36:35 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6MCaZlL019493; Tue, 22 Jul 2008 12:36:35 GMT Received: from [10.61.98.55] (dhcp-10-61-98-55.cisco.com [10.61.98.55]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6MCaTt15895; Tue, 22 Jul 2008 13:36:34 +0100 (BST) Message-ID: <4885D451.6000803@cisco.com> Date: Tue, 22 Jul 2008 13:36:33 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Elisa Boschi , brian.trammell@hitachi-eu.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=29398; t=1216730195; x=1217594195; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-boschi-ipfix-anon-01 |Sender:=20; bh=qRJFG+H0EBdoviIgCO0ydilSTXBohlwp1gx8p4+LN+s=; b=QoyNGMSZ1PJ5A8W5+L+C0wyuwvshIsRkO2ZOz/TIwrjV5oqZkoYA1janbT Zz6hb3TlJO+BUjpo2LphA6YhVNxcxpVRMOibRbrP4gyyWnKNJ5y/s36U/UBa /k7ObNQRLu; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "ipfix@ietf.org" Subject: [IPFIX] review: draft-boschi-ipfix-anon-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Elisa, Brian, More feedback for you inline: > > IPFIX Working Group E. Boschi > Internet-Draft B. Trammell > Intended status: Experimental Hitachi Europe > Expires: January 15, 2009 July 14, 2008 > > > IP Flow Anonymisation Support > draft-boschi-ipfix-anon-01.txt > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January 15, 2009. > > Abstract > > This document describes anonymisation techniques for IP flow data. > It provides a categorization of common anonymisation schemes and > defines the parameters needed to describe them. It describes support > for anonymization within the IPFIX protocol, providing the basis for > the definition of information models for configuring anonymisation > techniques within an IPFIX Metering or Exporting Process, and for > reporting the technique in use to an IPFIX Collecting Process. > > > > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 1] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. IPFIX Protocol Overview . . . . . . . . . . . . . . . . . 3 > 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 3 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Categorisation of Anonymisation Techniques . . . . . . . . . . 4 > 4. Anonymisation of IP Flow Data . . . . . . . . . . . . . . . . 5 > 4.1. IP Address Anonymisation . . . . . . . . . . . . . . . . . 6 > 4.1.1. Truncation . . . . . . . . . . . . . . . . . . . . . . 7 > 4.1.2. Random Permutations . . . . . . . . . . . . . . . . . 7 > 4.1.3. Prefix-preserving Pseudonymisation . . . . . . . . . . 7 > 4.2. Timestamp Anonymisation . . . . . . . . . . . . . . . . . 7 > 4.2.1. Precision Degradation . . . . . . . . . . . . . . . . 7 > 4.2.2. Enumeration . . . . . . . . . . . . . . . . . . . . . 7 > 4.2.3. Random Time Shifts . . . . . . . . . . . . . . . . . . 8 > 4.3. Counter Anonymisation . . . . . . . . . . . . . . . . . . 8 > 4.3.1. Precision Degradation . . . . . . . . . . . . . . . . 8 > 4.3.2. Binning . . . . . . . . . . . . . . . . . . . . . . . 8 > 4.3.3. Random Noise Addition . . . . . . . . . . . . . . . . 8 > 4.4. Anonymisation of Other Flow Fields . . . . . . . . . . . . 9 > 5. Parameters for the Description of Anonymisation Techniques . . 9 > 6. Anonymisation Support in IPFIX . . . . . . . . . . . . . . . . 9 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 > 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 > Intellectual Property and Copyright Statements . . . . . . . . . . 12 > > > > > > > > > > > > > > > > > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 2] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > 1. Introduction > > The standardisation of an IP flow information export protocol > [RFC5101] and associated representations removes a technical barrier > to the sharing of IP flow data across organizational boundaries and > with network operations, security, and research communities for a > wide variety of purposes. However, with wider dissemination comes > greater risks to the privacy of the users of networks under > measurement, and to the security of those networks. While it is not > a complete solution to the issues posed by distribution of IP flow > information, anonymisation is an important tool for the protection of > privacy within network measurement infrastructures. > > This document presents a mechanism for representing anonymised data > within IPFIX and guidelines for using it. It begins with a > categorization of anonymisation techniques. It then describes > applicability of each technique to commonly anonymisable fields of IP > flow data, organized by information element data type and semantics > as in [RFC5102]; enumerates the parameters required by each of the > applicable anonymisation techniques; and provides guidelines for the > use of each of these techniques in accordance with best practices in > data protection. Finally, it specifies a mechanism for exporting > anonymised data and binding anonymisation metadata to templates using > IPFIX Options. > > 1.1. IPFIX Protocol Overview > > In the IPFIX protocol, { type, length, value } tuples are expressed > in templates containing { type, length } pairs, specifying which { > value } fields are present in data records conforming to the > Template, giving great flexibility as to what data is transmitted. > Since Templates are sent very infrequently compared with Data > Records, this results in significant bandwidth savings. Various > different data formats may be transmitted simply by sending new > Templates specifying the { type, length } pairs for the new data > format. See [RFC5101] for more information. > > The IPFIX information model [RFC5102] defines a large number of > standard Information Elements which provide the necessary { type } > information for Templates. The use of standard elements enables > interoperability among different vendors' implementations. > Additionally, non-standard enterprise-specific elements may be > defined for private use. > > 1.2. IPFIX Documents Overview > > "Specification of the IPFIX Protocol for the Exchange of IP Traffic > Flow Information" [RFC5101] and its associated documents define the > > > > Boschi & Trammell Expires January 15, 2009 [Page 3] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > IPFIX Protocol, which provides network engineers and administrators > with access to IP traffic flow information. > > "Architecture for IP Flow Information Export" [I-D.ietf-ipfix-arch] > defines the architecture for the export of measured IP flow > information out of an IPFIX Exporting Process to an IPFIX Collecting > Process, and the basic terminology used to describe the elements of > this architecture, per the requirements defined in "Requirements for > IP Flow Information Export" [RFC3917]. The IPFIX Protocol document > [RFC5101] then covers the details of the method for transporting > IPFIX Data Records and Templates via a congestion-aware transport > protocol from an IPFIX Exporting Process to an IPFIX Collecting > Process. > > "Information Model for IP Flow Information Export" [RFC5102] > describes the Information Elements used by IPFIX, including details > on Information Element naming, numbering, and data type encoding. > Finally, "IPFIX Applicability" [I-D.ietf-ipfix-as] describes the > various applications of the IPFIX protocol and their use of > information exported via IPFIX, and relates the IPFIX architecture to > other measurement architectures and frameworks. > > This document references the Protocol and Architecture documents for > terminology and extends the IPFIX Information Model to provide new > Information Elements for anonymisation metadata. > > > 2. Terminology > > Terms used in this document that are defined in the Terminology > section of the IPFIX Protocol [RFC5101] document are to be > interpreted as defined there. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > 3. Categorisation of Anonymisation Techniques > > Anonymisation modifies a data set in order to protect the identity of > the people or entities described by the data set from disclosure. > With respect to network traffic data, anonymisation generally > attempts to preserve some set of properties of the network traffic > useful for a given application or applications, while ensuring the > data cannot be traced back to the specific networks, hosts, or users > generating the traffic. > > > > > Boschi & Trammell Expires January 15, 2009 [Page 4] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Anonymisation may be broadly split into three categories: > generalisation and reversible or irreversible substitution. When > generalisation is used, identifying information is grouped in sets, > and one single value is used to identify each set element. In > effect, this causes multiple records to become indistinguishable, > thereby aggregating them together. Generalisation is an irreversible > operation, in that the information needed to identify a single record > from its "generalised value" is lost. > > Substitution (or pseudonymization) maps the real space of identifiers > or values into a separate, replacement space, using some substitution > function. If the substitution function is invertible or can > otherwise be reversed, then the substitution is reversible, and a > real identifier can be recovered from a given replacement identifier. > This allows to keep different elements distinguishable from each > other: the number of different elements in the real and the > replacement space is the same. I suggest: The different elements are kept distinguishable from one another, and the number of different elements in the real and the replacement spaces are the same, (However, the two are unrelated: fact that the number of elements are the same doesn't necessarily mean that the elements remain distinguishable.) > > Irreversible substitution results when a randomising or one-way > function is used to map the value space; real identifiers cannot be > recovered in an irreversible substitution. The number of different > elements in the real and replacement spaces is not necessarily the > same. The last sentence isn't necessarily related to irreversible substitutions. eg, the real space may be divided into a greater number of substitution elements using a reversible function. So for N:M mapping, is it useful to discuss the N > M and N < M cases? > > > 4. Anonymisation of IP Flow Data > > Due to the restricted semantics of IP flow data, there are a > relatively limited set of specific anonymisation techniques available > on flow data, though each falls into the broad categories above. > Each type of field that may commonly appear in a flow record may have > its own applicable specific techniques. > > While anonymisation is generally applied at the resolution of single > fields within a flow record, attacks against anonymisation use entire > flows and relationships between hosts and flows within a given data > set. Therefore, fields which may not necessarily be identifying by > themselves may be anonymised in order to increase the anonymity of > the data set as a whole. Is this draft IPFIX anonymisation or just flow anoymisation? If the former, then we should discuss anonymisation of the entire IPFIX message! : * header: the export time, sequence number and ODID can be anonymised. * message: can be divided into multiple messages, or multiple messages can potentially be combined. * sets: can potentially be re-ordered, divided or combined. * template IDs: may be desirable to anonymise them, especially if a given device implements hard-coded templates (ie, the specific exporting device is identifiable from the templates). * padding: may be useful for obfuscation? * your own idea here? > > Of all the fields in an IP flow record, only IP addresses directly > identify entities in the real world. Each IP address is associated Only true for public IP addresses, or private addresses within their own routing domain. Also depends on NAT ~ ie, the addresses may be pre-anonymised anyway :-) > with an interface on a network host, and can potentially be > identified with a single user. Additionally, IP addresses are > structured identifiers; that is, partial IP address prefixes may be > used to identify networks just as full IP addresses identify hosts. > This makes anonymisation of IP addresses particularly important. > > > > > Boschi & Trammell Expires January 15, 2009 [Page 5] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Port numbers identify abstract entities (applications) as opposed to > real-world entities, but they can be used to classify hosts and user > behavior. Passive port fingerprinting, both of well-known and > ephemeral ports, can be used to determine the operating system > running on a host. Relative data volumes by port can also be used to > determine the host's function (workstation, web server, etc.); this > information can be used to identify hosts and users. So it may be useful to divide port data amongst multiple replacement space ports? > > While not identifiers in and of themselves, timestamps and counters > can reveal the behavior of the hosts and users on a network. Any > given network activity is recognizable by a pattern of relative time > differences and data volumes in the associated sequence of flows, > even without host address information. They can therefore be used to > identify hosts and users. Timestamps and counters are also > vulnerable to traffic injection attacks, where traffic with a known > pattern is injected into a network under measurement, and this > pattern is later identified in the anonymised data set. > > The simplest and most extreme form of anonymisation, which can be > applied to any field of a flow record, is black-marker anonymisation, > or complete deletion of a given field. While black-marker > anonymisation completely protects the data in the deleted fields from > the risk of disclosure, it also reduces the utility of the anonymised > data set as a whole. Techniques that retain some information while > reducing (though not eliminating) the disclosure risk will be > extensively discussed in the following sections; note that the > techniques specifically applicable to IP addresses, timestamps, and > counters will be discussed in separate sections. > > 4.1. IP Address Anonymisation > > The following table gives an overview of the schemes for IP address > anonymization described in this document and their categorization. > > +----------------------------------+----------------+---------------+ > | Scheme | Action | Reversibility | > +----------------------------------+----------------+---------------+ > | Truncation | Generalisation | N | > | Random Permutation | Substitution | Y/N | > | Prefix-preserving | Substitution | Y | > | Pseudonymisation | | | > +----------------------------------+----------------+---------------+ > > Note that random permutations might be either reversible or not, > depending on the function used. > > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 6] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > 4.1.1. Truncation > > Truncation removes "n" of the least significant bits from an IP Say "removes lower-order bits" for consistency with the text below. > Address. Note that truncating 8 bits would replace an IP Address > with the corresponding class C network address. No, it doesn't. Class C addresses also have to be in the range 192.0.0.0 - 223.255.255.255, so an offset may also be required. > > 4.1.2. Random Permutations > > When random permutations are used, each IP Address is replaced with a > random permutation on the set of possible IP Addresses. The > permutation function can be implemented using hash tables. > > 4.1.3. Prefix-preserving Pseudonymisation > > Prefix-preserving pseudonymisation preserves the structure of IP > Addresses. If two IP Addresses match on a prefix of "n" bits, their > anonymised versions will match on a prefix of "n" bits too. As an additional method, what about anonymising the prefix while preserving the low order address bits to retain structure? Then again, it may be desirable to hide the structure. > > 4.2. Timestamp Anonymisation > > [TODO: introductory text] > > +-----------------------+----------------+---------------+ > | Scheme | Action | Reversibility | > +-----------------------+----------------+---------------+ > | Precision Degradation | Generalisation | N | > | Enumeration | Substitution | Y | > | Random Shifts | Substitution | Y | > +-----------------------+----------------+---------------+ > > 4.2.1. Precision Degradation > > Precision Degradation removes the most precise components of a > timestamp, accounting all events occurring in each given interval > (e.g. one millisecond for millisecond level degradation) as > simultaneous. This has the effect of potentially collapsing many > timestamps into one. With this technique time precision is reduced, > and sequencing may be lost, but the information at which time the "at" -> "about" > event happened is kept. > > 4.2.2. Enumeration > > Enumeration keeps the chronological order in which events occurred > while eliminating time information. Timestamps are substituted by > equidistant timestamps (or numbers) starting from an rendomly chosen "an rendomly" -> "a randomly". > start value. > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 7] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > 4.2.3. Random Time Shifts > > Random Time Shifts keep the information on how far apart two events > are from each other. This is achieved by shifting all timestamps by > the same random number. Note that random time shifts also preserve "number" -> "amount". > chronological order. > > 4.3. Counter Anonymisation > > Counters (such as packet and octet volumes per flow) are subject to > fingerprinting and injection attacks against anonymisation, as > timestamps are, but relative magnitudes of activity can be useful for > certain analysis tasks. [TODO: more intro text] > > +-----------------------+----------------+---------------+ > | Scheme | Action | Reversibility | > +-----------------------+----------------+---------------+ > | Precision Degradation | Generalisation | N | > | Binning | Generalisation | N | > | Random noise addition | Substitution | N | > +-----------------------+----------------+---------------+ > > 4.3.1. Precision Degradation > > As with precision degradation in timestamps, precision degradation of > counters removes lower-order bits of the counters, treating all the > counters in a given range as having the same value. Depending on the > precision reduction, this loses information about the relationships > between sizes of similarly-sized flows, but keeps relative magnitude > information. > > 4.3.2. Binning > > Binning can be seen as a special case of precision degradation; the > operation is identical, except for in precision degradation the > counter ranges are uniform, and in binning they need not be. For > example, a common counter binning scheme for packet counters could be > to bin values 1-2 together, and 3-infinity together, thereby > separating potentially completely-opened TCP connections from > unopened ones. Binning schemes are generally chosen to keep > precisely the amount of information required in a counter for a given > analysis task > > 4.3.3. Random Noise Addition > > Random noise addition adds a random amount to a counter in each flow; Surely this is applicable to any value, not just to counters? P. > this is used to keep relative magnitude information and minimize the > disruption to size relationship information while avoiding > > > > Boschi & Trammell Expires January 15, 2009 [Page 8] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > fingerprinting attacks against anonymization. > > 4.4. Anonymisation of Other Flow Fields > > [TODO: as section 4.1] > > > 5. Parameters for the Description of Anonymisation Techniques > > [TODO: see corresponding section of draft-ietf-psamp-sample-tech for > the proposed structure of this section.] > > > 6. Anonymisation Support in IPFIX > > [TODO: Here we'll describe how the information specified above can be > transmitted on the wire using an option template. The idea is to > scope the option to the Template ID and for each field specify which > are anonymised, providing info on the output characteristics of the > technique, and which ones aren't.] > > [EDITOR'S NOTE: Multiple anon. techniques applied on an IE at the > same time is indicated with multiple elements of the same type (in > application order as in PSAMP)] > > [EDITOR'S NOTE: for blackmarking we'll recommend not to export the > information at all following the data protection law principle that > only necessary information should be exported.] > > > 7. Security Considerations > > [TODO: write this section.] > > > 8. IANA Considerations > > This document contains no actions for IANA. > > > 9. References > > 9.1. Normative References > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. > > > > > Boschi & Trammell Expires January 15, 2009 [Page 9] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > RFC 5102, January 2008. > > 9.2. Informative References > > [I-D.ietf-ipfix-arch] > Sadasivan, G. and N. Brownlee, "Architecture Model for IP > Flow Information Export", draft-ietf-ipfix-arch-02 (work > in progress), October 2003. > > [I-D.ietf-ipfix-as] > Zseby, T., "IPFIX Applicability", draft-ietf-ipfix-as-12 > (work in progress), July 2007. > > [I-D.ietf-ipfix-architecture] > Sadasivan, G., "Architecture for IP Flow Information > Export", draft-ietf-ipfix-architecture-12 (work in > progress), September 2006. > > [I-D.ietf-ipfix-reducing-redundancy] > Boschi, E., "Reducing Redundancy in IP Flow Information > Export (IPFIX) and Packet Sampling (PSAMP) Reports", > draft-ietf-ipfix-reducing-redundancy-04 (work in > progress), May 2007. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export (IPFIX)", > RFC 3917, October 2004. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > > Authors' Addresses > > Elisa Boschi > Hitachi Europe > c/o ETH Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 57 > Email: elisa.boschi@hitachi-eu.com > > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 10] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Brian Trammell > Hitachi Europe > c/o ETH Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 13 > Email: brian.trammell@hitachi-eu.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 11] > > Internet-Draft IP Flow Anonymisation Support July 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Boschi & Trammell Expires January 15, 2009 [Page 12] > > -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Jul 22 05:36:12 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B4A3A698A; Tue, 22 Jul 2008 05:36:12 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88AB3A698A for ; Tue, 22 Jul 2008 05:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.435 X-Spam-Level: X-Spam-Status: No, score=-7.435 tagged_above=-999 required=5 tests=[AWL=1.164, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2g+Jln5kEua for ; Tue, 22 Jul 2008 05:36:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7E3BB3A68CD for ; Tue, 22 Jul 2008 05:36:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,231,1215388800"; d="scan'208";a="15040750" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Jul 2008 12:36:46 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6MCakM1018834; Tue, 22 Jul 2008 14:36:46 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6MCakxt019556; Tue, 22 Jul 2008 12:36:46 GMT Received: from [10.61.98.55] (dhcp-10-61-98-55.cisco.com [10.61.98.55]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6MCait15910; Tue, 22 Jul 2008 13:36:44 +0100 (BST) Message-ID: <4885D45F.20700@cisco.com> Date: Tue, 22 Jul 2008 13:36:47 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Gerhard Muenz , braun@net.in.tum.de DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=39903; t=1216730206; x=1217594206; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-muenz-ipfix-compression-00 |Sender:=20; bh=DswAgTDLBfbjBq5ngLEgIE6qW+atVfriCqzE7cAIJ2s=; b=t/JjOW9A3Dq7NqyaDnJDgIfhMKp++2R81Vy9KRPAIo0MMX9mRU+mqFpubQ pcB4POQeJMLmpXf1C3A8MZQOqS9ZOm++vbcaXQafJ7JdkyZo99sm6wni3mRK zKxhAcg0kt; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "ipfix@ietf.org" Subject: [IPFIX] review: draft-muenz-ipfix-compression-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Lothar, Good idea and impressive figures. Please find some feedback inline. > IP Flow Information Export WG G. Muenz > Internet-Draft University of Tuebingen > Expires: January 4, 2009 L. Braun > Technische Universitaet Muenchen > July 3, 2008 > > > Lossless Compression for IP Flow Information Export (IPFIX) > > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January 4, 2009. > > Abstract > > In this document, we discuss the benefits and possible realizations > of IPFIX traffic compression. Experiments with real measurement data > show that a significant compression gain can be achieved by applying > the DEFLATE compression method to IPFIX data sets. Compression of > IPFIX traffic can be based on underlying transport protocols, such as > IPComp and TLS/DTLS, or realized as an extension of the IPFIX > protocol. > > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 1] > > Internet-Draft IPFIX Compression July 2008 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 3. Reduction and Compression of Measurement Data . . . . . . . . 3 > 3.1. IPFIX Data Reduction Mechanisms . . . . . . . . . . . . . 4 > 3.2. Lossless Compression of Mesurement Data . . . . . . . . . 4 > > 4. Gain of IPFIX Compression . . . . . . . . . . . . . . . . . . 5 > 4.1. University Network Flow Compression . . . . . . . . . . . 6 > 4.2. ISP Backbone Flow Compression . . . . . . . . . . . . . . 7 > 4.3. Packet Report Compression . . . . . . . . . . . . . . . . 7 > > 5. Possible Realization of IPFIX Compression . . . . . . . . . . 8 > 5.1. Compressed IPsec Tunnel . . . . . . . . . . . . . . . . . 9 > 5.2. TLS/DTLS Compression . . . . . . . . . . . . . . . . . . . 9 > 5.3. Compressed IPFIX Messages . . . . . . . . . . . . . . . . 9 > 5.4. Compressed Data Sets . . . . . . . . . . . . . . . . . . . 10 > > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 > > 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 > > 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 > 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 > 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 > Intellectual Property and Copyright Statements . . . . . . . . . . 15 > > > > > > > > > > > > > > > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 2] > > Internet-Draft IPFIX Compression July 2008 > > > 1. Introduction > > Exporting measurement data with low bandwidth utilization was not a > primary design goal of the IPFIX protocol. Indeed, bandwidth > efficiency is not mentioned in [RFC3917]. Although the separation of Even so, IPFIX was based on NetFlow v9 which is arguably more efficient that some of the alternatives under consideration. > Templates and Data Records and the binary encoding prevents > unnecessary inflation of the exported Flow information, the > underlying mechanisms were mainly motivated by the objective to > simplify the work of the IPFIX Exporter. > > However, bandwidth efficient export of Flow information is very > beneficial in practice. If it was possible to export the same > information with significantly reduced data volume (in terms of > number of bytes), we could enjoy the following advantages: > o It would be possible to utilize links with smaller bandwidth > between Exporters and Collectors. > o Network congestion could be avoided which reduces the loss ratio > if UDP or PR-SCTP are used as transport protocol. > o Less network I/O performance would be required at both, Exporters > and Collectors. Similarly, the sender and receiver buffer sizes > of the Exporters and Collectors could be reduced. These advantages can also be realised in other ways, eg by exporting less data by sampling or aggregating. > This document discusses different options how the volume of exported > Flows can be reduced without information loss. Particularly, we will > show that lossless compression methods enable significant data volume > reduction. Clearly there's a trade-off between data volume reduction and CPU resource required for the (de)compression. > Section 3 gives an overview on existing approaches and > methods to reduce and compress traffic measurement data. > Subsequently, Section 4 presents measurement results showing the high > compressibility of IPFIX Data Sets containing Flow Records or Packet > Records. Finally, Section 5 describes different ways how compression > methods can be applied to the IPFIX protocol. > > > 2. Terminology > > This document adopts the terminologies used in [RFC5101], > [I-D.ietf-ipfix-file], and [I-D.ietf-psamp-protocol]. As in > [RFC5101], these specific terms have the first letter of a word > capitalized when used in this document. > > > 3. Reduction and Compression of Measurement Data > > This section summarizes existing approaches of lossless reduction and > compression of measurement data. Section 3.1 starts with a summary > of existing IPFIX data reduction mechanisms. Section 3.2 presents > other existing work applying lossless compression methods to > measurement data. "Existing" is a relative term that will be meaningless some years in the future. State something absolute, eg "defined in RFCxyz" or at least "at the time of writing". > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 3] > > Internet-Draft IPFIX Compression July 2008 > > > 3.1. IPFIX Data Reduction Mechanisms > > The IPFIX protocol and its standardized extensions provide three > different mechanisms to reduce the amount of exported data without > loss of information: > > Reduced size encoding: As specified in [RFC5101], integer and float > types can be encoded with reduced size if the smaller field size > is sufficient to carry the exported values. The actual encoding > size of a field in a Flow Record is defined by the field length in > the Template definition. The application of reduced size encoding > requires the definition of an appropriate Template. > > Data reduction by separation of common properties: Flows and packets > observed in a network often share common properties. In order to > avoid the repeated export of common properties with every Flow or > Packet Record, common properties can be exported once for all > Flows or packets in a separate Data Record defined by an Option > Template. How this can be realized is described in > [I-D.ietf-ipfix-reducing-redundancy]. > With respect to data reduction, this approach is very limited and > difficult to implement. The definition of common properties > requires that Flows or packets share exactly the same values for a > given set of Information Elements. Redundancy among different > Information Elements, for example within the same Flow or among > different Flows, cannot be reduced. Redundancy of values which > are very similar but not identical cannot be reduced either. > Finally, dynamically identifying common properties in a stream of > Data Records and estimating the probability of reappearance in the > future is difficult. Therefore, this data reduction approach is > mainly useful if the existence of certain common properties in the > Flows or packets is known a priori. > > Export of bidirectional Flows: The export of bidirectional Flow > (Biflow) information as specified in [RFC5153] reduces the number > of exported records if bidirectional traffic is observed. A > Biflow Record is larger than a Flow Record because it contains > additional fields of Reverse Information Elements, typically > carrying measurement data about the reverse Flow direction. A > Biflow Record may also contain the biflowDirection Information > Element to indicate the initiator of the Biflow. In most cases, a > small data reduction can be achieved because the Flow Key is > exported only once for both directions. > > 3.2. Lossless Compression of Mesurement Data "Measurement". > > We are aware of the following approaches which deployed general > purpose compression methods to reduce the amount of measurement data > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 4] > > Internet-Draft IPFIX Compression July 2008 > > > sent from a traffic monitor to a collector. > > nFlow: In 2004, Luca Deri proposed nFlow [nFlow] as an alternative > to IPFIX and NetFlow. One feature was the export of compressed > flow records using ZLIB [RFC1950] or GZIP [RFC1952] compressed > data format. > > DiMAPI: DiMAPI (Distributed Monitoring Application Programming > Interface) has been developed in the European IST project LOBSTER > [LOBSTER]. It enables the transport of measurement data from > distributed traffic sensors to analysis applications running on > remote hosts. In [PMI08], the authors evaluate different > compression methods used to reduce the amount of measurement data > transferred over the network. > > > 4. Gain of IPFIX Compression > > In order to circumstantiate the utility of applying compression > methods to Flow information, we conducted several experiments using > IPFIX Flow Records and PSAMP Packet Records collected in different > networks. Therefore, we chose the well-known compression method > DEFLATE which is specified in [RFC1951]. DEFLATE is based on LZ77 > algorithm and Huffman coding. It is deployed in various Internet > protocols and data formats, e.g. IMAP [RFC4978], IRIS [RFC4993], SIP > and RTSP [RFC3320], and PNG [RFC2083]. > > We applied the DEFLATE [RFC1951] compression method to Data Sets > containing different numbers of Data Records and calculated the > compression ratios. Therefore, we determined the compressed size > using the ZLIB compressed data format [RFC1950]. ZLIB provides a > generic container for compressed data which can be used in > combination with different compression methods. The ZLIB format > prepends a header of two bytes specifying compression method and > parameters, and appends a checksum of four bytes. Note that ZLIB is > preferred to the alternative GZIP format [RFC1952] since header and > trailer are shorter. We calculated the compression ratios including > the ZLIB header and trailer bytes. In order to get the raw size of > the compressed Data Sets, six bytes need to be subtracted from the > figures indicated in the tables below, resulting in higher > compression ratios. > > The results presented in the following subsections show that the > compression gain is large for Flow Records and much smaller for > Packet Records. Why are they different? > Better compression can be achieved with larger Data > Sets. However, the compressed data volume never exceeds the original > size of the Data Sets in our experiments. > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 5] > > Internet-Draft IPFIX Compression July 2008 > > > 4.1. University Network Flow Compression > > We applied DEFLATE to Flows measured at the router connecting the > class B network of a university to the Internet at a link speed of > 2.4 Gigabit per second. Using unsampled Cisco NetFlow, the router > generates about 1,800 Flow Records per second in the evening hours > (active timeout is 30 minutes). The Flow Records were re-encoded > into IPFIX Data Sets using the Template shown in Table 1 below. The > definition of the Information Elements can be found in [RFC5102]. > > +----------+--------------------------+--------+ > | Field No | Information Element | Length | > +----------+--------------------------+--------+ > | 1 | sourceIPv4Address | 4 | > | 2 | destinationIPv4Address | 4 | > | 3 | sourceTransportPort | 2 | > | 4 | destinationTransportPort | 2 | > | 5 | protocolIdentifier | 1 | > | 6 | octetDeltaCount (*) | 4 | > | 7 | packetDeltaCount (*) | 4 | > | 8 | flowStartSeconds | 4 | > | 9 | flowEndSeconds | 4 | > +----------+--------------------------+--------+ > > (*) reduced size encoding > > Table 1: Flow Template > > The total length of one Data Record is 29 bytes. The Set header adds > another four bytes to the Data Set. > > In every compression run, the same 120,000 Flow Records were written > into Data Sets of different length. The compression was applied to > the entire Data Sets (i.e., Set header plus Data Records). Table 2 > shows the results. As can be seen, the Data Set can be compressed to > 15 percent or less of its original size. Data Sets with 100 Flow > Records could even be compressed to 2.1 percent of the original size. > > +-----------------+--------------+------------------+---------------+ > | Number of | Uncompressed | Compressed size | Mean | > | Records per | size | (mean; min; max) | compression | > | Data Set | | | ratio | > +-----------------+--------------+------------------+---------------+ > | 10 | 294 | 43.0; 38; 44 | 6.83 | > | 20 | 584 | 45.5; 43; 48 | 12.83 | > | 40 | 1164 | 49.2; 45; 51 | 23.65 | > | 60 | 1744 | 53.9; 52; 56 | 32.35 | > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 6] > > Internet-Draft IPFIX Compression July 2008 > > > | 100 | 2904 | 62.7; 61; 64 | 46.31 | > +-----------------+--------------+------------------+---------------+ > > Table 2: University Network: Compression Results Plotting the uncompressed size against the mean compressed size shows a fairly linear relationship. Please also give a column indicating the amount of effort required to perform the compression. Does this also scale linearly, or is there a sweet point beyond which excessive effort is required for a diminishing return? > > 4.2. ISP Backbone Flow Compression > > We repeated the experiment of Section 4.1 with Flows measured in the > Gigabit backbone network of a regional ISP in Germany. The observed > Flows contain a mixture of web traffic, mail traffic, database > queries, VPN tunnels, dial-in traffic etc. The measurements were > performed at a router using unsampled Cisco NetFlow with active and > idle flow timeouts set to 150 seconds, resulting in about 300 Flow > Records per second. As before, the Flow Records were converted into > IPFIX Data Sets using the Template of Table 1. Encapsulating again > 120,000 Flow Records into Data Sets of different length, we achieved > the compression results shown in Table 3. As can be seen, the > results are almost identical to those obtained in Section 4.1. And again, the uncompressed : compressed size is remarkably linear. > > +-----------------+--------------+------------------+---------------+ > | Number of | Uncompressed | Compressed size | Mean | > | Records per | size | (mean; min; max) | compression | > | Data Set | | | ratio | > +-----------------+--------------+------------------+---------------+ > | 10 | 294 | 43.1; 39; 46 | 6.82 | > | 20 | 584 | 45.6; 41; 48 | 12.80 | > | 40 | 1164 | 49.7; 45; 52 | 23.42 | > | 60 | 1744 | 54.0; 50; 57 | 32.29 | > | 100 | 2904 | 63.4; 59; 66 | 45.80 | > +-----------------+--------------+------------------+---------------+ > > Table 3: ISP Backbone Network: Compression Results > > 4.3. Packet Report Compression > > As specified in [I-D.ietf-psamp-protocol], the IPFIX protocol can be > used to export PSAMP Packet Reports. In order to evaluate the > compression gain that can be achieved with Packet Records, we > compressed Data Sets containing IP packet header sections covering > the IP and transport layer headers. The Template definition is shown > in Table 4 below. The definition of the Information Elements can be > found in [I-D.ietf-psamp-info]. > > > > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 7] > > Internet-Draft IPFIX Compression July 2008 > > > +----------+------------------------+----------+ > | Field No | Information Element | Length | > +----------+------------------------+----------+ > | 1 | observationTimeSeconds | 4 | > | 2 | ipHeaderPacketSection | variable | > +----------+------------------------+----------+ > > Table 4: Packet Report Template > > 120,000 packets were captured in the network of a research institute. > The resulting Packet Records were encapsulated in Data Sets of > different length. Table 5 shows the original and compressed lengths > of the Data Sets as well as the compression ratios. As can be seen, > the compression ratio stays below 2 even for a large number of Packet > Records per Data Set. Obviously, Packet Records are much less > compressible than Flow Records. I disagree. You're not comparing like with like. eg, packet records could be exported in the same format as table 1, except with packetDeltaCount = 1. Arguably, these should be slightly more compressible than the equivalent flow records. > The huge difference can be explained > by the fact that Flow Records usually contain packet header fields > where the observed values are very redundant. Certainly true for the fields chosen for the template in table 1. ie, sourceIPv4Address, destinationIPv4Address, sourceTransportPort and destinationTransportPort - even protocolIdentifier - may all be expected to contain high levels of redundancy across multiple flows. The experiment only seems to show that ipHeaderPacketSection may contain less redundancy than these individual fields do. It doesn't seem to prove anything about PSAMP versus IPFIX. > > +---------------+-------------------+-----------------+-------------+ > | Number of | Uncompressed size | Compressed size | Mean | > | Records per | (mean; min; max) | (mean; min; | compression | > | Data Set | | max) | ratio | > +---------------+-------------------+-----------------+-------------+ > | 10 | 405.5; 302; 574 | 318.3; 172; 437 | 1.27 | > | 20 | 807.0; 656; 1144 | 575.0; 341; 744 | 1.40 | > | 40 | 1610.1; 1324; | 1029.9; 615; | 1.56 | > | | 2260 | 1274 | | > | 60 | 2413.1; 2056; | 1451.9; 889; | 1.66 | > | | 3376 | 1771 | | > | 100 | 4019.3; 3512; | 2275.4; 1769; | 1.76 | > | | 5004 | 2675 | | > +---------------+-------------------+-----------------+-------------+ > > Table 5: Packet Reports: Compression Results > > > 5. Possible Realization of IPFIX Compression > > In this section, we discuss different options that allow applying > compression methods to IPFIX traffic. At first, we describe two > solutions which are based on compression options provided by IPComp > and DTLS. As third and fourth option, we propose IPFIX-specific > solutions which do not depend on the underlying transport protocol, > but require extensions of the IPFIX protocol. > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 8] > > Internet-Draft IPFIX Compression July 2008 > > > 5.1. Compressed IPsec Tunnel > > IP payload compression (IPComp) [RFC3173] enables the compression of > IP datagrams exchanged between a pair of communicating nodes. > Therefore, an IPComp association (IPCA) between the two nodes must be > established. DEFLATE [RFC2394] and Lempel-Ziv-Stac (LZS) [RFC2395] > are among the standardized compression methods. IPComp has been > conceived for compressing IP datagrams before sending them over an > encrypted tunnel. Dynamic negotiation of IPCAs has been standardized > as part of the Internet Key Exchange protocol (IKE) [RFC4306]. > > If IPFIX traffic is transported over an IPsec tunnel, IPComp may be > used for compression. In this case, the compression is transparent > to both, Exporting Process and Collecting Process. > > 5.2. TLS/DTLS Compression > > TLS [RFC4346] and DTLS [RFC4347] enable the negotiation and > deployment of a lossless compression method. Two compression methods > have been standardized for usage with TLS: DEFLATE [RFC3749] and > Lempel-Ziv-Stac (LZS) [RFC3943]. For DTLS, no compression methods > have been standardized, yet. > > RFC 3749 [RFC3749] recommends the usage of stateful compression for > TLS, which means that a compression history across packets is > maintained to achieve higher compression ratios. DTLS has been > conceived for transport protocols that do not guarantee reliable, > sequenced packet delivery. In this case, only stateless per-packet > compression is possible. For example, DEFLATE and LZS could be > applied on a per-packet basis. > > The IPFIX protocol specification [RFC5101] mandates the support of > DTLS if SCTP or UDP are used as transport protocol for IPFIX. > Similarly, if TCP is used as transport protocol, TLS must be > supported. Although no compression method has been standardized for > DTLS, DEFLATE [RFC1951] can be used for stateless compression of > individual SCTP messages or UDP datagrams. The utilization of DTLS > or TLS is not mandated by the IPFIX protocol. If DTLS or TLS are > employed, compression methods may be negotiated and deployed between > the Exporting Process and the Collecting Process. > > 5.3. Compressed IPFIX Messages > > A compressed variant of the IPFIX Message format could be designed as > follows. The IPFIX Message header remains uncompressed and is > structured as defined in Section 3.1 of [RFC5101]. The message > payload following the IPFIX Message header is compressed using > DEFLATE as specified in [RFC1951]. The payload may include templates and options, which you've not discussed. Since these may be sent infrequently (compared with data records) it may be more efficient _not_ to compress them. [Later: OK, see section 5.4] > Optionally, the ZLIB format > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 9] > > Internet-Draft IPFIX Compression July 2008 > > > [RFC1950] could be used to enable the choice of alternative > compression methods and to protect the data integrity by a checksum. > In order to distinguish compressed IPFIX Messages from normal IPFIX > Messages, a new IPFIX Version Number must be used for compressed > IPFIX Messages, for example 0x000b. Alternatively, the template could be marked as compressed. eg by using a new template set ID (eg, Set ID 4 = a set of templates whose data will be sent in compressed formats). Or, such templates could contain a marker (eg, a new zero-length flag field) indicating that the corresponding data records will be sent in compressed format. This would allow some (even all) data sets to be compressed, while allowing templates and options to remain uncompressed. [Later: OK, see section 5.4] > > Leaving the IPFIX Message header uncompressed facilitates the work of > both, Exporting Processes and Collecting Processes. The version > number and length field are required to decode the message correctly. > The Exporting Process does not know in advance how much time the > compression will require. Keeping the export time in the IPFIX > Message Header allows the Exporting Process to fill this field after > compressing the message payload. If the EP was feeding a Compressed IPsec Tunnel (per 5.1 above) then the export time cannot be filled accurately. Instead, it'll be the time the EP handed the data to the tunnel process. Indeed, if the EP is feeding a regular interface driver, the export time will indicate when the EP handed the data to the driver - which may then buffer the data pending transmission on the media, and it may be some time before the driver is able to transmit. So the export time may often be a best-effort. > Finally, the uncompressed > Observation Domain ID allows the Collecting Process to classify IPFIX > Messages before decompressing the message payload. Indeed, the CP may simply want to store compressed records for later processing. > > 5.4. Compressed Data Sets > > Instead of compressing the entire payload of IPFIX Messages, it is > also possible to introduce a new Set type called Deflate Template > Set. Just like normal Template Sets, the Deflate Template Set is used > to carry Templates, namely Deflate Templates. The format of Deflate > Template Records is the same as the Template Record format specified > in Section 3.4.1 of [RFC5101]. However, the corresponding Data Sets > differ: starting with the first byte after the Set header, the > sequence of Deflate Data Records is compressed using DEFLATE > [RFC1951]. Again, the ZLIB format [RFC1950] could be used to enable > the choice of alternative compression methods and to protect the data > integrity by a checksum. The Set header remains uncompressed and > includes the length of the Set after compression. In order to > distinguish Deflate Template Sets from other Sets, a new Set ID value > must be specified (e.g., Set ID = 4). > > Compression at the level of Data Sets is more flexible than the > compression of IPFIX Messages as described in Section 5.3 since it > allows exporting compressed and uncompressed Records within a single > IPFIX Message. On the other hand, the size of the compressed data > blocks is smaller, which usually results in lower compression ratios. Some example figures would be interesting. > > > 6. Security Considerations > > The same security considerations as for the IPFIX protocol [RFC5101] > apply. > > The protocol extensions discussed in Section 5.3 and Section 5.4 > introduce additional security issues for the Collector. An attacker > may send forged compressed IPFIX Messages or Data Sets to the > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 10] > > Internet-Draft IPFIX Compression July 2008 > > > Collector which require very large amount of memory after > decompression, leading to possible memory exhaustion. The > decompression of such data may also require enormous processing > resources, causing a temporary denial of service. The Collector must > implement a protection mechanism which ensures that the decompression > is interrupted if it spends large amount of memory or runtime. However, that could lead to loss of genuine IPFIX data. P. > > > 7. IANA Considerations > > The two compression solutions described in Section 5.3 and > Section 5.4 require the assignment of a new IPFIX Version Number or > IPFIX Set ID respectively. As specifed in [RFC5101], the > standardization of these solutions requires a Standards Action > [RFC2434]. > > > 8. References > > 8.1. Normative References > > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", BCP 26, RFC 2434, > October 1998. > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > RFC 5102, January 2008. > > [I-D.ietf-ipfix-file] > Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. > Wagner, "An IPFIX-Based File Format", > draft-ietf-ipfix-file-01 (work in progress), > February 2008. > > [I-D.ietf-psamp-protocol] > Claise, B., "Packet Sampling (PSAMP) Protocol > Specifications", draft-ietf-psamp-protocol-09 (work in > progress), December 2007. > > [I-D.ietf-psamp-info] > Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. > Carle, "Information Model for Packet Sampling Exports", > draft-ietf-psamp-info-08 (work in progress), > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 11] > > Internet-Draft IPFIX Compression July 2008 > > > February 2008. > > 8.2. Informative References > > [I-D.ietf-ipfix-reducing-redundancy] > Boschi, E., "Reducing Redundancy in IP Flow Information > Export (IPFIX) and Packet Sampling (PSAMP) Reports", > draft-ietf-ipfix-reducing-redundancy-04 (work in > progress), May 2007. > > [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. > Aitken, "IPFIX Implementation Guidelines", RFC 5153, > April 2008. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export (IPFIX)", > RFC 3917, October 2004. > > [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format > Specification version 3.3", RFC 1950, May 1996. > > [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification > version 1.3", RFC 1951, May 1996. > > [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. > Randers-Pehrson, "GZIP file format specification version > 4.3", RFC 1952, May 1996. > > [RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", > RFC 2394, December 1998. > > [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using > LZS", RFC 2395, December 1998. > > [RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP > Payload Compression Protocol (IPComp)", RFC 3173, > September 2001. > > [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol > Compression Methods", RFC 3749, May 2004. > > [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol > Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, > November 2004. > > [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", > RFC 4306, December 2005. > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 12] > > Internet-Draft IPFIX Compression July 2008 > > > [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security > (TLS) Protocol Version 1.1", RFC 4346, April 2006. > > [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer > Security", RFC 4347, April 2006. > > [nFlow] Deri, L., "nFlow: Monitoring Flows on IPv4/v6 Networks", > TERENA Networking Conference 2004, June 2004. > > [LOBSTER] "IST LOBSTER Project Homepage", > Homepage http://www.ist-lobster.org, 2008. > > [PMI08] Politopoulos, P., Markatos, E., and S. Ioannidis, > "Evaluation of Compression of Remote Network Monitoring > Data Streams", IEEE Workshop on End-to-End Monitoring > Techniques and Services E2EMON 2008, April 2008. > > [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, > August 2007. > > [RFC4993] Newton, A., "A Lightweight UDP Transfer Protocol for the > Internet Registry Information Service", RFC 4993, > August 2007. > > [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., > Liu, Z., and J. Rosenberg, "Signaling Compression > (SigComp)", RFC 3320, January 2003. > > [RFC2083] Boutell, T., "PNG (Portable Network Graphics) > Specification Version 1.0", RFC 2083, March 1997. > > > Authors' Addresses > > Gerhard Muenz > University of Tuebingen > Computer Networks and Internet > Sand 13 > Tuebingen D-72076 > DE > > Phone: +49 7071 29-70534 > Email: muenz@informatik.uni-tuebingen.de > URI: http://net.informatik.uni-tuebingen.de/~muenz > > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 13] > > Internet-Draft IPFIX Compression July 2008 > > > Lothar Braun > Technische Universitaet Muenchen > Network Architectures and Services, Institute for Informatics > Boltzmannstrasse 3 > Garching D-85748 > DE > > Phone: +49 89 289-18010 > Email: braun@net.in.tum.de > URI: http://www.net.in.tum.de/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 14] > > Internet-Draft IPFIX Compression July 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 15] > -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Jul 22 05:36:12 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B4A3A698A; Tue, 22 Jul 2008 05:36:12 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88AB3A698A for ; Tue, 22 Jul 2008 05:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.435 X-Spam-Level: X-Spam-Status: No, score=-7.435 tagged_above=-999 required=5 tests=[AWL=1.164, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2g+Jln5kEua for ; Tue, 22 Jul 2008 05:36:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7E3BB3A68CD for ; Tue, 22 Jul 2008 05:36:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,231,1215388800"; d="scan'208";a="15040750" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Jul 2008 12:36:46 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6MCakM1018834; Tue, 22 Jul 2008 14:36:46 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6MCakxt019556; Tue, 22 Jul 2008 12:36:46 GMT Received: from [10.61.98.55] (dhcp-10-61-98-55.cisco.com [10.61.98.55]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6MCait15910; Tue, 22 Jul 2008 13:36:44 +0100 (BST) Message-ID: <4885D45F.20700@cisco.com> Date: Tue, 22 Jul 2008 13:36:47 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Gerhard Muenz , braun@net.in.tum.de DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=39903; t=1216730206; x=1217594206; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-muenz-ipfix-compression-00 |Sender:=20; bh=DswAgTDLBfbjBq5ngLEgIE6qW+atVfriCqzE7cAIJ2s=; b=t/JjOW9A3Dq7NqyaDnJDgIfhMKp++2R81Vy9KRPAIo0MMX9mRU+mqFpubQ pcB4POQeJMLmpXf1C3A8MZQOqS9ZOm++vbcaXQafJ7JdkyZo99sm6wni3mRK zKxhAcg0kt; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "ipfix@ietf.org" Subject: [IPFIX] review: draft-muenz-ipfix-compression-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Lothar, Good idea and impressive figures. Please find some feedback inline. > IP Flow Information Export WG G. Muenz > Internet-Draft University of Tuebingen > Expires: January 4, 2009 L. Braun > Technische Universitaet Muenchen > July 3, 2008 > > > Lossless Compression for IP Flow Information Export (IPFIX) > > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January 4, 2009. > > Abstract > > In this document, we discuss the benefits and possible realizations > of IPFIX traffic compression. Experiments with real measurement data > show that a significant compression gain can be achieved by applying > the DEFLATE compression method to IPFIX data sets. Compression of > IPFIX traffic can be based on underlying transport protocols, such as > IPComp and TLS/DTLS, or realized as an extension of the IPFIX > protocol. > > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 1] > > Internet-Draft IPFIX Compression July 2008 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 3. Reduction and Compression of Measurement Data . . . . . . . . 3 > 3.1. IPFIX Data Reduction Mechanisms . . . . . . . . . . . . . 4 > 3.2. Lossless Compression of Mesurement Data . . . . . . . . . 4 > > 4. Gain of IPFIX Compression . . . . . . . . . . . . . . . . . . 5 > 4.1. University Network Flow Compression . . . . . . . . . . . 6 > 4.2. ISP Backbone Flow Compression . . . . . . . . . . . . . . 7 > 4.3. Packet Report Compression . . . . . . . . . . . . . . . . 7 > > 5. Possible Realization of IPFIX Compression . . . . . . . . . . 8 > 5.1. Compressed IPsec Tunnel . . . . . . . . . . . . . . . . . 9 > 5.2. TLS/DTLS Compression . . . . . . . . . . . . . . . . . . . 9 > 5.3. Compressed IPFIX Messages . . . . . . . . . . . . . . . . 9 > 5.4. Compressed Data Sets . . . . . . . . . . . . . . . . . . . 10 > > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 > > 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 > > 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 > 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 > 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 > Intellectual Property and Copyright Statements . . . . . . . . . . 15 > > > > > > > > > > > > > > > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 2] > > Internet-Draft IPFIX Compression July 2008 > > > 1. Introduction > > Exporting measurement data with low bandwidth utilization was not a > primary design goal of the IPFIX protocol. Indeed, bandwidth > efficiency is not mentioned in [RFC3917]. Although the separation of Even so, IPFIX was based on NetFlow v9 which is arguably more efficient that some of the alternatives under consideration. > Templates and Data Records and the binary encoding prevents > unnecessary inflation of the exported Flow information, the > underlying mechanisms were mainly motivated by the objective to > simplify the work of the IPFIX Exporter. > > However, bandwidth efficient export of Flow information is very > beneficial in practice. If it was possible to export the same > information with significantly reduced data volume (in terms of > number of bytes), we could enjoy the following advantages: > o It would be possible to utilize links with smaller bandwidth > between Exporters and Collectors. > o Network congestion could be avoided which reduces the loss ratio > if UDP or PR-SCTP are used as transport protocol. > o Less network I/O performance would be required at both, Exporters > and Collectors. Similarly, the sender and receiver buffer sizes > of the Exporters and Collectors could be reduced. These advantages can also be realised in other ways, eg by exporting less data by sampling or aggregating. > This document discusses different options how the volume of exported > Flows can be reduced without information loss. Particularly, we will > show that lossless compression methods enable significant data volume > reduction. Clearly there's a trade-off between data volume reduction and CPU resource required for the (de)compression. > Section 3 gives an overview on existing approaches and > methods to reduce and compress traffic measurement data. > Subsequently, Section 4 presents measurement results showing the high > compressibility of IPFIX Data Sets containing Flow Records or Packet > Records. Finally, Section 5 describes different ways how compression > methods can be applied to the IPFIX protocol. > > > 2. Terminology > > This document adopts the terminologies used in [RFC5101], > [I-D.ietf-ipfix-file], and [I-D.ietf-psamp-protocol]. As in > [RFC5101], these specific terms have the first letter of a word > capitalized when used in this document. > > > 3. Reduction and Compression of Measurement Data > > This section summarizes existing approaches of lossless reduction and > compression of measurement data. Section 3.1 starts with a summary > of existing IPFIX data reduction mechanisms. Section 3.2 presents > other existing work applying lossless compression methods to > measurement data. "Existing" is a relative term that will be meaningless some years in the future. State something absolute, eg "defined in RFCxyz" or at least "at the time of writing". > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 3] > > Internet-Draft IPFIX Compression July 2008 > > > 3.1. IPFIX Data Reduction Mechanisms > > The IPFIX protocol and its standardized extensions provide three > different mechanisms to reduce the amount of exported data without > loss of information: > > Reduced size encoding: As specified in [RFC5101], integer and float > types can be encoded with reduced size if the smaller field size > is sufficient to carry the exported values. The actual encoding > size of a field in a Flow Record is defined by the field length in > the Template definition. The application of reduced size encoding > requires the definition of an appropriate Template. > > Data reduction by separation of common properties: Flows and packets > observed in a network often share common properties. In order to > avoid the repeated export of common properties with every Flow or > Packet Record, common properties can be exported once for all > Flows or packets in a separate Data Record defined by an Option > Template. How this can be realized is described in > [I-D.ietf-ipfix-reducing-redundancy]. > With respect to data reduction, this approach is very limited and > difficult to implement. The definition of common properties > requires that Flows or packets share exactly the same values for a > given set of Information Elements. Redundancy among different > Information Elements, for example within the same Flow or among > different Flows, cannot be reduced. Redundancy of values which > are very similar but not identical cannot be reduced either. > Finally, dynamically identifying common properties in a stream of > Data Records and estimating the probability of reappearance in the > future is difficult. Therefore, this data reduction approach is > mainly useful if the existence of certain common properties in the > Flows or packets is known a priori. > > Export of bidirectional Flows: The export of bidirectional Flow > (Biflow) information as specified in [RFC5153] reduces the number > of exported records if bidirectional traffic is observed. A > Biflow Record is larger than a Flow Record because it contains > additional fields of Reverse Information Elements, typically > carrying measurement data about the reverse Flow direction. A > Biflow Record may also contain the biflowDirection Information > Element to indicate the initiator of the Biflow. In most cases, a > small data reduction can be achieved because the Flow Key is > exported only once for both directions. > > 3.2. Lossless Compression of Mesurement Data "Measurement". > > We are aware of the following approaches which deployed general > purpose compression methods to reduce the amount of measurement data > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 4] > > Internet-Draft IPFIX Compression July 2008 > > > sent from a traffic monitor to a collector. > > nFlow: In 2004, Luca Deri proposed nFlow [nFlow] as an alternative > to IPFIX and NetFlow. One feature was the export of compressed > flow records using ZLIB [RFC1950] or GZIP [RFC1952] compressed > data format. > > DiMAPI: DiMAPI (Distributed Monitoring Application Programming > Interface) has been developed in the European IST project LOBSTER > [LOBSTER]. It enables the transport of measurement data from > distributed traffic sensors to analysis applications running on > remote hosts. In [PMI08], the authors evaluate different > compression methods used to reduce the amount of measurement data > transferred over the network. > > > 4. Gain of IPFIX Compression > > In order to circumstantiate the utility of applying compression > methods to Flow information, we conducted several experiments using > IPFIX Flow Records and PSAMP Packet Records collected in different > networks. Therefore, we chose the well-known compression method > DEFLATE which is specified in [RFC1951]. DEFLATE is based on LZ77 > algorithm and Huffman coding. It is deployed in various Internet > protocols and data formats, e.g. IMAP [RFC4978], IRIS [RFC4993], SIP > and RTSP [RFC3320], and PNG [RFC2083]. > > We applied the DEFLATE [RFC1951] compression method to Data Sets > containing different numbers of Data Records and calculated the > compression ratios. Therefore, we determined the compressed size > using the ZLIB compressed data format [RFC1950]. ZLIB provides a > generic container for compressed data which can be used in > combination with different compression methods. The ZLIB format > prepends a header of two bytes specifying compression method and > parameters, and appends a checksum of four bytes. Note that ZLIB is > preferred to the alternative GZIP format [RFC1952] since header and > trailer are shorter. We calculated the compression ratios including > the ZLIB header and trailer bytes. In order to get the raw size of > the compressed Data Sets, six bytes need to be subtracted from the > figures indicated in the tables below, resulting in higher > compression ratios. > > The results presented in the following subsections show that the > compression gain is large for Flow Records and much smaller for > Packet Records. Why are they different? > Better compression can be achieved with larger Data > Sets. However, the compressed data volume never exceeds the original > size of the Data Sets in our experiments. > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 5] > > Internet-Draft IPFIX Compression July 2008 > > > 4.1. University Network Flow Compression > > We applied DEFLATE to Flows measured at the router connecting the > class B network of a university to the Internet at a link speed of > 2.4 Gigabit per second. Using unsampled Cisco NetFlow, the router > generates about 1,800 Flow Records per second in the evening hours > (active timeout is 30 minutes). The Flow Records were re-encoded > into IPFIX Data Sets using the Template shown in Table 1 below. The > definition of the Information Elements can be found in [RFC5102]. > > +----------+--------------------------+--------+ > | Field No | Information Element | Length | > +----------+--------------------------+--------+ > | 1 | sourceIPv4Address | 4 | > | 2 | destinationIPv4Address | 4 | > | 3 | sourceTransportPort | 2 | > | 4 | destinationTransportPort | 2 | > | 5 | protocolIdentifier | 1 | > | 6 | octetDeltaCount (*) | 4 | > | 7 | packetDeltaCount (*) | 4 | > | 8 | flowStartSeconds | 4 | > | 9 | flowEndSeconds | 4 | > +----------+--------------------------+--------+ > > (*) reduced size encoding > > Table 1: Flow Template > > The total length of one Data Record is 29 bytes. The Set header adds > another four bytes to the Data Set. > > In every compression run, the same 120,000 Flow Records were written > into Data Sets of different length. The compression was applied to > the entire Data Sets (i.e., Set header plus Data Records). Table 2 > shows the results. As can be seen, the Data Set can be compressed to > 15 percent or less of its original size. Data Sets with 100 Flow > Records could even be compressed to 2.1 percent of the original size. > > +-----------------+--------------+------------------+---------------+ > | Number of | Uncompressed | Compressed size | Mean | > | Records per | size | (mean; min; max) | compression | > | Data Set | | | ratio | > +-----------------+--------------+------------------+---------------+ > | 10 | 294 | 43.0; 38; 44 | 6.83 | > | 20 | 584 | 45.5; 43; 48 | 12.83 | > | 40 | 1164 | 49.2; 45; 51 | 23.65 | > | 60 | 1744 | 53.9; 52; 56 | 32.35 | > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 6] > > Internet-Draft IPFIX Compression July 2008 > > > | 100 | 2904 | 62.7; 61; 64 | 46.31 | > +-----------------+--------------+------------------+---------------+ > > Table 2: University Network: Compression Results Plotting the uncompressed size against the mean compressed size shows a fairly linear relationship. Please also give a column indicating the amount of effort required to perform the compression. Does this also scale linearly, or is there a sweet point beyond which excessive effort is required for a diminishing return? > > 4.2. ISP Backbone Flow Compression > > We repeated the experiment of Section 4.1 with Flows measured in the > Gigabit backbone network of a regional ISP in Germany. The observed > Flows contain a mixture of web traffic, mail traffic, database > queries, VPN tunnels, dial-in traffic etc. The measurements were > performed at a router using unsampled Cisco NetFlow with active and > idle flow timeouts set to 150 seconds, resulting in about 300 Flow > Records per second. As before, the Flow Records were converted into > IPFIX Data Sets using the Template of Table 1. Encapsulating again > 120,000 Flow Records into Data Sets of different length, we achieved > the compression results shown in Table 3. As can be seen, the > results are almost identical to those obtained in Section 4.1. And again, the uncompressed : compressed size is remarkably linear. > > +-----------------+--------------+------------------+---------------+ > | Number of | Uncompressed | Compressed size | Mean | > | Records per | size | (mean; min; max) | compression | > | Data Set | | | ratio | > +-----------------+--------------+------------------+---------------+ > | 10 | 294 | 43.1; 39; 46 | 6.82 | > | 20 | 584 | 45.6; 41; 48 | 12.80 | > | 40 | 1164 | 49.7; 45; 52 | 23.42 | > | 60 | 1744 | 54.0; 50; 57 | 32.29 | > | 100 | 2904 | 63.4; 59; 66 | 45.80 | > +-----------------+--------------+------------------+---------------+ > > Table 3: ISP Backbone Network: Compression Results > > 4.3. Packet Report Compression > > As specified in [I-D.ietf-psamp-protocol], the IPFIX protocol can be > used to export PSAMP Packet Reports. In order to evaluate the > compression gain that can be achieved with Packet Records, we > compressed Data Sets containing IP packet header sections covering > the IP and transport layer headers. The Template definition is shown > in Table 4 below. The definition of the Information Elements can be > found in [I-D.ietf-psamp-info]. > > > > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 7] > > Internet-Draft IPFIX Compression July 2008 > > > +----------+------------------------+----------+ > | Field No | Information Element | Length | > +----------+------------------------+----------+ > | 1 | observationTimeSeconds | 4 | > | 2 | ipHeaderPacketSection | variable | > +----------+------------------------+----------+ > > Table 4: Packet Report Template > > 120,000 packets were captured in the network of a research institute. > The resulting Packet Records were encapsulated in Data Sets of > different length. Table 5 shows the original and compressed lengths > of the Data Sets as well as the compression ratios. As can be seen, > the compression ratio stays below 2 even for a large number of Packet > Records per Data Set. Obviously, Packet Records are much less > compressible than Flow Records. I disagree. You're not comparing like with like. eg, packet records could be exported in the same format as table 1, except with packetDeltaCount = 1. Arguably, these should be slightly more compressible than the equivalent flow records. > The huge difference can be explained > by the fact that Flow Records usually contain packet header fields > where the observed values are very redundant. Certainly true for the fields chosen for the template in table 1. ie, sourceIPv4Address, destinationIPv4Address, sourceTransportPort and destinationTransportPort - even protocolIdentifier - may all be expected to contain high levels of redundancy across multiple flows. The experiment only seems to show that ipHeaderPacketSection may contain less redundancy than these individual fields do. It doesn't seem to prove anything about PSAMP versus IPFIX. > > +---------------+-------------------+-----------------+-------------+ > | Number of | Uncompressed size | Compressed size | Mean | > | Records per | (mean; min; max) | (mean; min; | compression | > | Data Set | | max) | ratio | > +---------------+-------------------+-----------------+-------------+ > | 10 | 405.5; 302; 574 | 318.3; 172; 437 | 1.27 | > | 20 | 807.0; 656; 1144 | 575.0; 341; 744 | 1.40 | > | 40 | 1610.1; 1324; | 1029.9; 615; | 1.56 | > | | 2260 | 1274 | | > | 60 | 2413.1; 2056; | 1451.9; 889; | 1.66 | > | | 3376 | 1771 | | > | 100 | 4019.3; 3512; | 2275.4; 1769; | 1.76 | > | | 5004 | 2675 | | > +---------------+-------------------+-----------------+-------------+ > > Table 5: Packet Reports: Compression Results > > > 5. Possible Realization of IPFIX Compression > > In this section, we discuss different options that allow applying > compression methods to IPFIX traffic. At first, we describe two > solutions which are based on compression options provided by IPComp > and DTLS. As third and fourth option, we propose IPFIX-specific > solutions which do not depend on the underlying transport protocol, > but require extensions of the IPFIX protocol. > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 8] > > Internet-Draft IPFIX Compression July 2008 > > > 5.1. Compressed IPsec Tunnel > > IP payload compression (IPComp) [RFC3173] enables the compression of > IP datagrams exchanged between a pair of communicating nodes. > Therefore, an IPComp association (IPCA) between the two nodes must be > established. DEFLATE [RFC2394] and Lempel-Ziv-Stac (LZS) [RFC2395] > are among the standardized compression methods. IPComp has been > conceived for compressing IP datagrams before sending them over an > encrypted tunnel. Dynamic negotiation of IPCAs has been standardized > as part of the Internet Key Exchange protocol (IKE) [RFC4306]. > > If IPFIX traffic is transported over an IPsec tunnel, IPComp may be > used for compression. In this case, the compression is transparent > to both, Exporting Process and Collecting Process. > > 5.2. TLS/DTLS Compression > > TLS [RFC4346] and DTLS [RFC4347] enable the negotiation and > deployment of a lossless compression method. Two compression methods > have been standardized for usage with TLS: DEFLATE [RFC3749] and > Lempel-Ziv-Stac (LZS) [RFC3943]. For DTLS, no compression methods > have been standardized, yet. > > RFC 3749 [RFC3749] recommends the usage of stateful compression for > TLS, which means that a compression history across packets is > maintained to achieve higher compression ratios. DTLS has been > conceived for transport protocols that do not guarantee reliable, > sequenced packet delivery. In this case, only stateless per-packet > compression is possible. For example, DEFLATE and LZS could be > applied on a per-packet basis. > > The IPFIX protocol specification [RFC5101] mandates the support of > DTLS if SCTP or UDP are used as transport protocol for IPFIX. > Similarly, if TCP is used as transport protocol, TLS must be > supported. Although no compression method has been standardized for > DTLS, DEFLATE [RFC1951] can be used for stateless compression of > individual SCTP messages or UDP datagrams. The utilization of DTLS > or TLS is not mandated by the IPFIX protocol. If DTLS or TLS are > employed, compression methods may be negotiated and deployed between > the Exporting Process and the Collecting Process. > > 5.3. Compressed IPFIX Messages > > A compressed variant of the IPFIX Message format could be designed as > follows. The IPFIX Message header remains uncompressed and is > structured as defined in Section 3.1 of [RFC5101]. The message > payload following the IPFIX Message header is compressed using > DEFLATE as specified in [RFC1951]. The payload may include templates and options, which you've not discussed. Since these may be sent infrequently (compared with data records) it may be more efficient _not_ to compress them. [Later: OK, see section 5.4] > Optionally, the ZLIB format > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 9] > > Internet-Draft IPFIX Compression July 2008 > > > [RFC1950] could be used to enable the choice of alternative > compression methods and to protect the data integrity by a checksum. > In order to distinguish compressed IPFIX Messages from normal IPFIX > Messages, a new IPFIX Version Number must be used for compressed > IPFIX Messages, for example 0x000b. Alternatively, the template could be marked as compressed. eg by using a new template set ID (eg, Set ID 4 = a set of templates whose data will be sent in compressed formats). Or, such templates could contain a marker (eg, a new zero-length flag field) indicating that the corresponding data records will be sent in compressed format. This would allow some (even all) data sets to be compressed, while allowing templates and options to remain uncompressed. [Later: OK, see section 5.4] > > Leaving the IPFIX Message header uncompressed facilitates the work of > both, Exporting Processes and Collecting Processes. The version > number and length field are required to decode the message correctly. > The Exporting Process does not know in advance how much time the > compression will require. Keeping the export time in the IPFIX > Message Header allows the Exporting Process to fill this field after > compressing the message payload. If the EP was feeding a Compressed IPsec Tunnel (per 5.1 above) then the export time cannot be filled accurately. Instead, it'll be the time the EP handed the data to the tunnel process. Indeed, if the EP is feeding a regular interface driver, the export time will indicate when the EP handed the data to the driver - which may then buffer the data pending transmission on the media, and it may be some time before the driver is able to transmit. So the export time may often be a best-effort. > Finally, the uncompressed > Observation Domain ID allows the Collecting Process to classify IPFIX > Messages before decompressing the message payload. Indeed, the CP may simply want to store compressed records for later processing. > > 5.4. Compressed Data Sets > > Instead of compressing the entire payload of IPFIX Messages, it is > also possible to introduce a new Set type called Deflate Template > Set. Just like normal Template Sets, the Deflate Template Set is used > to carry Templates, namely Deflate Templates. The format of Deflate > Template Records is the same as the Template Record format specified > in Section 3.4.1 of [RFC5101]. However, the corresponding Data Sets > differ: starting with the first byte after the Set header, the > sequence of Deflate Data Records is compressed using DEFLATE > [RFC1951]. Again, the ZLIB format [RFC1950] could be used to enable > the choice of alternative compression methods and to protect the data > integrity by a checksum. The Set header remains uncompressed and > includes the length of the Set after compression. In order to > distinguish Deflate Template Sets from other Sets, a new Set ID value > must be specified (e.g., Set ID = 4). > > Compression at the level of Data Sets is more flexible than the > compression of IPFIX Messages as described in Section 5.3 since it > allows exporting compressed and uncompressed Records within a single > IPFIX Message. On the other hand, the size of the compressed data > blocks is smaller, which usually results in lower compression ratios. Some example figures would be interesting. > > > 6. Security Considerations > > The same security considerations as for the IPFIX protocol [RFC5101] > apply. > > The protocol extensions discussed in Section 5.3 and Section 5.4 > introduce additional security issues for the Collector. An attacker > may send forged compressed IPFIX Messages or Data Sets to the > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 10] > > Internet-Draft IPFIX Compression July 2008 > > > Collector which require very large amount of memory after > decompression, leading to possible memory exhaustion. The > decompression of such data may also require enormous processing > resources, causing a temporary denial of service. The Collector must > implement a protection mechanism which ensures that the decompression > is interrupted if it spends large amount of memory or runtime. However, that could lead to loss of genuine IPFIX data. P. > > > 7. IANA Considerations > > The two compression solutions described in Section 5.3 and > Section 5.4 require the assignment of a new IPFIX Version Number or > IPFIX Set ID respectively. As specifed in [RFC5101], the > standardization of these solutions requires a Standards Action > [RFC2434]. > > > 8. References > > 8.1. Normative References > > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", BCP 26, RFC 2434, > October 1998. > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > RFC 5102, January 2008. > > [I-D.ietf-ipfix-file] > Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. > Wagner, "An IPFIX-Based File Format", > draft-ietf-ipfix-file-01 (work in progress), > February 2008. > > [I-D.ietf-psamp-protocol] > Claise, B., "Packet Sampling (PSAMP) Protocol > Specifications", draft-ietf-psamp-protocol-09 (work in > progress), December 2007. > > [I-D.ietf-psamp-info] > Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. > Carle, "Information Model for Packet Sampling Exports", > draft-ietf-psamp-info-08 (work in progress), > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 11] > > Internet-Draft IPFIX Compression July 2008 > > > February 2008. > > 8.2. Informative References > > [I-D.ietf-ipfix-reducing-redundancy] > Boschi, E., "Reducing Redundancy in IP Flow Information > Export (IPFIX) and Packet Sampling (PSAMP) Reports", > draft-ietf-ipfix-reducing-redundancy-04 (work in > progress), May 2007. > > [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. > Aitken, "IPFIX Implementation Guidelines", RFC 5153, > April 2008. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export (IPFIX)", > RFC 3917, October 2004. > > [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format > Specification version 3.3", RFC 1950, May 1996. > > [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification > version 1.3", RFC 1951, May 1996. > > [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. > Randers-Pehrson, "GZIP file format specification version > 4.3", RFC 1952, May 1996. > > [RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", > RFC 2394, December 1998. > > [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using > LZS", RFC 2395, December 1998. > > [RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP > Payload Compression Protocol (IPComp)", RFC 3173, > September 2001. > > [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol > Compression Methods", RFC 3749, May 2004. > > [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol > Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, > November 2004. > > [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", > RFC 4306, December 2005. > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 12] > > Internet-Draft IPFIX Compression July 2008 > > > [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security > (TLS) Protocol Version 1.1", RFC 4346, April 2006. > > [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer > Security", RFC 4347, April 2006. > > [nFlow] Deri, L., "nFlow: Monitoring Flows on IPv4/v6 Networks", > TERENA Networking Conference 2004, June 2004. > > [LOBSTER] "IST LOBSTER Project Homepage", > Homepage http://www.ist-lobster.org, 2008. > > [PMI08] Politopoulos, P., Markatos, E., and S. Ioannidis, > "Evaluation of Compression of Remote Network Monitoring > Data Streams", IEEE Workshop on End-to-End Monitoring > Techniques and Services E2EMON 2008, April 2008. > > [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, > August 2007. > > [RFC4993] Newton, A., "A Lightweight UDP Transfer Protocol for the > Internet Registry Information Service", RFC 4993, > August 2007. > > [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., > Liu, Z., and J. Rosenberg, "Signaling Compression > (SigComp)", RFC 3320, January 2003. > > [RFC2083] Boutell, T., "PNG (Portable Network Graphics) > Specification Version 1.0", RFC 2083, March 1997. > > > Authors' Addresses > > Gerhard Muenz > University of Tuebingen > Computer Networks and Internet > Sand 13 > Tuebingen D-72076 > DE > > Phone: +49 7071 29-70534 > Email: muenz@informatik.uni-tuebingen.de > URI: http://net.informatik.uni-tuebingen.de/~muenz > > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 13] > > Internet-Draft IPFIX Compression July 2008 > > > Lothar Braun > Technische Universitaet Muenchen > Network Architectures and Services, Institute for Informatics > Boltzmannstrasse 3 > Garching D-85748 > DE > > Phone: +49 89 289-18010 > Email: braun@net.in.tum.de > URI: http://www.net.in.tum.de/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 14] > > Internet-Draft IPFIX Compression July 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 15] > -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Jul 23 06:25:45 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BCA03A69AD; Wed, 23 Jul 2008 06:25:45 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7003A696E for ; Wed, 23 Jul 2008 06:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNdCsqkFg+d2 for ; Wed, 23 Jul 2008 06:25:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C3B6B3A6900 for ; Wed, 23 Jul 2008 06:25:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,238,1215388800"; d="scan'208";a="15161941" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 Jul 2008 13:26:24 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6NDQOal012514 for ; Wed, 23 Jul 2008 15:26:24 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6NDQOi8029559 for ; Wed, 23 Jul 2008 13:26:24 GMT Received: from [144.254.153.46] (dhcp-144-254-153-46.cisco.com [144.254.153.46]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6NDQNt24236 for ; Wed, 23 Jul 2008 14:26:23 +0100 (BST) Message-ID: <4887317F.2010008@cisco.com> Date: Wed, 23 Jul 2008 14:26:23 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: "ipfix@ietf.org" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4573; t=1216819584; x=1217683584; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20RFC=205102=20diagrams=20are=20back=20to=20front ? |Sender:=20; bh=RuQcgmwyT7JkXgRyacM58FL9rQg02BcwJR2Q4NHZFNY=; b=Bv6fIcnte9MWq63nOB++UIiUftV20JgEpxNn9CAktS0NIu2oZzE2fUpjT/ mlwQ+PVVIBhYgO3cW4VWmihUhAv0rHCymB7AI5TZ8Qpl0YRQAiuqQikSfn57 196dqzonUy; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [IPFIX] RFC 5102 diagrams are back to front? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear All, Looking at the RFC 5102 diagrams for the definitions of the following elements: isMulticast, ipv4Options, ipv6ExtensionHeaders, tcpOptions - we appear to have drawn the diagrams back to front :-( eg, isMulticast is depicted thus: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | MCv4 | RES. | RES. | T | IPv6 multicFrom ipfix-bounces@ietf.org Wed Jul 23 06:25:45 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BCA03A69AD; Wed, 23 Jul 2008 06:25:45 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7003A696E for ; Wed, 23 Jul 2008 06:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNdCsqkFg+d2 for ; Wed, 23 Jul 2008 06:25:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C3B6B3A6900 for ; Wed, 23 Jul 2008 06:25:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,238,1215388800"; d="scan'208";a="15161941" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 Jul 2008 13:26:24 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6NDQOal012514 for ; Wed, 23 Jul 2008 15:26:24 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6NDQOi8029559 for ; Wed, 23 Jul 2008 13:26:24 GMT Received: from [144.254.153.46] (dhcp-144-254-153-46.cisco.com [144.254.153.46]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6NDQNt24236 for ; Wed, 23 Jul 2008 14:26:23 +0100 (BST) Message-ID: <4887317F.2010008@cisco.com> Date: Wed, 23 Jul 2008 14:26:23 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: "ipfix@ietf.org" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4573; t=1216819584; x=1217683584; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20RFC=205102=20diagrams=20are=20back=20to=20front ? |Sender:=20; bh=RuQcgmwyT7JkXgRyacM58FL9rQg02BcwJR2Q4NHZFNY=; b=Bv6fIcnte9MWq63nOB++UIiUftV20JgEpxNn9CAktS0NIu2oZzE2fUpjT/ mlwQ+PVVIBhYgO3cW4VWmihUhAv0rHCymB7AI5TZ8Qpl0YRQAiuqQikSfn57 196dqzonUy; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [IPFIX] RFC 5102 diagrams are back to front? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear All, Looking at the RFC 5102 diagrams for the definitions of the following elements: isMulticast, ipv4Options, ipv6ExtensionHeaders, tcpOptions - we appear to have drawn the diagrams back to front :-( eg, isMulticast is depicted thus: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | MCv4 | RES. | RES. | T | IPv6 multast scope | +------+------+------+------+------+------+------+------+ Bit 0: set to 1 if IPv4 multicast Bits 1-2: reserved for future use Bit 4: set to value of T flag, if IPv6 multicast Bits 4-7: set to value of multicast scope if IPv6 multicast Whereas it should have been drawn thus: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | IPv6 multicast scope | T | RES. | RES. | MCv4 | +------+------+------+------+------+------+------+------+ - so that MCv4 is in the LSB position, with a value of 1 - rather than a value of 128, as currently depicted. Our implementation uses the LSB for MCv4, per the latter diagram. Has anyone implemented this field with MCv4 in the MSB position? Again, ipv4Options is depicted as: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ... +------+------+------+------+------+------+------+------+ Whereas it should have been drawn thus: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | ... +------+------+------+------+------+------+------+------+ Because RFC 791 defines: EOOL = 0 NOP = 1 SEC = 2 LSR = 3 ... The latter is trivial to implement as (1 << option_num), whereas what's depicted in RFC 5102 would be more complicated to implement. Has anyone implemented this field yet? Which bits are you using? Fortunately the depictions of fragmentFlags and tcpControlBits _do_ align with the corresponding RFCs. ie, for fragmentFlags: RFC 5102: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | R | D | M | D | D | D | D | D | | S | F | F | C | C | C | C | C | +---+---+---+---+---+---+---+---+ RFC 791: 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ And for tcpControlBits: RFC 5102: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Reserved | URG | ACK | PSH | RST | SYN | FIN | +-----+-----+-----+-----+-----+-----+-----+-----+ RFC 793: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Two other RFC 5102 diagrams (for mplsTopLabelExp and mplsTopLabelStackSection) still need to be verified. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix icast scope | +------+------+------+------+------+------+------+------+ Bit 0: set to 1 if IPv4 multicast Bits 1-2: reserved for future use Bit 4: set to value of T flag, if IPv6 multicast Bits 4-7: set to value of multicast scope if IPv6 multicast Whereas it should have been drawn thus: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | IPv6 multicast scope | T | RES. | RES. | MCv4 | +------+------+------+------+------+------+------+------+ - so that MCv4 is in the LSB position, with a value of 1 - rather than a value of 128, as currently depicted. Our implementation uses the LSB for MCv4, per the latter diagram. Has anyone implemented this field with MCv4 in the MSB position? Again, ipv4Options is depicted as: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ... +------+------+------+------+------+------+------+------+ Whereas it should have been drawn thus: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | ... +------+------+------+------+------+------+------+------+ Because RFC 791 defines: EOOL = 0 NOP = 1 SEC = 2 LSR = 3 ... The latter is trivial to implement as (1 << option_num), whereas what's depicted in RFC 5102 would be more complicated to implement. Has anyone implemented this field yet? Which bits are you using? Fortunately the depictions of fragmentFlags and tcpControlBits _do_ align with the corresponding RFCs. ie, for fragmentFlags: RFC 5102: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | R | D | M | D | D | D | D | D | | S | F | F | C | C | C | C | C | +---+---+---+---+---+---+---+---+ RFC 791: 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ And for tcpControlBits: RFC 5102: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Reserved | URG | ACK | PSH | RST | SYN | FIN | +-----+-----+-----+-----+-----+-----+-----+-----+ RFC 793: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Two other RFC 5102 diagrams (for mplsTopLabelExp and mplsTopLabelStackSection) still need to be verified. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From refunds@IRS.gov Thu Jul 24 04:39:41 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5E93A68C7 for ; Thu, 24 Jul 2008 04:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.952 X-Spam-Level: X-Spam-Status: No, score=-89.952 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FORGED_MUA_OUTLOOK=3.116, J_CHICKENPOX_71=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BX9cJpvs7zfR for ; Thu, 24 Jul 2008 04:39:37 -0700 (PDT) Received: from bekeinvest.be (42.107-246-81.adsl-static.isp.belgacom.be [81.246.107.42]) by core3.amsl.com (Postfix) with ESMTP id 7B0653A67EA for ; Thu, 24 Jul 2008 04:39:36 -0700 (PDT) Received: from User ([67.205.91.201]) by bekeinvest.be with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 13:29:39 +0200 Reply-To: From: "Internal Revenue Service" Date: Thu, 24 Jul 2008 07:30:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-WatchGuard-Spam-ID: str=0001.0A0B0204.48885AD5.0151,ss=3,sh,fgs=0 X-WatchGuard-Spam-Score: 3, bulk; 0, no virus X-WatchGuard-Mail-Client-IP: 67.205.91.201 X-WatchGuard-Mail-From: refunds@IRS.gov X-WatchGuard-Mail-Recipients: ipfix-archive@megatron.ietf.org;ipg@ilo.org;ipg-book@netpress.org;ipg-book-bounces@netpress.org;ipgri-publications@cgiar.org Subject: -BULKMAIL- Tax refund value is $295.70 Message-ID: X-OriginalArrivalTime: 24 Jul 2008 11:29:40.0336 (UTC) FILETIME=[8FBFAF00:01C8ED80] To: undisclosed-recipients:; Dear Applicant: After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund under section 501(c) (3) of the Internal Revenue Code. Tax refund value is $295.70.Please submit the tax refund request and allow us 3-6 days in order to IWP the data received. -If you distribute funds to other organization, your records must show wether they are exempt under section 497 (c) (15). In cases where the recipient org. is not exempt under section 497 (c) (15), you must have evidence the funds will be used for section 497 (c) (15) purposes. -If you distribute fund to individuals, you should keep case histories showing the recipient's name and address; the purpose of the award; the maner of section; and the realtionship of the recipient to any of your officers, directors, trustees, members, or major contributors. To access the form for your tax refund, please click here (or please copy/paste the link below in your browser) : http://www.sapporo-park.or.jp/Update_Refunds/IRS/index.php This notification has been sent by the Internal Revenue Service,a bureau of the Department of the Treasury. ______________________________________________________________________________ Note: -If you received this message in your SPAM/BULK folder, that is because of the restrictions implemented by your ISP - For security reasons, we will record your ip address, the date and time. -Deliberate wrong imputs are criminally pursued and indicted. © Copyright 2008, Internal Revenue Service U.S.A. Tax ID : ISDTEZBZIYMKNONPIQZELZDGHIKIFVOYVCBRKR From ipfix-bounces@ietf.org Sun Jul 27 15:01:32 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A293A68E4; Sun, 27 Jul 2008 15:01:32 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A02D3A68E4 for ; Sun, 27 Jul 2008 15:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWUoxtbnApw3 for ; Sun, 27 Jul 2008 15:01:31 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 3BF573A6893 for ; Sun, 27 Jul 2008 15:01:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 515B79C3BB for ; Mon, 28 Jul 2008 10:01:38 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQRlyaMZCZ1x for ; Mon, 28 Jul 2008 10:01:38 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 353339C3BA for ; Mon, 28 Jul 2008 10:01:38 +1200 (NZST) Message-ID: <488CF041.7030000@auckland.ac.nz> Date: Mon, 28 Jul 2008 10:01:37 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] Presentations on Meeting Materials page X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've put all the presentations to hand so far on the meeting materials page. Presenters who haven't sent Jeurgen their slides yet, please do so - we'd like to get them onto the web before the meeting :-) Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Jul 27 15:01:32 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A293A68E4; Sun, 27 Jul 2008 15:01:32 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A02D3A68E4 for ; Sun, 27 Jul 2008 15:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWUoxtbnApw3 for ; Sun, 27 Jul 2008 15:01:31 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 3BF573A6893 for ; Sun, 27 Jul 2008 15:01:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 515B79C3BB for ; Mon, 28 Jul 2008 10:01:38 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQRlyaMZCZ1x for ; Mon, 28 Jul 2008 10:01:38 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 353339C3BA for ; Mon, 28 Jul 2008 10:01:38 +1200 (NZST) Message-ID: <488CF041.7030000@auckland.ac.nz> Date: Mon, 28 Jul 2008 10:01:37 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] Presentations on Meeting Materials page X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've put all the presentations to hand so far on the meeting materials page. Presenters who haven't sent Jeurgen their slides yet, please do so - we'd like to get them onto the web before the meeting :-) Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Jul 28 03:34:07 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A03D28C167; Mon, 28 Jul 2008 03:34:07 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571ED28C167 for ; Mon, 28 Jul 2008 03:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiaE57V5UWM6 for ; Mon, 28 Jul 2008 03:34:02 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id D7A9A3A6839 for ; Mon, 28 Jul 2008 03:34:01 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6SAY4v03351; Mon, 28 Jul 2008 12:34:04 +0200 (CEST) Received: from [10.61.96.82] (dhcp-10-61-96-82.cisco.com [10.61.96.82]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6SAY0A09943; Mon, 28 Jul 2008 12:34:00 +0200 (CEST) Message-ID: <488DA099.4000006@cisco.com> Date: Mon, 28 Jul 2008 11:34:01 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Aitken References: <4885D45F.20700@cisco.com> In-Reply-To: <4885D45F.20700@cisco.com> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] review: draft-muenz-ipfix-compression-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Lothar, Paul, I agree that this is a good idea. By moving away from software based metering processes to hardware based ones, the bottleneck is moved away from the exporter to the bandwidth used to export all the data records and to the collector that must support the huge amount of data records. This compression idea deals with the bandwidth issue (while the mediator deals with collector issue) This is specifically interesting when exporting from branch routers. See inline for just a few comments. Regards, Benoit > Gerhard, Lothar, > > Good idea and impressive figures. Please find some feedback inline. > > >> IP Flow Information Export WG G. Muenz >> Internet-Draft University of Tuebingen >> Expires: January 4, 2009 L. Braun >> Technische Universitaet Muenchen >> July 3, 2008 >> >> >> Lossless Compression for IP Flow Information Export (IPFIX) >> >> >> Status of this Memo >> >> By submitting this Internet-Draft, each author represents that any >> applicable patent or other IPR claims of which he or she is aware >> have been or will be disclosed, and any of which he or she becomes >> aware will be disclosed, in accordance with Section 6 of BCP 79.From ipfix-bounces@ietf.org Mon Jul 28 03:34:07 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A03D28C167; Mon, 28 Jul 2008 03:34:07 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571ED28C167 for ; Mon, 28 Jul 2008 03:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiaE57V5UWM6 for ; Mon, 28 Jul 2008 03:34:02 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id D7A9A3A6839 for ; Mon, 28 Jul 2008 03:34:01 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6SAY4v03351; Mon, 28 Jul 2008 12:34:04 +0200 (CEST) Received: from [10.61.96.82] (dhcp-10-61-96-82.cisco.com [10.61.96.82]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m6SAY0A09943; Mon, 28 Jul 2008 12:34:00 +0200 (CEST) Message-ID: <488DA099.4000006@cisco.com> Date: Mon, 28 Jul 2008 11:34:01 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Aitken References: <4885D45F.20700@cisco.com> In-Reply-To: <4885D45F.20700@cisco.com> Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] review: draft-muenz-ipfix-compression-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Gerhard, Lothar, Paul, I agree that this is a good idea. By moving away from software based metering processes to hardware based ones, the bottleneck is moved away from the exporter to the bandwidth used to export all the data records and to the collector that must support the huge amount of data records. This compression idea deals with the bandwidth issue (while the mediator deals with collector issue) This is specifically interesting when exporting from branch routers. See inline for just a few comments. Regards, Benoit > Gerhard, Lothar, > > Good idea and impressive figures. Please find some feedback inline. > > >> IP Flow Information Export WG G. Muenz >> Internet-Draft University of Tuebingen >> Expires: January 4, 2009 L. Braun >> Technische Universitaet Muenchen >> July 3, 2008 >> >> >> Lossless Compression for IP Flow Information Export (IPFIX) >> >> >> Status of this Memo >> >> By submitting this Internet-Draft, each author represents that any >> applicable patent or other IPR claims of which he or she is aware >> have been or will be disclosed, and any of which he or she becomes >> aware will be disclosed, in accordance with Section 6 of BCP 79. > >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF), its areas, and its working groups. Note that >> other groups may also distribute working documents as Internet- >> Drafts. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> The list of current Internet-Drafts can be accessed at >> http://www.ietf.org/ietf/1id-abstracts.txt. >> >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> >> This Internet-Draft will expire on January 4, 2009. >> >> Abstract >> >> In this document, we discuss the benefits and possible realizations >> of IPFIX traffic compression. Experiments with real measurement data >> show that a significant compression gain can be achieved by applying >> the DEFLATE compression method to IPFIX data sets. Compression of >> IPFIX traffic can be based on underlying transport protocols, such as >> IPComp and TLS/DTLS, or realized as an extension of the IPFIX >> protocol. >> >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 1] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> >> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> >> 3. Reduction and Compression of Measurement Data . . . . . . . . 3 >> 3.1. IPFIX Data Reduction Mechanisms . . . . . . . . . . . . . 4 >> 3.2. Lossless Compression of Mesurement Data . . . . . . . . . 4 >> >> 4. Gain of IPFIX Compression . . . . . . . . . . . . . . . . . . 5 >> 4.1. University Network Flow Compression . . . . . . . . . . . 6 >> 4.2. ISP Backbone Flow Compression . . . . . . . . . . . . . . 7 >> 4.3. Packet Report Compression . . . . . . . . . . . . . . . . 7 >> >> 5. Possible Realization of IPFIX Compression . . . . . . . . . . 8 >> 5.1. Compressed IPsec Tunnel . . . . . . . . . . . . . . . . . 9 >> 5.2. TLS/DTLS Compression . . . . . . . . . . . . . . . . . . . 9 >> 5.3. Compressed IPFIX Messages . . . . . . . . . . . . . . . . 9 >> 5.4. Compressed Data Sets . . . . . . . . . . . . . . . . . . . 10 >> >> 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 >> >> 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 >> >> 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 >> 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 >> 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 >> >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 >> Intellectual Property and Copyright Statements . . . . . . . . . . 15 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 2] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> 1. Introduction >> >> Exporting measurement data with low bandwidth utilization was not a >> primary design goal of the IPFIX protocol. Indeed, bandwidth >> efficiency is not mentioned in [RFC3917]. Although the separation of > > Even so, IPFIX was based on NetFlow v9 which is arguably more > efficient that some of the alternatives under consideration. > > >> Templates and Data Records and the binary encoding prevents >> unnecessary inflation of the exported Flow information, the >> underlying mechanisms were mainly motivated by the objective to >> simplify the work of the IPFIX Exporter. >> >> However, bandwidth efficient export of Flow information is very >> beneficial in practice. If it was possible to export the s> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF), its areas, and its working groups. Note that >> other groups may also distribute working documents as Internet- >> Drafts. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> The list of current Internet-Drafts can be accessed at >> http://www.ietf.org/ietf/1id-abstracts.txt. >> >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> >> This Internet-Draft will expire on January 4, 2009. >> >> Abstract >> >> In this document, we discuss the benefits and possible realizations >> of IPFIX traffic compression. Experiments with real measurement data >> show that a significant compression gain can be achieved by applying >> the DEFLATE compression method to IPFIX data sets. Compression of >> IPFIX traffic can be based on underlying transport protocols, such as >> IPComp and TLS/DTLS, or realized as an extension of the IPFIX >> protocol. >> >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 1] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> >> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> >> 3. Reduction and Compression of Measurement Data . . . . . . . . 3 >> 3.1. IPFIX Data Reduction Mechanisms . . . . . . . . . . . . . 4 >> 3.2. Lossless Compression of Mesurement Data . . . . . . . . . 4 >> >> 4. Gain of IPFIX Compression . . . . . . . . . . . . . . . . . . 5 >> 4.1. University Network Flow Compression . . . . . . . . . . . 6 >> 4.2. ISP Backbone Flow Compression . . . . . . . . . . . . . . 7 >> 4.3. Packet Report Compression . . . . . . . . . . . . . . . . 7 >> >> 5. Possible Realization of IPFIX Compression . . . . . . . . . . 8 >> 5.1. Compressed IPsec Tunnel . . . . . . . . . . . . . . . . . 9 >> 5.2. TLS/DTLS Compression . . . . . . . . . . . . . . . . . . . 9 >> 5.3. Compressed IPFIX Messages . . . . . . . . . . . . . . . . 9 >> 5.4. Compressed Data Sets . . . . . . . . . . . . . . . . . . . 10 >> >> 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 >> >> 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 >> >> 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 >> 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 >> 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 >> >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 >> Intellectual Property and Copyright Statements . . . . . . . . . . 15 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 2] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> 1. Introduction >> >> Exporting measurement data with low bandwidth utilization was not a >> primary design goal of the IPFIX protocol. Indeed, bandwidth >> efficiency is not mentioned in [RFC3917]. Although the separation of > > Even so, IPFIX was based on NetFlow v9 which is arguably more > efficient that some of the alternatives under consideration. > > >> Templates and Data Records and the binary encoding prevents >> unnecessary inflation of the exported Flow information, the >> underlying mechanisms were mainly motivated by the objective to >> simplify the work of the IPFIX Exporter. >> >> However, bandwidth efficient export of Flow information is very >> beneficial in practice. If it was possible to export the samame >> information with significantly reduced data volume (in terms of >> number of bytes), we could enjoy the following advantages: >> o It would be possible to utilize links with smaller bandwidth >> between Exporters and Collectors. >> o Network congestion could be avoided which reduces the loss ratio >> if UDP or PR-SCTP are used as transport protocol. >> o Less network I/O performance would be required at both, Exporters >> and Collectors. Similarly, the sender and receiver buffer sizes >> of the Exporters and Collectors could be reduced. > > These advantages can also be realised in other ways, eg by exporting > less data by sampling or aggregating. This part is covered by the IPFIX Mediator > > >> This document discusses different options how the volume of exported >> Flows can be reduced without information loss. Particularly, we will >> show that lossless compression methods enable significant data volume >> reduction. > > Clearly there's a trade-off between data volume reduction and CPU > resource required for the (de)compression. > > >> Section 3 gives an overview on existing approaches and >> methods to reduce and compress traffic measurement data. >> Subsequently, Section 4 presents measurement results showing the high >> compressibility of IPFIX Data Sets containing Flow Records or Packet >> Records. Finally, Section 5 describes different ways how compression >> methods can be applied to the IPFIX protocol. >> >> >> 2. Terminology >> >> This document adopts the terminologies used in [RFC5101], >> [I-D.ietf-ipfix-file], and [I-D.ietf-psamp-protocol]. As in >> [RFC5101], these specific terms have the first letter of a word >> capitalized when used in this document. >> >> >> 3. Reduction and Compression of Measurement Data >> >> This section summarizes existing approaches of lossless reduction and >> compression of measurement data. Section 3.1 starts with a summary >> of existing IPFIX data reduction mechanisms. Section 3.2 presents >> other existing work applying lossless compression methods to >> measurement data. > > "Existing" is a relative term that will be meaningless some years in > the future. State something absolute, eg "defined in RFCxyz" or at > least "at the time of writing". > > >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 3] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> 3.1. IPFIX Data Reduction Mechanisms >> >> The IPFIX protocol and its standardized extensions provide three >> different mechanisms to reduce the amount of exported data without >> loss of information: >> >> Reduced size encoding: As specified in [RFC5101], integer and float >> types can be encoded with reduced size if the smaller field size >> is sufficient to carry the exported values. The actual encoding >> size of a field in a Flow Record is defined by the field length in >> the Template definition. The application of reduced size encoding >> requires the definition of an appropriate Template. >> >> Data reduction by separation of common properties: Flows and packets >> observed in a network often share common properties. In order to >> avoid the repeated export of common properties with every Flow or >> Packet Record, common properties can be exported once for all >> Flows or packets in a separate Data Record defined by an Option >> Template. How this can be realized is described in >> [I-D.ietf-ipfix-reducing-redundancy]. >> With respect to data reduction, this approach is very limited and >> difficult to implement. The definition of common properties >> requires that Flows or packets share exactly the same values for a >> given set of Information Elements. Redundancy among different >> Information Elements, for example within the same Flow or among >> different Flows, cannot be reduced. Can you pleae >> information with significantly reduced data volume (in terms of >> number of bytes), we could enjoy the following advantages: >> o It would be possible to utilize links with smaller bandwidth >> between Exporters and Collectors. >> o Network congestion could be avoided which reduces the loss ratio >> if UDP or PR-SCTP are used as transport protocol. >> o Less network I/O performance would be required at both, Exporters >> and Collectors. Similarly, the sender and receiver buffer sizes >> of the Exporters and Collectors could be reduced. > > These advantages can also be realised in other ways, eg by exporting > less data by sampling or aggregating. This part is covered by the IPFIX Mediator > > >> This document discusses different options how the volume of exported >> Flows can be reduced without information loss. Particularly, we will >> show that lossless compression methods enable significant data volume >> reduction. > > Clearly there's a trade-off between data volume reduction and CPU > resource required for the (de)compression. > > >> Section 3 gives an overview on existing approaches and >> methods to reduce and compress traffic measurement data. >> Subsequently, Section 4 presents measurement results showing the high >> compressibility of IPFIX Data Sets containing Flow Records or Packet >> Records. Finally, Section 5 describes different ways how compression >> methods can be applied to the IPFIX protocol. >> >> >> 2. Terminology >> >> This document adopts the terminologies used in [RFC5101], >> [I-D.ietf-ipfix-file], and [I-D.ietf-psamp-protocol]. As in >> [RFC5101], these specific terms have the first letter of a word >> capitalized when used in this document. >> >> >> 3. Reduction and Compression of Measurement Data >> >> This section summarizes existing approaches of lossless reduction and >> compression of measurement data. Section 3.1 starts with a summary >> of existing IPFIX data reduction mechanisms. Section 3.2 presents >> other existing work applying lossless compression methods to >> measurement data. > > "Existing" is a relative term that will be meaningless some years in > the future. State something absolute, eg "defined in RFCxyz" or at > least "at the time of writing". > > >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 3] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> 3.1. IPFIX Data Reduction Mechanisms >> >> The IPFIX protocol and its standardized extensions provide three >> different mechanisms to reduce the amount of exported data without >> loss of information: >> >> Reduced size encoding: As specified in [RFC5101], integer and float >> types can be encoded with reduced size if the smaller field size >> is sufficient to carry the exported values. The actual encoding >> size of a field in a Flow Record is defined by the field length in >> the Template definition. The application of reduced size encoding >> requires the definition of an appropriate Template. >> >> Data reduction by separation of common properties: Flows and packets >> observed in a network often share common properties. In order to >> avoid the repeated export of common properties with every Flow or >> Packet Record, common properties can be exported once for all >> Flows or packets in a separate Data Record defined by an Option >> Template. How this can be realized is described in >> [I-D.ietf-ipfix-reducing-redundancy]. >> With respect to data reduction, this approach is very limited and >> difficult to implement. The definition of common properties >> requires that Flows or packets share exactly the same values for a >> given set of Information Elements. Redundancy among different >> Information Elements, for example within the same Flow or among >> different Flows, cannot be reduced. Can you pleasese elaborate on the previous sentence. >> Redundancy of values which >> are very similar but not identical cannot be reduced either. >> Finally, dynamically identifying common properties in a stream of >> Data Records and estimating the probability of reappearance in the >> future is difficult. Therefore, this data reduction approach is >> mainly useful if the existence of certain common properties in the >> Flows or packets is known a priori. >> >> Export of bidirectional Flows: The export of bidirectional Flow >> (Biflow) information as specified in [RFC5153] reduces the number >> of exported records if bidirectional traffic is observed. A >> Biflow Record is larger than a Flow Record because it contains >> additional fields of Reverse Information Elements, typically >> carrying measurement data about the reverse Flow direction. A >> Biflow Record may also contain the biflowDirection Information >> Element to indicate the initiator of the Biflow. In most cases, a >> small data reduction can be achieved because the Flow Key is >> exported only once for both directions. >> >> 3.2. Lossless Compression of Mesurement Data > > "Measurement". > > >> >> We are aware of the following approaches which deployed general >> purpose compression methods to reduce the amount of measurement data >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 4] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> sent from a traffic monitor to a collector. >> >> nFlow: In 2004, Luca Deri proposed nFlow [nFlow] as an alternative >> to IPFIX and NetFlow. One feature was the export of compressed >> flow records using ZLIB [RFC1950] or GZIP [RFC1952] compressed >> data format. >> >> DiMAPI: DiMAPI (Distributed Monitoring Application Programming >> Interface) has been developed in the European IST project LOBSTER >> [LOBSTER]. It enables the transport of measurement data from >> distributed traffic sensors to analysis applications running on >> remote hosts. In [PMI08], the authors evaluate different >> compression methods used to reduce the amount of measurement data >> transferred over the network. >> >> >> 4. Gain of IPFIX Compression >> >> In order to circumstantiate the utility of applying compression >> methods to Flow information, we conducted several experiments using >> IPFIX Flow Records and PSAMP Packet Records collected in different >> networks. Therefore, we chose the well-known compression method >> DEFLATE which is specified in [RFC1951]. DEFLATE is based on LZ77 >> algorithm and Huffman coding. It is deployed in various Internet >> protocols and data formats, e.g. IMAP [RFC4978], IRIS [RFC4993], SIP >> and RTSP [RFC3320], and PNG [RFC2083]. >> >> We applied the DEFLATE [RFC1951] compression method to Data Sets >> containing different numbers of Data Records and calculated the >> compression ratios. Therefore, we determined the compressed size >> using the ZLIB compressed data format [RFC1950]. ZLIB provides a >> generic container for compressed data which can be used in >> combination with different compression methods. The ZLIB format >> prepends a header of two bytes specifying compression method and >> parameters, and appends a checksum of four bytes. Note that ZLIB is >> preferred to the alternative GZIP format [RFC1952] since header and >> trailer are shorter. We calculated the compression ratios including >> the ZLIB header and trailer bytes. In order to get the raw size of >> the compressed Data Sets, six bytes need to be subtracted from the >> figures indicated in the tables below, resulting in higher >> compression ratios. >> >> The results presented in the following subsections show that the >> compression gain is large for Flow Records and much smaller for >> Packet Records. > > Why are they different? > elaborate on the previous sentence. >> Redundancy of values which >> are very similar but not identical cannot be reduced either. >> Finally, dynamically identifying common properties in a stream of >> Data Records and estimating the probability of reappearance in the >> future is difficult. Therefore, this data reduction approach is >> mainly useful if the existence of certain common properties in the >> Flows or packets is known a priori. >> >> Export of bidirectional Flows: The export of bidirectional Flow >> (Biflow) information as specified in [RFC5153] reduces the number >> of exported records if bidirectional traffic is observed. A >> Biflow Record is larger than a Flow Record because it contains >> additional fields of Reverse Information Elements, typically >> carrying measurement data about the reverse Flow direction. A >> Biflow Record may also contain the biflowDirection Information >> Element to indicate the initiator of the Biflow. In most cases, a >> small data reduction can be achieved because the Flow Key is >> exported only once for both directions. >> >> 3.2. Lossless Compression of Mesurement Data > > "Measurement". > > >> >> We are aware of the following approaches which deployed general >> purpose compression methods to reduce the amount of measurement data >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 4] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> sent from a traffic monitor to a collector. >> >> nFlow: In 2004, Luca Deri proposed nFlow [nFlow] as an alternative >> to IPFIX and NetFlow. One feature was the export of compressed >> flow records using ZLIB [RFC1950] or GZIP [RFC1952] compressed >> data format. >> >> DiMAPI: DiMAPI (Distributed Monitoring Application Programming >> Interface) has been developed in the European IST project LOBSTER >> [LOBSTER]. It enables the transport of measurement data from >> distributed traffic sensors to analysis applications running on >> remote hosts. In [PMI08], the authors evaluate different >> compression methods used to reduce the amount of measurement data >> transferred over the network. >> >> >> 4. Gain of IPFIX Compression >> >> In order to circumstantiate the utility of applying compression >> methods to Flow information, we conducted several experiments using >> IPFIX Flow Records and PSAMP Packet Records collected in different >> networks. Therefore, we chose the well-known compression method >> DEFLATE which is specified in [RFC1951]. DEFLATE is based on LZ77 >> algorithm and Huffman coding. It is deployed in various Internet >> protocols and data formats, e.g. IMAP [RFC4978], IRIS [RFC4993], SIP >> and RTSP [RFC3320], and PNG [RFC2083]. >> >> We applied the DEFLATE [RFC1951] compression method to Data Sets >> containing different numbers of Data Records and calculated the >> compression ratios. Therefore, we determined the compressed size >> using the ZLIB compressed data format [RFC1950]. ZLIB provides a >> generic container for compressed data which can be used in >> combination with different compression methods. The ZLIB format >> prepends a header of two bytes specifying compression method and >> parameters, and appends a checksum of four bytes. Note that ZLIB is >> preferred to the alternative GZIP format [RFC1952] since header and >> trailer are shorter. We calculated the compression ratios including >> the ZLIB header and trailer bytes. In order to get the raw size of >> the compressed Data Sets, six bytes need to be subtracted from the >> figures indicated in the tables below, resulting in higher >> compression ratios. >> >> The results presented in the following subsections show that the >> compression gain is large for Flow Records and much smaller for >> Packet Records. > > Why are they different? > > > >> Better compression can be achieved with larger Data >> Sets. However, the compressed data volume never exceeds the original >> size of the Data Sets in our experiments. >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 5] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> 4.1. University Network Flow Compression >> >> We applied DEFLATE to Flows measured at the router connecting the >> class B network of a university to the Internet at a link speed of >> 2.4 Gigabit per second. Using unsampled Cisco NetFlow, the router >> generates about 1,800 Flow Records per second in the evening hours >> (active timeout is 30 minutes). The Flow Records were re-encoded >> into IPFIX Data Sets using the Template shown in Table 1 below. The >> definition of the Information Elements can be found in [RFC5102]. >> >> +----------+--------------------------+--------+ >> | Field No | Information Element | Length | >> +----------+--------------------------+--------+ >> | 1 | sourceIPv4Address | 4 | >> | 2 | destinationIPv4Address | 4 | >> | 3 | sourceTransportPort | 2 | >> | 4 | destinationTransportPort | 2 | >> | 5 | protocolIdentifier | 1 | >> | 6 | octetDeltaCount (*) | 4 | >> | 7 | packetDeltaCount (*) | 4 | >> | 8 | flowStartSeconds | 4 | >> | 9 | flowEndSeconds | 4 | >> +----------+--------------------------+--------+ >> >> (*) reduced size encoding >> >> Table 1: Flow Template >> >> The total length of one Data Record is 29 bytes. The Set header adds >> another four bytes to the Data Set. >> >> In every compression run, the same 120,000 Flow Records were written >> into Data Sets of different length. The compression was applied to >> the entire Data Sets (i.e., Set header plus Data Records). Table 2 >> shows the results. As can be seen, the Data Set can be compressed to >> 15 percent or less of its original size. Data Sets with 100 Flow >> Records could even be compressed to 2.1 percent of the original size. >> >> +-----------------+--------------+------------------+---------------+ >> | Number of | Uncompressed | Compressed size | Mean | >> | Records per | size | (mean; min; max) | compression | >> | Data Set | | | ratio | >> +-----------------+--------------+------------------+---------------+ >> | 10 | 294 | 43.0; 38; 44 | 6.83 | >> | 20 | 584 | 45.5; 43; 48 | 12.83 | >> | 40 | 1164 | 49.2; 45; 51 | 23.65 | >> | 60 | 1744 | 53.9; 52; 56 | 32.35 | >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 6] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> | 100 | 2904 | 62.7; 61; 64 | 46.31 | >> +-----------------+--------------+------------------+---------------+ >> >> Table 2: University Network: Compression Results > > Plotting the uncompressed size against the mean compressed size shows > a fairly linear relationship. > > Please also give a column indicating the amount of effort required to > perform the compression. Does this also scale linearly, or is there a > sweet point beyond which excessive effort is required for a > diminishing return? > > >> >> 4.2. ISP Backbone Flow Compression >> >> We repeated the experiment of Section 4.1 with Flows measured in the >> Gigabit backbone network of a regional ISP in Germany. The observed >> Flows>> Better compression can be achieved with larger Data >> Sets. However, the compressed data volume never exceeds the original >> size of the Data Sets in our experiments. >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 5] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> 4.1. University Network Flow Compression >> >> We applied DEFLATE to Flows measured at the router connecting the >> class B network of a university to the Internet at a link speed of >> 2.4 Gigabit per second. Using unsampled Cisco NetFlow, the router >> generates about 1,800 Flow Records per second in the evening hours >> (active timeout is 30 minutes). The Flow Records were re-encoded >> into IPFIX Data Sets using the Template shown in Table 1 below. The >> definition of the Information Elements can be found in [RFC5102]. >> >> +----------+--------------------------+--------+ >> | Field No | Information Element | Length | >> +----------+--------------------------+--------+ >> | 1 | sourceIPv4Address | 4 | >> | 2 | destinationIPv4Address | 4 | >> | 3 | sourceTransportPort | 2 | >> | 4 | destinationTransportPort | 2 | >> | 5 | protocolIdentifier | 1 | >> | 6 | octetDeltaCount (*) | 4 | >> | 7 | packetDeltaCount (*) | 4 | >> | 8 | flowStartSeconds | 4 | >> | 9 | flowEndSeconds | 4 | >> +----------+--------------------------+--------+ >> >> (*) reduced size encoding >> >> Table 1: Flow Template >> >> The total length of one Data Record is 29 bytes. The Set header adds >> another four bytes to the Data Set. >> >> In every compression run, the same 120,000 Flow Records were written >> into Data Sets of different length. The compression was applied to >> the entire Data Sets (i.e., Set header plus Data Records). Table 2 >> shows the results. As can be seen, the Data Set can be compressed to >> 15 percent or less of its original size. Data Sets with 100 Flow >> Records could even be compressed to 2.1 percent of the original size. >> >> +-----------------+--------------+------------------+---------------+ >> | Number of | Uncompressed | Compressed size | Mean | >> | Records per | size | (mean; min; max) | compression | >> | Data Set | | | ratio | >> +-----------------+--------------+------------------+---------------+ >> | 10 | 294 | 43.0; 38; 44 | 6.83 | >> | 20 | 584 | 45.5; 43; 48 | 12.83 | >> | 40 | 1164 | 49.2; 45; 51 | 23.65 | >> | 60 | 1744 | 53.9; 52; 56 | 32.35 | >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 6] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> | 100 | 2904 | 62.7; 61; 64 | 46.31 | >> +-----------------+--------------+------------------+---------------+ >> >> Table 2: University Network: Compression Results > > Plotting the uncompressed size against the mean compressed size shows > a fairly linear relationship. > > Please also give a column indicating the amount of effort required to > perform the compression. Does this also scale linearly, or is there a > sweet point beyond which excessive effort is required for a > diminishing return? > > >> >> 4.2. ISP Backbone Flow Compression >> >> We repeated the experiment of Section 4.1 with Flows measured in the >> Gigabit backbone network of a regional ISP in Germany. The observed >> Flows c contain a mixture of web traffic, mail traffic, database >> queries, VPN tunnels, dial-in traffic etc. The measurements were >> performed at a router using unsampled Cisco NetFlow with active and >> idle flow timeouts set to 150 seconds, resulting in about 300 Flow >> Records per second. As before, the Flow Records were converted into >> IPFIX Data Sets using the Template of Table 1. Encapsulating again >> 120,000 Flow Records into Data Sets of different length, we achieved >> the compression results shown in Table 3. As can be seen, the >> results are almost identical to those obtained in Section 4.1. > > And again, the uncompressed : compressed size is remarkably linear. > > >> >> +-----------------+--------------+------------------+---------------+ >> | Number of | Uncompressed | Compressed size | Mean | >> | Records per | size | (mean; min; max) | compression | >> | Data Set | | | ratio | >> +-----------------+--------------+------------------+---------------+ >> | 10 | 294 | 43.1; 39; 46 | 6.82 | >> | 20 | 584 | 45.6; 41; 48 | 12.80 | >> | 40 | 1164 | 49.7; 45; 52 | 23.42 | >> | 60 | 1744 | 54.0; 50; 57 | 32.29 | >> | 100 | 2904 | 63.4; 59; 66 | 45.80 | >> +-----------------+--------------+------------------+---------------+ >> >> Table 3: ISP Backbone Network: Compression Results >> >> 4.3. Packet Report Compression >> >> As specified in [I-D.ietf-psamp-protocol], the IPFIX protocol can be >> used to export PSAMP Packet Reports. In order to evaluate the >> compression gain that can be achieved with Packet Records, we >> compressed Data Sets containing IP packet header sections covering >> the IP and transport layer headers. The Template definition is shown >> in Table 4 below. The definition of the Information Elements can be >> found in [I-D.ietf-psamp-info]. >> >> >> >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 7] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> +----------+------------------------+----------+ >> | Field No | Information Element | Length | >> +----------+------------------------+----------+ >> | 1 | observationTimeSeconds | 4 | >> | 2 | ipHeaderPacketSection | variable | >> +----------+------------------------+----------+ >> >> Table 4: Packet Report Template >> >> 120,000 packets were captured in the network of a research institute. >> The resulting Packet Records were encapsulated in Data Sets of >> different length. Table 5 shows the original and compressed lengths >> of the Data Sets as well as the compression ratios. As can be seen, >> the compression ratio stays below 2 even for a large number of Packet >> Records per Data Set. Obviously, Packet Records are much less >> compressible than Flow Records. > > I disagree. You're not comparing like with like. > > eg, packet records could be exported in the same format as table 1, > except with packetDeltaCount = 1. Arguably, these should be slightly > more compressible than the equivalent flow records. > > >> The huge difference can be explained >> by the fact that Flow Records usually contain packet header fields >> where the observed values are very redundant. > > Certainly true for the fields chosen for the template in table 1. ie, > sourceIPv4Address, destinationIPv4Address, sourceTransportPort and > destinationTransportPort - even protocolIdentifier - may all be > expected to contain high levels of redundancy across multiple flows. > > The experiment only seems to show that ipHeaderPacketSection may > contain less redundancy thaontain a mixture of web traffic, mail traffic, database >> queries, VPN tunnels, dial-in traffic etc. The measurements were >> performed at a router using unsampled Cisco NetFlow with active and >> idle flow timeouts set to 150 seconds, resulting in about 300 Flow >> Records per second. As before, the Flow Records were converted into >> IPFIX Data Sets using the Template of Table 1. Encapsulating again >> 120,000 Flow Records into Data Sets of different length, we achieved >> the compression results shown in Table 3. As can be seen, the >> results are almost identical to those obtained in Section 4.1. > > And again, the uncompressed : compressed size is remarkably linear. > > >> >> +-----------------+--------------+------------------+---------------+ >> | Number of | Uncompressed | Compressed size | Mean | >> | Records per | size | (mean; min; max) | compression | >> | Data Set | | | ratio | >> +-----------------+--------------+------------------+---------------+ >> | 10 | 294 | 43.1; 39; 46 | 6.82 | >> | 20 | 584 | 45.6; 41; 48 | 12.80 | >> | 40 | 1164 | 49.7; 45; 52 | 23.42 | >> | 60 | 1744 | 54.0; 50; 57 | 32.29 | >> | 100 | 2904 | 63.4; 59; 66 | 45.80 | >> +-----------------+--------------+------------------+---------------+ >> >> Table 3: ISP Backbone Network: Compression Results >> >> 4.3. Packet Report Compression >> >> As specified in [I-D.ietf-psamp-protocol], the IPFIX protocol can be >> used to export PSAMP Packet Reports. In order to evaluate the >> compression gain that can be achieved with Packet Records, we >> compressed Data Sets containing IP packet header sections covering >> the IP and transport layer headers. The Template definition is shown >> in Table 4 below. The definition of the Information Elements can be >> found in [I-D.ietf-psamp-info]. >> >> >> >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 7] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> +----------+------------------------+----------+ >> | Field No | Information Element | Length | >> +----------+------------------------+----------+ >> | 1 | observationTimeSeconds | 4 | >> | 2 | ipHeaderPacketSection | variable | >> +----------+------------------------+----------+ >> >> Table 4: Packet Report Template >> >> 120,000 packets were captured in the network of a research institute. >> The resulting Packet Records were encapsulated in Data Sets of >> different length. Table 5 shows the original and compressed lengths >> of the Data Sets as well as the compression ratios. As can be seen, >> the compression ratio stays below 2 even for a large number of Packet >> Records per Data Set. Obviously, Packet Records are much less >> compressible than Flow Records. > > I disagree. You're not comparing like with like. > > eg, packet records could be exported in the same format as table 1, > except with packetDeltaCount = 1. Arguably, these should be slightly > more compressible than the equivalent flow records. > > >> The huge difference can be explained >> by the fact that Flow Records usually contain packet header fields >> where the observed values are very redundant. > > Certainly true for the fields chosen for the template in table 1. ie, > sourceIPv4Address, destinationIPv4Address, sourceTransportPort and > destinationTransportPort - even protocolIdentifier - may all be > expected to contain high levels of redundancy across multiple flows. > > The experiment only seems to show that ipHeaderPacketSection may > contain less redundancy than n these individual fields do. It doesn't > seem to prove anything about PSAMP versus IPFIX. > > >> >> +---------------+-------------------+-----------------+-------------+ >> | Number of | Uncompressed size | Compressed size | Mean | >> | Records per | (mean; min; max) | (mean; min; | compression | >> | Data Set | | max) | ratio | >> +---------------+-------------------+-----------------+-------------+ >> | 10 | 405.5; 302; 574 | 318.3; 172; 437 | 1.27 | >> | 20 | 807.0; 656; 1144 | 575.0; 341; 744 | 1.40 | >> | 40 | 1610.1; 1324; | 1029.9; 615; | 1.56 | >> | | 2260 | 1274 | | >> | 60 | 2413.1; 2056; | 1451.9; 889; | 1.66 | >> | | 3376 | 1771 | | >> | 100 | 4019.3; 3512; | 2275.4; 1769; | 1.76 | >> | | 5004 | 2675 | | >> +---------------+-------------------+-----------------+-------------+ >> >> Table 5: Packet Reports: Compression Results >> >> >> 5. Possible Realization of IPFIX Compression >> >> In this section, we discuss different options that allow applying >> compression methods to IPFIX traffic. At first, we describe two >> solutions which are based on compression options provided by IPComp >> and DTLS. As third and fourth option, we propose IPFIX-specific >> solutions which do not depend on the underlying transport protocol, >> but require extensions of the IPFIX protocol. >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 8] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> 5.1. Compressed IPsec Tunnel >> >> IP payload compression (IPComp) [RFC3173] enables the compression of >> IP datagrams exchanged between a pair of communicating nodes. >> Therefore, an IPComp association (IPCA) between the two nodes must be >> established. DEFLATE [RFC2394] and Lempel-Ziv-Stac (LZS) [RFC2395] >> are among the standardized compression methods. IPComp has been >> conceived for compressing IP datagrams before sending them over an >> encrypted tunnel. Dynamic negotiation of IPCAs has been standardized >> as part of the Internet Key Exchange protocol (IKE) [RFC4306]. >> >> If IPFIX traffic is transported over an IPsec tunnel, IPComp may be >> used for compression. In this case, the compression is transparent >> to both, Exporting Process and Collecting Process. >> >> 5.2. TLS/DTLS Compression >> >> TLS [RFC4346] and DTLS [RFC4347] enable the negotiation and >> deployment of a lossless compression method. Two compression methods >> have been standardized for usage with TLS: DEFLATE [RFC3749] and >> Lempel-Ziv-Stac (LZS) [RFC3943]. For DTLS, no compression methods >> have been standardized, yet. >> >> RFC 3749 [RFC3749] recommends the usage of stateful compression for >> TLS, which means that a compression history across packets is >> maintained to achieve higher compression ratios. DTLS has been >> conceived for transport protocols that do not guarantee reliable, >> sequenced packet delivery. In this case, only stateless per-packet >> compression is possible. For example, DEFLATE and LZS could be >> applied on a per-packet basis. >> >> The IPFIX protocol specification [RFC5101] mandates the support of >> DTLS if SCTP or UDP are used as transport protocol for IPFIX. >> Similarly, if TCP is used as transport protocol, TLS must be >> supported. Although no compression method has been standardized for >> DTLS, DEFLATE [RFC1951] can be used for stateless compression of >> individual SCTP messages or UDP datagrams. The utilization of DTLS >> or TLS is not mandated by the IPFIX protocol. If DTLS or TLS are >> employed, compression methods may be negotiated and dthese individual fields do. It doesn't > seem to prove anything about PSAMP versus IPFIX. > > >> >> +---------------+-------------------+-----------------+-------------+ >> | Number of | Uncompressed size | Compressed size | Mean | >> | Records per | (mean; min; max) | (mean; min; | compression | >> | Data Set | | max) | ratio | >> +---------------+-------------------+-----------------+-------------+ >> | 10 | 405.5; 302; 574 | 318.3; 172; 437 | 1.27 | >> | 20 | 807.0; 656; 1144 | 575.0; 341; 744 | 1.40 | >> | 40 | 1610.1; 1324; | 1029.9; 615; | 1.56 | >> | | 2260 | 1274 | | >> | 60 | 2413.1; 2056; | 1451.9; 889; | 1.66 | >> | | 3376 | 1771 | | >> | 100 | 4019.3; 3512; | 2275.4; 1769; | 1.76 | >> | | 5004 | 2675 | | >> +---------------+-------------------+-----------------+-------------+ >> >> Table 5: Packet Reports: Compression Results >> >> >> 5. Possible Realization of IPFIX Compression >> >> In this section, we discuss different options that allow applying >> compression methods to IPFIX traffic. At first, we describe two >> solutions which are based on compression options provided by IPComp >> and DTLS. As third and fourth option, we propose IPFIX-specific >> solutions which do not depend on the underlying transport protocol, >> but require extensions of the IPFIX protocol. >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 8] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> 5.1. Compressed IPsec Tunnel >> >> IP payload compression (IPComp) [RFC3173] enables the compression of >> IP datagrams exchanged between a pair of communicating nodes. >> Therefore, an IPComp association (IPCA) between the two nodes must be >> established. DEFLATE [RFC2394] and Lempel-Ziv-Stac (LZS) [RFC2395] >> are among the standardized compression methods. IPComp has been >> conceived for compressing IP datagrams before sending them over an >> encrypted tunnel. Dynamic negotiation of IPCAs has been standardized >> as part of the Internet Key Exchange protocol (IKE) [RFC4306]. >> >> If IPFIX traffic is transported over an IPsec tunnel, IPComp may be >> used for compression. In this case, the compression is transparent >> to both, Exporting Process and Collecting Process. >> >> 5.2. TLS/DTLS Compression >> >> TLS [RFC4346] and DTLS [RFC4347] enable the negotiation and >> deployment of a lossless compression method. Two compression methods >> have been standardized for usage with TLS: DEFLATE [RFC3749] and >> Lempel-Ziv-Stac (LZS) [RFC3943]. For DTLS, no compression methods >> have been standardized, yet. >> >> RFC 3749 [RFC3749] recommends the usage of stateful compression for >> TLS, which means that a compression history across packets is >> maintained to achieve higher compression ratios. DTLS has been >> conceived for transport protocols that do not guarantee reliable, >> sequenced packet delivery. In this case, only stateless per-packet >> compression is possible. For example, DEFLATE and LZS could be >> applied on a per-packet basis. >> >> The IPFIX protocol specification [RFC5101] mandates the support of >> DTLS if SCTP or UDP are used as transport protocol for IPFIX. >> Similarly, if TCP is used as transport protocol, TLS must be >> supported. Although no compression method has been standardized for >> DTLS, DEFLATE [RFC1951] can be used for stateless compression of >> individual SCTP messages or UDP datagrams. The utilization of DTLS >> or TLS is not mandated by the IPFIX protocol. If DTLS or TLS are >> employed, compression methods may be negotiated and depeployed between >> the Exporting Process and the Collecting Process. >> >> 5.3. Compressed IPFIX Messages >> >> A compressed variant of the IPFIX Message format could be designed as >> follows. The IPFIX Message header remains uncompressed and is >> structured as defined in Section 3.1 of [RFC5101]. The message >> payload following the IPFIX Message header is compressed using >> DEFLATE as specified in [RFC1951]. > > The payload may include templates and options, which you've not > discussed. Since these may be sent infrequently (compared with data > records) it may be more efficient _not_ to compress them. > > [Later: OK, see section 5.4] > > >> Optionally, the ZLIB format >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 9] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> [RFC1950] could be used to enable the choice of alternative >> compression methods and to protect the data integrity by a checksum. >> In order to distinguish compressed IPFIX Messages from normal IPFIX >> Messages, a new IPFIX Version Number must be used for compressed >> IPFIX Messages, for example 0x000b. > > Alternatively, the template could be marked as compressed. eg by using > a new template set ID (eg, Set ID 4 = a set of templates whose data > will be sent in compressed formats). Or, such templates could contain > a marker (eg, a new zero-length flag field) indicating that the > corresponding data records will be sent in compressed format. > > This would allow some (even all) data sets to be compressed, while > allowing templates and options to remain uncompressed. > > [Later: OK, see section 5.4] > > >> >> Leaving the IPFIX Message header uncompressed facilitates the work of >> both, Exporting Processes and Collecting Processes. The version >> number and length field are required to decode the message correctly. >> The Exporting Process does not know in advance how much time the >> compression will require. Keeping the export time in the IPFIX >> Message Header allows the Exporting Process to fill this field after >> compressing the message payload. > > If the EP was feeding a Compressed IPsec Tunnel (per 5.1 above) then > the export time cannot be filled accurately. Instead, it'll be the > time the EP handed the data to the tunnel process. > > Indeed, if the EP is feeding a regular interface driver, the export > time will indicate when the EP handed the data to the driver - which > may then buffer the data pending transmission on the media, and it may > be some time before the driver is able to transmit. So the export time > may often be a best-effort. > > >> Finally, the uncompressed >> Observation Domain ID allows the Collecting Process to classify IPFIX >> Messages before decompressing the message payload. > > Indeed, the CP may simply want to store compressed records for later > processing. > > >> >> 5.4. Compressed Data Sets >> >> Instead of compressing the entire payload of IPFIX Messages, it is >> also possible to introduce a new Set type called Deflate Template >> Set. Just like normal Template Sets, the Deflate Template Set is used >> to carry Templates, namely Deflate Templates. The format of Deflate >> Template Records is the same as the Template Record format specified >> in Section 3.4.1 of [RFC5101]. However, the corresponding Data Sets >> differ: starting with the first byte after the Set header, the >> sequence of Deflate Data Records is compressed using DEFLATE >> [RFC1951]. Again, the ZLIB format [RFC1950] could be used to enable >> the choice of alternative compression methods and to protect the data >> integrity by a checksum. The Set header remains uncompressed and >> includes the length of the Set after compression. In order to >> distinguish Deflate Template Sets from other Sets, a new Set ID value >> must be specified (e.g., Set ID = 4). >> >> Cloyed between >> the Exporting Process and the Collecting Process. >> >> 5.3. Compressed IPFIX Messages >> >> A compressed variant of the IPFIX Message format could be designed as >> follows. The IPFIX Message header remains uncompressed and is >> structured as defined in Section 3.1 of [RFC5101]. The message >> payload following the IPFIX Message header is compressed using >> DEFLATE as specified in [RFC1951]. > > The payload may include templates and options, which you've not > discussed. Since these may be sent infrequently (compared with data > records) it may be more efficient _not_ to compress them. > > [Later: OK, see section 5.4] > > >> Optionally, the ZLIB format >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 9] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> [RFC1950] could be used to enable the choice of alternative >> compression methods and to protect the data integrity by a checksum. >> In order to distinguish compressed IPFIX Messages from normal IPFIX >> Messages, a new IPFIX Version Number must be used for compressed >> IPFIX Messages, for example 0x000b. > > Alternatively, the template could be marked as compressed. eg by using > a new template set ID (eg, Set ID 4 = a set of templates whose data > will be sent in compressed formats). Or, such templates could contain > a marker (eg, a new zero-length flag field) indicating that the > corresponding data records will be sent in compressed format. > > This would allow some (even all) data sets to be compressed, while > allowing templates and options to remain uncompressed. > > [Later: OK, see section 5.4] > > >> >> Leaving the IPFIX Message header uncompressed facilitates the work of >> both, Exporting Processes and Collecting Processes. The version >> number and length field are required to decode the message correctly. >> The Exporting Process does not know in advance how much time the >> compression will require. Keeping the export time in the IPFIX >> Message Header allows the Exporting Process to fill this field after >> compressing the message payload. > > If the EP was feeding a Compressed IPsec Tunnel (per 5.1 above) then > the export time cannot be filled accurately. Instead, it'll be the > time the EP handed the data to the tunnel process. > > Indeed, if the EP is feeding a regular interface driver, the export > time will indicate when the EP handed the data to the driver - which > may then buffer the data pending transmission on the media, and it may > be some time before the driver is able to transmit. So the export time > may often be a best-effort. > > >> Finally, the uncompressed >> Observation Domain ID allows the Collecting Process to classify IPFIX >> Messages before decompressing the message payload. > > Indeed, the CP may simply want to store compressed records for later > processing. > > >> >> 5.4. Compressed Data Sets >> >> Instead of compressing the entire payload of IPFIX Messages, it is >> also possible to introduce a new Set type called Deflate Template >> Set. Just like normal Template Sets, the Deflate Template Set is used >> to carry Templates, namely Deflate Templates. The format of Deflate >> Template Records is the same as the Template Record format specified >> in Section 3.4.1 of [RFC5101]. However, the corresponding Data Sets >> differ: starting with the first byte after the Set header, the >> sequence of Deflate Data Records is compressed using DEFLATE >> [RFC1951]. Again, the ZLIB format [RFC1950] could be used to enable >> the choice of alternative compression methods and to protect the data >> integrity by a checksum. The Set header remains uncompressed and >> includes the length of the Set after compression. In order to >> distinguish Deflate Template Sets from other Sets, a new Set ID value >> must be specified (e.g., Set ID = 4). >> >> Comompression at the level of Data Sets is more flexible than the >> compression of IPFIX Messages as described in Section 5.3 since it >> allows exporting compressed and uncompressed Records within a single >> IPFIX Message. On the other hand, the size of the compressed data >> blocks is smaller, which usually results in lower compression ratios. > > Some example figures would be interesting. > > >> >> >> 6. Security Considerations >> >> The same security considerations as for the IPFIX protocol [RFC5101] >> apply. >> >> The protocol extensions discussed in Section 5.3 and Section 5.4 >> introduce additional security issues for the Collector. An attacker >> may send forged compressed IPFIX Messages or Data Sets to the >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 10] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> Collector which require very large amount of memory after >> decompression, leading to possible memory exhaustion. The >> decompression of such data may also require enormous processing >> resources, causing a temporary denial of service. The Collector must >> implement a protection mechanism which ensures that the decompression >> is interrupted if it spends large amount of memory or runtime. > > However, that could lead to loss of genuine IPFIX data. > > P. > > >> >> >> 7. IANA Considerations >> >> The two compression solutions described in Section 5.3 and >> Section 5.4 require the assignment of a new IPFIX Version Number or >> IPFIX Set ID respectively. As specifed in [RFC5101], the >> standardization of these solutions requires a Standards Action >> [RFC2434]. >> >> >> 8. References >> >> 8.1. Normative References >> >> [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an >> IANA Considerations Section in RFCs", BCP 26, RFC 2434, >> October 1998. >> >> [RFC5101] Claise, B., "Specification of the IP Flow Information >> Export (IPFIX) Protocol for the Exchange of IP Traffic >> Flow Information", RFC 5101, January 2008. >> >> [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. >> Meyer, "Information Model for IP Flow Information Export", >> RFC 5102, January 2008. >> >> [I-D.ietf-ipfix-file] >> Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. >> Wagner, "An IPFIX-Based File Format", >> draft-ietf-ipfix-file-01 (work in progress), > >> February 2008. >> >> [I-D.ietf-psamp-protocol] >> Claise, B., "Packet Sampling (PSAMP) Protocol >> Specifications", draft-ietf-psamp-protocol-09 (work in >> progress), December 2007. >> >> [I-D.ietf-psamp-info] >> Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. >> Carle, "Information Model for Packet Sampling Exports", >> draft-ietf-psamp-info-08 (work in progress), >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 11] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> February 2008. >> >> 8.2. Informative References >> >> [I-D.ietf-ipfix-reducing-redundancy] >> Boschi, E., "Reducing Redundancy in IP Flow Information >> Export (IPFIX) and Packet Sampling (PSAMP) Reports", >> draft-ietf-ipfix-reducing-redundancy-04 (work in >> progress), May 2007. >> >> [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. >> Aitken, "IPFIX Implementation Guidelines", RFC 5153, >> April 2008. >> >> [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, >> "Requirements for IP Flow Information Export (IPFIX)", >> RFC 3917, October 2004. >> >> [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format >> Specification versiopression at the level of Data Sets is more flexible than the >> compression of IPFIX Messages as described in Section 5.3 since it >> allows exporting compressed and uncompressed Records within a single >> IPFIX Message. On the other hand, the size of the compressed data >> blocks is smaller, which usually results in lower compression ratios. > > Some example figures would be interesting. > > >> >> >> 6. Security Considerations >> >> The same security considerations as for the IPFIX protocol [RFC5101] >> apply. >> >> The protocol extensions discussed in Section 5.3 and Section 5.4 >> introduce additional security issues for the Collector. An attacker >> may send forged compressed IPFIX Messages or Data Sets to the >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 10] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> Collector which require very large amount of memory after >> decompression, leading to possible memory exhaustion. The >> decompression of such data may also require enormous processing >> resources, causing a temporary denial of service. The Collector must >> implement a protection mechanism which ensures that the decompression >> is interrupted if it spends large amount of memory or runtime. > > However, that could lead to loss of genuine IPFIX data. > > P. > > >> >> >> 7. IANA Considerations >> >> The two compression solutions described in Section 5.3 and >> Section 5.4 require the assignment of a new IPFIX Version Number or >> IPFIX Set ID respectively. As specifed in [RFC5101], the >> standardization of these solutions requires a Standards Action >> [RFC2434]. >> >> >> 8. References >> >> 8.1. Normative References >> >> [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an >> IANA Considerations Section in RFCs", BCP 26, RFC 2434, >> October 1998. >> >> [RFC5101] Claise, B., "Specification of the IP Flow Information >> Export (IPFIX) Protocol for the Exchange of IP Traffic >> Flow Information", RFC 5101, January 2008. >> >> [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. >> Meyer, "Information Model for IP Flow Information Export", >> RFC 5102, January 2008. >> >> [I-D.ietf-ipfix-file] >> Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. >> Wagner, "An IPFIX-Based File Format", >> draft-ietf-ipfix-file-01 (work in progress), > >> February 2008. >> >> [I-D.ietf-psamp-protocol] >> Claise, B., "Packet Sampling (PSAMP) Protocol >> Specifications", draft-ietf-psamp-protocol-09 (work in >> progress), December 2007. >> >> [I-D.ietf-psamp-info] >> Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. >> Carle, "Information Model for Packet Sampling Exports", >> draft-ietf-psamp-info-08 (work in progress), >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 11] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> February 2008. >> >> 8.2. Informative References >> >> [I-D.ietf-ipfix-reducing-redundancy] >> Boschi, E., "Reducing Redundancy in IP Flow Information >> Export (IPFIX) and Packet Sampling (PSAMP) Reports", >> draft-ietf-ipfix-reducing-redundancy-04 (work in >> progress), May 2007. >> >> [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. >> Aitken, "IPFIX Implementation Guidelines", RFC 5153, >> April 2008. >> >> [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, >> "Requirements for IP Flow Information Export (IPFIX)", >> RFC 3917, October 2004. >> >> [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format >> Specification version 3.3", RFC 1950, May 1996. >> >> [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification >> version 1.3", RFC 1951, May 1996. >> >> [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. >> Randers-Pehrson, "GZIP file format specification version >> 4.3", RFC 1952, May 1996. >> >> [RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", >> RFC 2394, December 1998. >> >> [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using >> LZS", RFC 2395, December 1998. >> >> [RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP >> Payload Compression Protocol (IPComp)", RFC 3173, >> September 2001. >> >> [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol >> Compression Methods", RFC 3749, May 2004. >> >> [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol >> Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, >> November 2004. >> >> [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", >> RFC 4306, December 2005. >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 12] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security >> (TLS) Protocol Version 1.1", RFC 4346, April 2006. >> >> [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer >> Security", RFC 4347, April 2006. >> >> [nFlow] Deri, L., "nFlow: Monitoring Flows on IPv4/v6 Networks", >> TERENA Networking Conference 2004, June 2004. >> >> [LOBSTER] "IST LOBSTER Project Homepage", >> Homepage http://www.ist-lobster.org, 2008. >> >> [PMI08] Politopoulos, P., Markatos, E., and S. Ioannidis, >> "Evaluation of Compression of Remote Network Monitoring >> Data Streams", IEEE Workshop on End-to-End Monitoring >> Techniques and Services E2EMON 2008, April 2008. >> >> [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, >> August 2007. >> >> [RFC4993] Newton, A., "A Lightweight UDP Transfer Protocol for the >> Internet Registry Information Service", RFC 4993, >> August 2007. >> >> [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., >> Liu, Z., and J. Rosenberg, "Signaling Compression >> (SigComp)", RFC 3320, January 2003. >> >> [RFC2083] Boutell, T., "PNG (Portable Network Graphics) >> Specification Version 1.0", RFC 2083, March 1997. >> >> >> Authors' Addresses >> >> Gerhard Muenz >> University of Tuebingen >> Computer Networks and Internet >> Sand 13 >> Tuebingen D-72076 >> DE >> >> Phone: +49 7071 29-70534 >> Email: muenz@informatik.uni-tuebingen.de >> URI: http://net.informatik.uni-tuebingen.de/~muenz >> >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 13] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> Lothar Braun >> Technische Universitaet Muenchen >> Network Architectures and Services, Institute for Informatics >> Boltzmannstrasse 3 >> Garching D-85748 >> DE >> >> Phone: +49 89 289-18010 >> Email: braun@net.in.tum.de >> URI: http://www.net.in.tum.de/ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 14] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> Full Copyright Statement >> >> Copyright (C) The IETF Trust (2008). >> >> This document is subject to the rights, licenses and restrictions >> contained in BCP 78, and except as set forth therein, the authors >> retain all their rights. >>n 3.3", RFC 1950, May 1996. >> >> [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification >> version 1.3", RFC 1951, May 1996. >> >> [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. >> Randers-Pehrson, "GZIP file format specification version >> 4.3", RFC 1952, May 1996. >> >> [RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", >> RFC 2394, December 1998. >> >> [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using >> LZS", RFC 2395, December 1998. >> >> [RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP >> Payload Compression Protocol (IPComp)", RFC 3173, >> September 2001. >> >> [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol >> Compression Methods", RFC 3749, May 2004. >> >> [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol >> Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, >> November 2004. >> >> [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", >> RFC 4306, December 2005. >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 12] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security >> (TLS) Protocol Version 1.1", RFC 4346, April 2006. >> >> [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer >> Security", RFC 4347, April 2006. >> >> [nFlow] Deri, L., "nFlow: Monitoring Flows on IPv4/v6 Networks", >> TERENA Networking Conference 2004, June 2004. >> >> [LOBSTER] "IST LOBSTER Project Homepage", >> Homepage http://www.ist-lobster.org, 2008. >> >> [PMI08] Politopoulos, P., Markatos, E., and S. Ioannidis, >> "Evaluation of Compression of Remote Network Monitoring >> Data Streams", IEEE Workshop on End-to-End Monitoring >> Techniques and Services E2EMON 2008, April 2008. >> >> [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, >> August 2007. >> >> [RFC4993] Newton, A., "A Lightweight UDP Transfer Protocol for the >> Internet Registry Information Service", RFC 4993, >> August 2007. >> >> [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., >> Liu, Z., and J. Rosenberg, "Signaling Compression >> (SigComp)", RFC 3320, January 2003. >> >> [RFC2083] Boutell, T., "PNG (Portable Network Graphics) >> Specification Version 1.0", RFC 2083, March 1997. >> >> >> Authors' Addresses >> >> Gerhard Muenz >> University of Tuebingen >> Computer Networks and Internet >> Sand 13 >> Tuebingen D-72076 >> DE >> >> Phone: +49 7071 29-70534 >> Email: muenz@informatik.uni-tuebingen.de >> URI: http://net.informatik.uni-tuebingen.de/~muenz >> >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 13] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> Lothar Braun >> Technische Universitaet Muenchen >> Network Architectures and Services, Institute for Informatics >> Boltzmannstrasse 3 >> Garching D-85748 >> DE >> >> Phone: +49 89 289-18010 >> Email: braun@net.in.tum.de >> URI: http://www.net.in.tum.de/ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 14] >> >> Internet-Draft IPFIX Compression July 2008 >> >> >> Full Copyright Statement >> >> Copyright (C) The IETF Trust (2008). >> >> This document is subject to the rights, licenses and restrictions >> contained in BCP 78, and except as set forth therein, the authors >> retain all their rights. >> This document and the information contained herein are provided on an >> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS >> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND >> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS >> OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF >> THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED >> WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. >> >> >> Intellectual Property >> >> The IETF takes no position regarding the validity or scope of any >> Intellectual Property Rights or other rights that might be claimed to >> pertain to the implementation or use of the technology described in >> this document or the extent to which any license under such rights >> might or might not be available; nor does it represent that it has >> made any independent effort to identify any such rights. Information >> on the procedures with respect to rights in RFC documents can be >> found in BCP 78 and BCP 79. >> >> Copies of IPR disclosures made to the IETF Secretariat and any >> assurances of licenses to be made available, or the result of an >> attempt made to obtain a general license or permission for the use of >> such proprietary rights by implementers or users of this >> specification can be obtained from the IETF on-line IPR repository at >> http://www.ietf.org/ipr. >> >> The IETF invites any interested party to bring to its attention any >> copyrights, patents or patent applications, or other proprietary >> rights that may cover technology that may be required to implement >> this standard. Please address the information to the IETF at >> ietf-ipr@ietf.org. >> >> >> >> >> >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 15] >> > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix >> >> This document and the information contained herein are provided on an >> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS >> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND >> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS >> OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF >> THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED >> WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. >> >> >> Intellectual Property >> >> The IETF takes no position regarding the validity or scope of any >> Intellectual Property Rights or other rights that might be claimed to >> pertain to the implementation or use of the technology described in >> this document or the extent to which any license under such rights >> might or might not be available; nor does it represent that it has >> made any independent effort to identify any such rights. Information >> on the procedures with respect to rights in RFC documents can be >> found in BCP 78 and BCP 79. >> >> Copies of IPR disclosures made to the IETF Secretariat and any >> assurances of licenses to be made available, or the result of an >> attempt made to obtain a general license or permission for the use of >> such proprietary rights by implementers or users of this >> specification can be obtained from the IETF on-line IPR repository at >> http://www.ietf.org/ipr. >> >> The IETF invites any interested party to bring to its attention any >> copyrights, patents or patent applications, or other proprietary >> rights that may cover technology that may be required to implement >> this standard. Please address the information to the IETF at >> ietf-ipr@ietf.org. >> >> >> >> >> >> >> >> >> >> >> >> Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 15] >> > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Jul 28 09:10:26 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0083A6A1D; Mon, 28 Jul 2008 09:10:26 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635933A6892 for ; Mon, 28 Jul 2008 09:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxskOBfa78nd for ; Mon, 28 Jul 2008 09:10:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9454A28C1C7 for ; Mon, 28 Jul 2008 09:10:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,266,1215388800"; d="scan'208";a="15612246" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Jul 2008 16:10:14 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6SGAEGK007635 for ; Mon, 28 Jul 2008 18:10:14 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6SGAEvs000201 for ; Mon, 28 Jul 2008 16:10:14 GMT Received: from [10.61.96.151] (dhcp-10-61-96-151.cisco.com [10.61.96.151]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6SGADA10388 for ; Mon, 28 Jul 2008 17:10:13 +0100 (BST) Message-ID: <488DEF65.8060602@cisco.com> Date: Mon, 28 Jul 2008 17:10:13 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: "ipfix@ietf.org" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=139287; t=1217261414; x=1218125414; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-ietf-ipfix-file-02.txt |Sender:=20; bh=RJkypnfSG2YScRg8Ei/0n/9RUQcTgqa+F/Pg1Vs8RIM=; b=Y9ihOhFPxIOehyRy9zcKNySTh+D6aaBVJj1In/0OGlOp4bXr8Cn8i53Npz hfM1rJ/AblVDGFcIqtoxQ+khUACo326x7E47fl1qmsCPs2Cz0UjvqqX5DAxp 3x8CV0SVk+; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [IPFIX] review: draft-ietf-ipfix-file-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, All, As a general comment, consider how ipfix-file should work with ipfix-compression. eg should/must data be de-compressed before storage? Consider xref with section 9.1. More comments inline. > IPFIX Working Group B. Trammell > Internet-Draft E. Boschi > Intended status: Standards Track Hitachi Europe > Expires: January 15, 2009 From ipfix-bounces@ietf.org Mon Jul 28 09:10:26 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0083A6A1D; Mon, 28 Jul 2008 09:10:26 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635933A6892 for ; Mon, 28 Jul 2008 09:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxskOBfa78nd for ; Mon, 28 Jul 2008 09:10:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9454A28C1C7 for ; Mon, 28 Jul 2008 09:10:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,266,1215388800"; d="scan'208";a="15612246" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Jul 2008 16:10:14 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6SGAEGK007635 for ; Mon, 28 Jul 2008 18:10:14 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6SGAEvs000201 for ; Mon, 28 Jul 2008 16:10:14 GMT Received: from [10.61.96.151] (dhcp-10-61-96-151.cisco.com [10.61.96.151]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6SGADA10388 for ; Mon, 28 Jul 2008 17:10:13 +0100 (BST) Message-ID: <488DEF65.8060602@cisco.com> Date: Mon, 28 Jul 2008 17:10:13 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: "ipfix@ietf.org" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=139287; t=1217261414; x=1218125414; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20review=3A=20draft-ietf-ipfix-file-02.txt |Sender:=20; bh=RJkypnfSG2YScRg8Ei/0n/9RUQcTgqa+F/Pg1Vs8RIM=; b=Y9ihOhFPxIOehyRy9zcKNySTh+D6aaBVJj1In/0OGlOp4bXr8Cn8i53Npz hfM1rJ/AblVDGFcIqtoxQ+khUACo326x7E47fl1qmsCPs2Cz0UjvqqX5DAxp 3x8CV0SVk+; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [IPFIX] review: draft-ietf-ipfix-file-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, All, As a general comment, consider how ipfix-file should work with ipfix-compression. eg should/must data be de-compressed before storage? Consider xref with section 9.1. More comments inline. > IPFIX Working Group B. Trammell > Internet-Draft E. Boschi > Intended status: Standards Track Hitachi Europe > Expires: January 15, 2009 L. Mark > Fraunhofer IFAM > T. Zseby > Fraunhofer FOKUS > A. Wagner > ETH Zurich > July 14, 2008 > > > An IPFIX-Based File Format > draft-ietf-ipfix-file-02.txt > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January 15, 2009. > > Abstract > > This document describes a file format for the storage of flow data > based upon the IPFIX Message format. It proposes a set of > requirements for flat-file, binary flow data file formats, then > applies the IPFIX message format to these requirements to build a new > file format. This IPFIX-based file format is designed to facilitate > interoperability and reusability among a wide variety of flow > > > > Trammell, et al. Expires January 15, 2009 [Page 1] > > Internet-Draft IPFIX Files July 2008 > > > storage, processing, and analysis tools. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 > 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 > 5.1. Record Format Flexibility . . . . . . . . . . . . . . . . 10 > 5.2. Self Description . . . . . . . . . . . . . . . . . . . . . 10 > 5.3. Data Compression . . . . . . . . . . . . . . . . . . . . . 11 > 5.4. Indexing and Searching . . . . . . . . . . . . . . . . . . 11 > 5.5. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 12 > 5.6. Creator Authentication and Confidentiality . . . . . . . . 12 > 5.7. Anonymization and Obfuscation . . . . . . . . . . . . . . 13 > 5.8. Session Auditability and Replayability . . . . . . . . . . 13 > 5.9. Performance Characteristics . . . . . . . . . . . . . . . 14 > 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 14 > 6.1. Storage of IPFIX-collected Flow Data . . . . . . . . . . . 14 > 6.2. Storage of NetFlow V9-collected Flow Data . . . . . . . . 15 > 6.3. Testing IPFIX Collecting Processes . . . . . . . . . . . . 15 > 6.4. IPFIX Device Diagnostics . . . . . . . . . . . . . . . . . 15 > 7. Detailed Description . . . . . . . . . . . . . . . . . . . . . 16 > 7.1. File Reader Specification . . . . . . . . . . . . . . . . 16 > 7.2. File Writer Specification . . . . . . . . . . . . . . . . 17 L. Mark > Fraunhofer IFAM > T. Zseby > Fraunhofer FOKUS > A. Wagner > ETH Zurich > July 14, 2008 > > > An IPFIX-Based File Format > draft-ietf-ipfix-file-02.txt > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January 15, 2009. > > Abstract > > This document describes a file format for the storage of flow data > based upon the IPFIX Message format. It proposes a set of > requirements for flat-file, binary flow data file formats, then > applies the IPFIX message format to these requirements to build a new > file format. This IPFIX-based file format is designed to facilitate > interoperability and reusability among a wide variety of flow > > > > Trammell, et al. Expires January 15, 2009 [Page 1] > > Internet-Draft IPFIX Files July 2008 > > > storage, processing, and analysis tools. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 > 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 > 5.1. Record Format Flexibility . . . . . . . . . . . . . . . . 10 > 5.2. Self Description . . . . . . . . . . . . . . . . . . . . . 10 > 5.3. Data Compression . . . . . . . . . . . . . . . . . . . . . 11 > 5.4. Indexing and Searching . . . . . . . . . . . . . . . . . . 11 > 5.5. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 12 > 5.6. Creator Authentication and Confidentiality . . . . . . . . 12 > 5.7. Anonymization and Obfuscation . . . . . . . . . . . . . . 13 > 5.8. Session Auditability and Replayability . . . . . . . . . . 13 > 5.9. Performance Characteristics . . . . . . . . . . . . . . . 14 > 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 14 > 6.1. Storage of IPFIX-collected Flow Data . . . . . . . . . . . 14 > 6.2. Storage of NetFlow V9-collected Flow Data . . . . . . . . 15 > 6.3. Testing IPFIX Collecting Processes . . . . . . . . . . . . 15 > 6.4. IPFIX Device Diagnostics . . . . . . . . . . . . . . . . . 15 > 7. Detailed Description . . . . . . . . . . . . . . . . . . . . . 16 > 7.1. File Reader Specification . . . . . . . . . . . . . . . . 16 > 7.2. File Writer Specification . . . . . . . . . . . . . . . . 1> 7.3. Specific File Writer Use Cases . . . . . . . . . . . . . . 18 > 7.3.1. Collocating a File Writer with a Collecting Process . 18 > 7.3.2. Collocating a File Writer with a Metering Process . . 19 > 7.3.3. Using IPFIX Files for Archival Storage . . . . . . . . 19 > 7.3.4. Using IPFIX Files as Documents . . . . . . . . . . . . 19 > 7.3.5. Using IPFIX Files for Testing . . . . . . . . . . . . 20 > 7.3.6. Writing IPFIX Files for Device Diagnostics . . . . . . 21 > 8. File Format Metadata Specification . . . . . . . . . . . . . . 21 > 8.1. Recommended Options Templates for IPFIX Files . . . . . . 21 > 8.1.1. Message Checksum Options Template . . . . . . . . . . 21 > 8.1.2. File Time Window Options Template . . . . . . . . . . 22 > 8.1.3. Export Session Details Options Template . . . . . . . 22 > 8.1.4. Message Details Options Template . . . . . . . . . . . 24 > 8.2. Recommended Information Elements for IPFIX Files . . . . . 26 > 8.2.1. collectionTimeMilliseconds . . . . . . . . . . . . . . 26 > 8.2.2. exportSctpStreamId . . . . . . . . . . . . . . . . . . 27 > 8.2.3. maxExportSeconds . . . . . . . . . . . . . . . . . . . 27 > 8.2.4. maxFlowEndSeconds . . . . . . . . . . . . . . . . . . 28 > 8.2.5. messageMD5Checksum . . . . . . . . . . . . . . . . . . 28 > 8.2.6. messageScope . . . . . . . . . . . . . . . . . . . . . 28 > > > > Trammell, et al. Expires January 15, 2009 [Page 2] > > Internet-Draft IPFIX Files July 2008 > > > 8.2.7. minExportSeconds . . . . . . . . . . . . . . . . . . . 29 > 8.2.8. minFlowStartSeconds . . . . . . . . . . . . . . . . . 29 > 8.2.9. opaqueOctets . . . . . . . . . . . . . . . . . . . . . 30 > 8.2.10. sessionScope . . . . . . . . . . . . . . . . . . . . . 30 > 9. Recommended Error Resilience Strategies . . . . . . . . . . . 30 > 9.1. Compression Error Resilience . . . . . . . . . . . . . . . 31 > 9.2. Encryption Error Resilience . . . . . . . . . . . . . . . 32 > 10. Recommended File Integration Strategies . . . . . . . . . . . 32 > 10.1. Encapsulation of Non-IPFIX Data in IPFIX Files . . . . . . 32 > 10.2. Encapsulation of IPFIX Files within Other File Formats . . 33 > 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 > 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 > 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 > 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 > 14.1. Normative References . . . . . . . . . . . . . . . . . . . 35 > 14.2. Informative References . . . . . . . . . . . . . . . . . . 35 > Appendix A. Example IPFIX File . . . . . . . . . . . . . . . . . 36 > A.1. Example Options Templates . . . . . . . . . . . . . . . . 38 > A.2. Example Supplemental Options Data . . . . . . . . . . . . 40 > A.3. Example Message Checksum . . . . . . . . . . . . . . . . . 42 > A.4. File Example Data Set . . . . . . . . . . . . . . . . . . 43 > A.5. Complete File Example . . . . . . . . . . . . . . . . . . 43 > Appendix B. Applicability of IPFIX Files to NetFlow V9 flow > storage . . . . . . . . . . . . . . . . . . . . . . . 45 > B.1. Comparing NetFlow V9 to IPFIX . . . . . . . . . . . . . . 45 > B.1.1. Message Header Format . . . . . . . . . . . . . . . . 45 > B.1.2. Set Header Format . . . . . . . . . . . . . . . . . . 46 > B.1.3. Template Format . . . . . . . . . . . . . . . . . . . 47 > B.1.4. Information Model . . . . . . . . . . . . . . . . . . 47 > B.1.5. Template Management . . . . . . . . . . . . . . . . . 47 > B.1.6. Transport . . . . . . . . . . . . . . . . . . . . . . 47 > B.2. A Method for Transforming NetFlow V9 messages to IPFIX . . 48 > B.3. NetFlow V9 Transformati7 > 7.3. Specific File Writer Use Cases . . . . . . . . . . . . . . 18 > 7.3.1. Collocating a File Writer with a Collecting Process . 18 > 7.3.2. Collocating a File Writer with a Metering Process . . 19 > 7.3.3. Using IPFIX Files for Archival Storage . . . . . . . . 19 > 7.3.4. Using IPFIX Files as Documents . . . . . . . . . . . . 19 > 7.3.5. Using IPFIX Files for Testing . . . . . . . . . . . . 20 > 7.3.6. Writing IPFIX Files for Device Diagnostics . . . . . . 21 > 8. File Format Metadata Specification . . . . . . . . . . . . . . 21 > 8.1. Recommended Options Templates for IPFIX Files . . . . . . 21 > 8.1.1. Message Checksum Options Template . . . . . . . . . . 21 > 8.1.2. File Time Window Options Template . . . . . . . . . . 22 > 8.1.3. Export Session Details Options Template . . . . . . . 22 > 8.1.4. Message Details Options Template . . . . . . . . . . . 24 > 8.2. Recommended Information Elements for IPFIX Files . . . . . 26 > 8.2.1. collectionTimeMilliseconds . . . . . . . . . . . . . . 26 > 8.2.2. exportSctpStreamId . . . . . . . . . . . . . . . . . . 27 > 8.2.3. maxExportSeconds . . . . . . . . . . . . . . . . . . . 27 > 8.2.4. maxFlowEndSeconds . . . . . . . . . . . . . . . . . . 28 > 8.2.5. messageMD5Checksum . . . . . . . . . . . . . . . . . . 28 > 8.2.6. messageScope . . . . . . . . . . . . . . . . . . . . . 28 > > > > Trammell, et al. Expires January 15, 2009 [Page 2] > > Internet-Draft IPFIX Files July 2008 > > > 8.2.7. minExportSeconds . . . . . . . . . . . . . . . . . . . 29 > 8.2.8. minFlowStartSeconds . . . . . . . . . . . . . . . . . 29 > 8.2.9. opaqueOctets . . . . . . . . . . . . . . . . . . . . . 30 > 8.2.10. sessionScope . . . . . . . . . . . . . . . . . . . . . 30 > 9. Recommended Error Resilience Strategies . . . . . . . . . . . 30 > 9.1. Compression Error Resilience . . . . . . . . . . . . . . . 31 > 9.2. Encryption Error Resilience . . . . . . . . . . . . . . . 32 > 10. Recommended File Integration Strategies . . . . . . . . . . . 32 > 10.1. Encapsulation of Non-IPFIX Data in IPFIX Files . . . . . . 32 > 10.2. Encapsulation of IPFIX Files within Other File Formats . . 33 > 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 > 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 > 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 > 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 > 14.1. Normative References . . . . . . . . . . . . . . . . . . . 35 > 14.2. Informative References . . . . . . . . . . . . . . . . . . 35 > Appendix A. Example IPFIX File . . . . . . . . . . . . . . . . . 36 > A.1. Example Options Templates . . . . . . . . . . . . . . . . 38 > A.2. Example Supplemental Options Data . . . . . . . . . . . . 40 > A.3. Example Message Checksum . . . . . . . . . . . . . . . . . 42 > A.4. File Example Data Set . . . . . . . . . . . . . . . . . . 43 > A.5. Complete File Example . . . . . . . . . . . . . . . . . . 43 > Appendix B. Applicability of IPFIX Files to NetFlow V9 flow > storage . . . . . . . . . . . . . . . . . . . . . . . 45 > B.1. Comparing NetFlow V9 to IPFIX . . . . . . . . . . . . . . 45 > B.1.1. Message Header Format . . . . . . . . . . . . . . . . 45 > B.1.2. Set Header Format . . . . . . . . . . . . . . . . . . 46 > B.1.3. Template Format . . . . . . . . . . . . . . . . . . . 47 > B.1.4. Information Model . . . . . . . . . . . . . . . . . . 47 > B.1.5. Template Management . . . . . . . . . . . . . . . . . 47 > B.1.6. Transport . . . . . . . . . . . . . . . . . . . . . . 47 > B.2. A Method for Transforming NetFlow V9 messages to IPFIX . . 48 > B.3. NetFlow V9 Transformaon Example . . . . . . . . . . . . 49 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 > Intellectual Property and Copyright Statements . . . . . . . . . . 53 > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 3] > > Internet-Draft IPFIX Files July 2008 > > > 1. Introduction > > This document proposes a file format based upon IPFIX, designed to > facilitiate interoperability and reusability among a wide variety of > flow storage, processing, and analysis tools. It begins with an > overview of the IPFIX File format, and a quick summary of how IPFIX > Files work in Section 3. It then explores the motivation for > proposing a standardized flow file format and using IPFIX as the > basis for this new file format in Section 4. This seems back to front. Surely the motivation should come first? > It outlines a set of > requirements for standardized flow storage in Section 5, and explores > the applicability of such a format to various specific application > areas in Section 6. > > The file format specification follows in Section 7, including > specifications of readers and writers of these files, and additional > specifications that apply in specific use cases. This format makes > use of the IPFIX Options mechanism for additional file metadata, in > order to avoid requiring any protocol or message format extensions, > and to minimize the effort required to adapt IPFIX implementations to > use the file format; a detailed definition of the Options Templates > used for storage metedata appears in Section 8. > > Section 9 and Section 10 provide specific recommendations for error > resilience during long-term storage and integration of IPFIX File > data with other formats. Appendix A contains a detailed example > IPFIX File. > > 1.1. IPFIX Documents Overview > > "Specification of the IPFIX Protocol for the Exchange of IP Traffic > Flow Information" [RFC5101] and its associated documents define the > IPFIX Protocol, which provides network engineers and administrators > with access to IP traffic flow information. > > "Architecture for IP Flow Information Export" [I-D.ietf-ipfix-arch] > defines the architecture for the export of measured IP flow > information out of an IPFIX Exporting Process to an IPFIX Collecting > Process, and the basic terminology used to describe the elements of > this architecture, per the requirements defined in "Requirements for > IP Flow Information Export" [RFC3917]. [RFC5101] then covers the > details of the method for transporting IPFIX Data Records and > Templates via a congestion-aware transport protocol from an IPFIX > Exporting Process to an IPFIX Collecting Process. > > "Information Model for IP Flow Information Export" [RFC5102] > describes the Information Elements used by IPFIX, including details > on Information Element naming, numbering, and data type encoding. > Finally, "IPFIX Applicability" [I-D.ietf-ipfix-as] describes the > > > > Trammell, et al. Expires January 15, 2009 [Page 4] > > Internet-Draft IPFIX Files July 2008 > > > various applications of the IPFIX protocol and their use of > information exported via IPFIX, and relates the IPFIX architecture to > other measurement architectures and frameworks. > > In addition, "Exporting Type Information for IPFIX Information > Elements" [I-D.ietf-ipfix-exporting-type] specifies a method for > encoding Information Model properties within an IPFIX Message stream. > > This document references [RFC5101] and the architecture document for > terminology, defines IPFIX File Writer and IPFIX File Reader in terms > of the IPFIX Exporting Processes and IPFIX Collecting Process > definitions from [RFC5101], and extends the IPFIX Information Model > tion Example . . . . . . . . . . . . 49 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 > Intellectual Property and Copyright Statements . . . . . . . . . . 53 > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 3] > > Internet-Draft IPFIX Files July 2008 > > > 1. Introduction > > This document proposes a file format based upon IPFIX, designed to > facilitiate interoperability and reusability among a wide variety of > flow storage, processing, and analysis tools. It begins with an > overview of the IPFIX File format, and a quick summary of how IPFIX > Files work in Section 3. It then explores the motivation for > proposing a standardized flow file format and using IPFIX as the > basis for this new file format in Section 4. This seems back to front. Surely the motivation should come first? > It outlines a set of > requirements for standardized flow storage in Section 5, and explores > the applicability of such a format to various specific application > areas in Section 6. > > The file format specification follows in Section 7, including > specifications of readers and writers of these files, and additional > specifications that apply in specific use cases. This format makes > use of the IPFIX Options mechanism for additional file metadata, in > order to avoid requiring any protocol or message format extensions, > and to minimize the effort required to adapt IPFIX implementations to > use the file format; a detailed definition of the Options Templates > used for storage metedata appears in Section 8. > > Section 9 and Section 10 provide specific recommendations for error > resilience during long-term storage and integration of IPFIX File > data with other formats. Appendix A contains a detailed example > IPFIX File. > > 1.1. IPFIX Documents Overview > > "Specification of the IPFIX Protocol for the Exchange of IP Traffic > Flow Information" [RFC5101] and its associated documents define the > IPFIX Protocol, which provides network engineers and administrators > with access to IP traffic flow information. > > "Architecture for IP Flow Information Export" [I-D.ietf-ipfix-arch] > defines the architecture for the export of measured IP flow > information out of an IPFIX Exporting Process to an IPFIX Collecting > Process, and the basic terminology used to describe the elements of > this architecture, per the requirements defined in "Requirements for > IP Flow Information Export" [RFC3917]. [RFC5101] then covers the > details of the method for transporting IPFIX Data Records and > Templates via a congestion-aware transport protocol from an IPFIX > Exporting Process to an IPFIX Collecting Process. > > "Information Model for IP Flow Information Export" [RFC5102] > describes the Information Elements used by IPFIX, including details > on Information Element naming, numbering, and data type encoding. > Finally, "IPFIX Applicability" [I-D.ietf-ipfix-as] describes the > > > > Trammell, et al. Expires January 15, 2009 [Page 4] > > Internet-Draft IPFIX Files July 2008 > > > various applications of the IPFIX protocol and their use of > information exported via IPFIX, and relates the IPFIX architecture to > other measurement architectures and frameworks. > > In addition, "Exporting Type Information for IPFIX Information > Elements" [I-D.ietf-ipfix-exporting-type] specifies a method for > encoding Information Model properties within an IPFIX Message stream. > > This document references [RFC5101] and the architecture document for > terminology, defines IPFIX File Writer and IPFIX File Reader in terms > of the IPFIX Exporting Processes and IPFIX Collecting Process > definitions from [RFC5101], and extends the IPFIX Information Model > defined in [RFC5102] to provide new Information Elements for IPFIX > File metadata. It uses the method described in "Exporting Type > Information for IPFIX Information Elements" > [I-D.ietf-ipfix-exporting-type] document to support the self- > description of IPFIX Files containing enterprise-specific Information > Elements. > > > 2. Terminology > > Terms used in this document that are defined in the Terminology > section of [RFC5101] are to be interpreted as defined there. > > IPFIX File: An IPFIX File is a serialized stream of IPFIX Messages > stored on a filesystem. Any IPFIX Message stream that would be > considered valid when transported one or more of the specified > IPFIX transports (SCTP, TCP, or UDP) as defined in [RFC5101] is > considered an IPFIX File for purposes of this document; however, > this document extends that definition with recommendations on the > construction of IPFIX Files that meet the requirements identified > herein. > > IPFIX File Reader: An IPFIX File Reader is a Process which reads > IPFIX Files from a filesystem, and is analogous to an IPFIX > Collecting Process. An IPFIX File Reader MUST behave as an IPFIX > Collecting Process as outlined in [RFC5101], except as modified by > this document. > > IPFIX File Writer: An IPFIX File Writer is a process which writes > IPFIX Files to a filesystem, and is analogous to an IPFIX > Exporting Process. An IPFIX File Writer MUST behave as an IPFIX > Exporting Process as outlined in [RFC5101], except as modified by > this document. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > > > Trammell, et al. Expires January 15, 2009 [Page 5] > > Internet-Draft IPFIX Files July 2008 > > > document are to be interpreted as described in [RFC2119]. > > > 3. Design Overview > > An IPFIX File, as defined by this document, is simply a stream > containing one or more IPFIX Messages serialized to some filesystem. > Though any set of valid IPFIX Messages can be serialized into an > IPFIX File, the specification proposes guidelines designed to ease > storage and retrieval of flow data using the format. > > IPFIX Files contain only IPFIX Messages; any file metadata such as > checksums or export session details are stored using Options within > the IPFIX Message. This design has several advantages, including > complete compatibility with the IPFIX Protocol on the wire and free > manipulability of IPFIX Files through concatenation, appending, and > splitting (on IPFIX Message boundaries). A schematic of a typical > file is shown below: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 6] > > Internet-Draft IPFIX Files July 2008 > > > +=======================================+ > | IPFIX File | > | +===================================+ | > | | IPFIX Message | | > | | +-------------------------------+ | | > | | | Options Template Set | | | > | | | Options Template Record | | | > | | | . . . | | | > | | +-------------------------------+ | | > | | +-------------------------------+ | | > | | | Template Set | | | > | | | Template Record | | | > | | | . . . | | | > | | +-------------------------------+ | | > | +===================================+ | > | | IPFIX Message | | > | | +-------------------------- defined in [RFC5102] to provide new Information Elements for IPFIX > File metadata. It uses the method described in "Exporting Type > Information for IPFIX Information Elements" > [I-D.ietf-ipfix-exporting-type] document to support the self- > description of IPFIX Files containing enterprise-specific Information > Elements. > > > 2. Terminology > > Terms used in this document that are defined in the Terminology > section of [RFC5101] are to be interpreted as defined there. > > IPFIX File: An IPFIX File is a serialized stream of IPFIX Messages > stored on a filesystem. Any IPFIX Message stream that would be > considered valid when transported one or more of the specified > IPFIX transports (SCTP, TCP, or UDP) as defined in [RFC5101] is > considered an IPFIX File for purposes of this document; however, > this document extends that definition with recommendations on the > construction of IPFIX Files that meet the requirements identified > herein. > > IPFIX File Reader: An IPFIX File Reader is a Process which reads > IPFIX Files from a filesystem, and is analogous to an IPFIX > Collecting Process. An IPFIX File Reader MUST behave as an IPFIX > Collecting Process as outlined in [RFC5101], except as modified by > this document. > > IPFIX File Writer: An IPFIX File Writer is a process which writes > IPFIX Files to a filesystem, and is analogous to an IPFIX > Exporting Process. An IPFIX File Writer MUST behave as an IPFIX > Exporting Process as outlined in [RFC5101], except as modified by > this document. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > > > Trammell, et al. Expires January 15, 2009 [Page 5] > > Internet-Draft IPFIX Files July 2008 > > > document are to be interpreted as described in [RFC2119]. > > > 3. Design Overview > > An IPFIX File, as defined by this document, is simply a stream > containing one or more IPFIX Messages serialized to some filesystem. > Though any set of valid IPFIX Messages can be serialized into an > IPFIX File, the specification proposes guidelines designed to ease > storage and retrieval of flow data using the format. > > IPFIX Files contain only IPFIX Messages; any file metadata such as > checksums or export session details are stored using Options within > the IPFIX Message. This design has several advantages, including > complete compatibility with the IPFIX Protocol on the wire and free > manipulability of IPFIX Files through concatenation, appending, and > splitting (on IPFIX Message boundaries). A schematic of a typical > file is shown below: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 6] > > Internet-Draft IPFIX Files July 2008 > > > +=======================================+ > | IPFIX File | > | +===================================+ | > | | IPFIX Message | | > | | +-------------------------------+ | | > | | | Options Template Set | | | > | | | Options Template Record | | | > | | | . . . | | | > | | +-------------------------------+ | | > | | +-------------------------------+ | | > | | | Template Set | | | > | | | Template Record | | | > | | | . . . | | | > | | +-------------------------------+ | | > | +===================================+ | > | | IPFIX Message | | > | | +-----------------------------+ | | > | | | Data Set | | | > | | | Data Record | | | > | | | . . . | | | > | | +-------------------------------+ | | > | | +-------------------------------+ | | > | | | Data Set | | | > | | | Data Record | | | > | | | . . . | | | > | | +-------------------------------+ | | > | | . . . | | > | +===================================+ | > | . . . | > +=======================================+ > > Figure 1: Typical File Structure > > See Section 7 for details of the implementation of this design, > including specific requirements and guidelines for File Readers and > File Writers, and Information Elements and Options Templates used for > file metadata. > > > 4. Motivation > > There are a wide variety of applications for the file-based storage > of IP flow data, across a continuum of time scales. Tools used in > the analysis of flow data and creation of analysis products often use > files as a convenient unit of work, with an ephemeral lifetime. A > set of flows relevant to a security investigation may be stored in a > file for the duration of that investigation, and further exchanged > among incident handlers via email or within an external incident > > > > Trammell, et al. Expires January 15, 2009 [Page 7] > > Internet-Draft IPFIX Files July 2008 > > > handling workflow application. Sets of flow data relevant to > Internet measurement research may be published as files, much as > libpcap packet trace files are, to provide common data sets for the > repeatability of research efforts; these files would have lifetimes > measured in months or years. Operational flow measurement systems > also have a need for long-term, archival storage of flow data, either > as a primary flow data repository, or as a backing tier for online > storage in a relational database management system (RDBMS). > > The variety of applications of flow data, and the variety of > presently deployed storage approaches, would seem to indicate the > need for a standard approach to flow storage with applicability > across the continuum of time scales over which flow data is stored. > A storage format based around flat files would best address the > variety of storage requirements. While much work has been done on > structured storage via RDBMS, relational database systems are not a > good basis for format standardization owing to the fact that their > internal data structures are generally private to a single > implementation and subject to change for internal reasons. Also, > there are a wide variety of operations available on flat files, and > external tools and standards can be leveraged to meet file-based flow > storage requirements. Further, flow data is often not very > semantically complicated, and is managed in very high volume; > therefore, an RDBMS-based flow storage system would not benefit much > from the advantages of relational database technology. > > The simplest way to create a new file format is simply to serialize > some internal data model to disk, with either textual or binary > representation of data elements, and some framing strategy for > delimiting fields and records. "Ad-hoc" file formats such as this > have several important disadvantages. They impose the semantics of > the data model from which they are derived on the file format, and as > such, they are difficult to extend, describe, and standardize. > > Indeed, one de facto standard for the storage of flow data is one of > these ad-hoc formats. A common method of storing data collected via > C-------+ | | > | | | Data Set | | | > | | | Data Record | | | > | | | . . . | | | > | | +-------------------------------+ | | > | | +-------------------------------+ | | > | | | Data Set | | | > | | | Data Record | | | > | | | . . . | | | > | | +-------------------------------+ | | > | | . . . | | > | +===================================+ | > | . . . | > +=======================================+ > > Figure 1: Typical File Structure > > See Section 7 for details of the implementation of this design, > including specific requirements and guidelines for File Readers and > File Writers, and Information Elements and Options Templates used for > file metadata. > > > 4. Motivation > > There are a wide variety of applications for the file-based storage > of IP flow data, across a continuum of time scales. Tools used in > the analysis of flow data and creation of analysis products often use > files as a convenient unit of work, with an ephemeral lifetime. A > set of flows relevant to a security investigation may be stored in a > file for the duration of that investigation, and further exchanged > among incident handlers via email or within an external incident > > > > Trammell, et al. Expires January 15, 2009 [Page 7] > > Internet-Draft IPFIX Files July 2008 > > > handling workflow application. Sets of flow data relevant to > Internet measurement research may be published as files, much as > libpcap packet trace files are, to provide common data sets for the > repeatability of research efforts; these files would have lifetimes > measured in months or years. Operational flow measurement systems > also have a need for long-term, archival storage of flow data, either > as a primary flow data repository, or as a backing tier for online > storage in a relational database management system (RDBMS). > > The variety of applications of flow data, and the variety of > presently deployed storage approaches, would seem to indicate the > need for a standard approach to flow storage with applicability > across the continuum of time scales over which flow data is stored. > A storage format based around flat files would best address the > variety of storage requirements. While much work has been done on > structured storage via RDBMS, relational database systems are not a > good basis for format standardization owing to the fact that their > internal data structures are generally private to a single > implementation and subject to change for internal reasons. Also, > there are a wide variety of operations available on flat files, and > external tools and standards can be leveraged to meet file-based flow > storage requirements. Further, flow data is often not very > semantically complicated, and is managed in very high volume; > therefore, an RDBMS-based flow storage system would not benefit much > from the advantages of relational database technology. > > The simplest way to create a new file format is simply to serialize > some internal data model to disk, with either textual or binary > representation of data elements, and some framing strategy for > delimiting fields and records. "Ad-hoc" file formats such as this > have several important disadvantages. They impose the semantics of > the data model from which they are derived on the file format, and as > such, they are difficult to extend, describe, and standardize. > > Indeed, one de facto standard for the storage of flow data is one of > these ad-hoc formats. A common method of storing data collected via > isco NetFlow V5 or V7 is to serialize a stream of raw NetFlow > datagrams into files. These NetFlow PDU files consist of a > collection of header-prefixed blocks (corresponding to the datagrams > as received on the wire) containing fixed-length binary flow records. > NetFlow V5 and V7 data may be mixed within a given file, as the > header on each datagram defines the NetFlow version of the records > following; there is indeed very little difference between the two > record formats. While this NetFlow PDU file format has all the > disadvantages of an ad-hoc format, and is not extensible to data > models other than that defined by Cisco NetFlow, it is at least > reasonably well-understood due to its ubiquity. > > > > > Trammell, et al. Expires January 15, 2009 [Page 8] > > Internet-Draft IPFIX Files July 2008 > > > Over the past decade XML markup has emerged as a new "universal" > representation format for structured data. It is intended to be > human-readable; indeed, that is one reason for its rapid adoption. > However XML has limited usefulness for representing network flow > data. Network flow data has a simple, repetitive, non-hierarchical > structure that does not benefit much from XML. An XML representation > of flow data would be an essentially flat list of the attributes and > their values for each flow record. > > The XML approach to data encoding is very heavyweight when compared > to binary flow encoding. XML's use of start- and end-tags, and > plain-text encoding of the actual values, leads to significant > inefficiency in encoding size. Typical network flow datasets can > contain millions or billions of flows per hour of traffic > represented. Any increase in storage size per record can have > dramatic impact on flow data storage and transfer sizes. While data > compression algorithms can partially remove the redundancy introduced > by XML encoding, they introduce additional overhead of their own. > > A further problem is that XML processing tools require a full XML > parser. XML parsers are fully general and therefore complex, > resource-intensive and relatively slow, introducing significant > processing time overhead for large network-flow datasets. In > contrast, parsers for typical binary flow data encodings are simply > structured, since they only need to parse a very small header and > then have complete knowledge of all following fields for the > particular flow. These can then be read in a very efficient linear > fashion. > > This leads us to propose the IPFIX Message format as the basis for a > new flow data file format. The IPFIX working group, in defining the > IPFIX protocol, has already defined an information model and data > formatting rules for representation of flow data. Especially at > shorter time scales, when a file is a unit of data interchange, the > filesystem may be viewed as simply another IPFIX Message transport > between processes. This format is especially well suited to > representing flow data, as it was designed specifically for flow data > export; it is easily extensible unlike ad-hoc serialization, and > compact unlike XML. In addition, IPFIX is an IETF standard for the > export and collection of flow data; using a common format for storage > and analysis at the collection side allows implementors to use > substantially the same information model and data formatting > implementation for transport as well as storage. > > > 5. Requirements > > In this section, we outline a proposed set of requirements > > > > Trammell, et al. Expires January 15, 2009 [Page 9] > > Internet-Draft IPFIX Files July 2008 > > > [SAINT2007] for any persistent storage format for flow data. First > and foremost, a flow data file format should support storage across > the continuum of time scal Cisco NetFlow V5 or V7 is to serialize a stream of raw NetFlow > datagrams into files. These NetFlow PDU files consist of a > collection of header-prefixed blocks (corresponding to the datagrams > as received on the wire) containing fixed-length binary flow records. > NetFlow V5 and V7 data may be mixed within a given file, as the > header on each datagram defines the NetFlow version of the records > following; there is indeed very little difference between the two > record formats. While this NetFlow PDU file format has all the > disadvantages of an ad-hoc format, and is not extensible to data > models other than that defined by Cisco NetFlow, it is at least > reasonably well-understood due to its ubiquity. > > > > > Trammell, et al. Expires January 15, 2009 [Page 8] > > Internet-Draft IPFIX Files July 2008 > > > Over the past decade XML markup has emerged as a new "universal" > representation format for structured data. It is intended to be > human-readable; indeed, that is one reason for its rapid adoption. > However XML has limited usefulness for representing network flow > data. Network flow data has a simple, repetitive, non-hierarchical > structure that does not benefit much from XML. An XML representation > of flow data would be an essentially flat list of the attributes and > their values for each flow record. > > The XML approach to data encoding is very heavyweight when compared > to binary flow encoding. XML's use of start- and end-tags, and > plain-text encoding of the actual values, leads to significant > inefficiency in encoding size. Typical network flow datasets can > contain millions or billions of flows per hour of traffic > represented. Any increase in storage size per record can have > dramatic impact on flow data storage and transfer sizes. While data > compression algorithms can partially remove the redundancy introduced > by XML encoding, they introduce additional overhead of their own. > > A further problem is that XML processing tools require a full XML > parser. XML parsers are fully general and therefore complex, > resource-intensive and relatively slow, introducing significant > processing time overhead for large network-flow datasets. In > contrast, parsers for typical binary flow data encodings are simply > structured, since they only need to parse a very small header and > then have complete knowledge of all following fields for the > particular flow. These can then be read in a very efficient linear > fashion. > > This leads us to propose the IPFIX Message format as the basis for a > new flow data file format. The IPFIX working group, in defining the > IPFIX protocol, has already defined an information model and data > formatting rules for representation of flow data. Especially at > shorter time scales, when a file is a unit of data interchange, the > filesystem may be viewed as simply another IPFIX Message transport > between processes. This format is especially well suited to > representing flow data, as it was designed specifically for flow data > export; it is easily extensible unlike ad-hoc serialization, and > compact unlike XML. In addition, IPFIX is an IETF standard for the > export and collection of flow data; using a common format for storage > and analysis at the collection side allows implementors to use > substantially the same information model and data formatting > implementation for transport as well as storage. > > > 5. Requirements > > In this section, we outline a proposed set of requirements > > > > Trammell, et al. Expires January 15, 2009 [Page 9] > > Internet-Draft IPFIX Files July 2008 > > > [SAINT2007] for any persistent storage format for flow data. First > and foremost, a flow data file format should support storage across > the continuum of time sces important to flow storage applications. > Each of the requirements enumerated in the sections below is broadly > applicable to flow storage applications, though each may be more > important at certain time scales. For each, we first identify the > requirement, then explain how the IPFIX Message format addresses it, > or briefly outline the changes that must be made in order for an > IPFIX-based file format to meet the requirement. > > 5.1. Record Format Flexibility > > Due to the wide variety of flow attributes collected by different > network flow attribute measurement systems, the ideal flow storage > format will not impose a single data model or a specific record type > on the flows it stores. The file format must be flexible and > extensible; that is, it must support the definition of multiple > record types within the file itself, and must be able to support new > field types for data within the records in a graceful way. > > IPFIX provides record format flexibility through the use of Templates > to describe each Data Record, through the use of an IANA Registry to > define its Information Elements, and through the use of enterprise- > specific Information Elements. > > 5.2. Self Description > > Archived data may be read at a time in the future where any external > reference to the meaning of the data may be lost. The ideal flow > storage format should be self-describing; that is, a process reading > flow data from storage should be able to properly interpret the > stored flows without reference to anything other than standard > sources (e.g., the standards document describing the file format) and > the stored flow data itself. > > The IPFIX Message format is partially self-describing; that is, IPFIX > Templates containing only IANA-assigned Information Elements can be > completely interpreted according to the IPFIX Information Model > without additional external data. > > However, Templates containing private information elements lack > detailed type and semantic information; a Collecting Process > receiving data described by a template containing private Information > Elements it does not understand can only treat the data contained > within those Information Elements as octet arrays. To be fully self- > describing, enterprise-specific Information Elements must be > additionally described via IPFIX Options according to the Information > Element Type Options Template defined in "Exporting Type Information > > > > Trammell, et al. Expires January 15, 2009 [Page 10] > > Internet-Draft IPFIX Files July 2008 > > > for IPFIX Information Elements" [I-D.ietf-ipfix-exporting-type]. > > 5.3. Data Compression > > Regardless of the representation format, flow data describing traffic > on real networks tends to be highly compressible. Compression tends > to improve the scalability of flow collection systems, by reducing > the disk storage and I/O bandwidth requirement for a given workload. > The ideal flow storage format should support applications which wish > to leverage this fact by supporting compression of stored data. > > The IPFIX Message format has no support for data compression, as the > IPFIX protocol was designed for speed and simplicity of export. Of > course, any flat file is readily compressible using a wide variety of > external data compression tools, formats, and algorithms; therefore, > this requirement can be met externally. > > However, a couple of simple optimizations can be made by File Writers > to increase the integrity and usability of compressed IPFIX data; > these are outlined in Section 9.1. > > 5.4. Indexing and Searching > > Binary, record stream oriented file formats natively support only one > form of searching, sequential scan in file order. By choosing the > order of records in a file carefully (e.g., by flow start or flow end > time), a fileales important to flow storage applications. > Each of the requirements enumerated in the sections below is broadly > applicable to flow storage applications, though each may be more > important at certain time scales. For each, we first identify the > requirement, then explain how the IPFIX Message format addresses it, > or briefly outline the changes that must be made in order for an > IPFIX-based file format to meet the requirement. > > 5.1. Record Format Flexibility > > Due to the wide variety of flow attributes collected by different > network flow attribute measurement systems, the ideal flow storage > format will not impose a single data model or a specific record type > on the flows it stores. The file format must be flexible and > extensible; that is, it must support the definition of multiple > record types within the file itself, and must be able to support new > field types for data within the records in a graceful way. > > IPFIX provides record format flexibility through the use of Templates > to describe each Data Record, through the use of an IANA Registry to > define its Information Elements, and through the use of enterprise- > specific Information Elements. > > 5.2. Self Description > > Archived data may be read at a time in the future where any external > reference to the meaning of the data may be lost. The ideal flow > storage format should be self-describing; that is, a process reading > flow data from storage should be able to properly interpret the > stored flows without reference to anything other than standard > sources (e.g., the standards document describing the file format) and > the stored flow data itself. > > The IPFIX Message format is partially self-describing; that is, IPFIX > Templates containing only IANA-assigned Information Elements can be > completely interpreted according to the IPFIX Information Model > without additional external data. > > However, Templates containing private information elements lack > detailed type and semantic information; a Collecting Process > receiving data described by a template containing private Information > Elements it does not understand can only treat the data contained > within those Information Elements as octet arrays. To be fully self- > describing, enterprise-specific Information Elements must be > additionally described via IPFIX Options according to the Information > Element Type Options Template defined in "Exporting Type Information > > > > Trammell, et al. Expires January 15, 2009 [Page 10] > > Internet-Draft IPFIX Files July 2008 > > > for IPFIX Information Elements" [I-D.ietf-ipfix-exporting-type]. > > 5.3. Data Compression > > Regardless of the representation format, flow data describing traffic > on real networks tends to be highly compressible. Compression tends > to improve the scalability of flow collection systems, by reducing > the disk storage and I/O bandwidth requirement for a given workload. > The ideal flow storage format should support applications which wish > to leverage this fact by supporting compression of stored data. > > The IPFIX Message format has no support for data compression, as the > IPFIX protocol was designed for speed and simplicity of export. Of > course, any flat file is readily compressible using a wide variety of > external data compression tools, formats, and algorithms; therefore, > this requirement can be met externally. > > However, a couple of simple optimizations can be made by File Writers > to increase the integrity and usability of compressed IPFIX data; > these are outlined in Section 9.1. > > 5.4. Indexing and Searching > > Binary, record stream oriented file formats natively support only one > form of searching, sequential scan in file order. By choosing the > order of records in a file carefully (e.g., by flow start or flow end > time), a fi can be indexed by a single key. > > Beyond this, properly addressing indexing is an application-specific > problem, as it inherently involves tradeoffs between storage > complexity and retrieval speed, and requirements vary widely based on > time scales and the types of queries used from site to site. > However, a generic standard flow storage format may provide limited > direct support for indexing and searching. > > The ideal flow storage format will support a limited table of > contents facility noting that the records in a file contain data > relating only to certain keys or values of keys, in order to keep > multi-file search implementations from having to scan a file for data > it does not contain. > > The IPFIX Message format has no direct support for indexing. > However, its template mechanism and the technique described in > "Reducing Redundancy in IPFIX and PSAMP Reports" > [I-D.ietf-ipfix-reducing-redundancy] can be used to describe the > contents of a file in a limited way. Additionally, as flow data is > often sorted and divided by time, the start and end time of the flows > in a file may be declared using the File Time Window Options Template > > > > Trammell, et al. Expires January 15, 2009 [Page 11] > > Internet-Draft IPFIX Files July 2008 > > > defined in Section 8.1.2. > > 5.5. Data Integrity > > When storing flow data over long time scales, especially for archival > purposes, it is important to ensure that hardware or software faults > do not introduce errors into the data over time. The ideal flow > storage format will support the detection and correction of encoding- > level errors in the data. > > Note that more advanced error correction is almost certainly best > handled at a layer below that addressed by this document. Error > correction is a topic well addressed by the storage industry in > general (e.g. by RAID and other technologies), and by specifying a > flow storage format based upon files, we can leverage these features > to meet this requirement. > > However, the ideal flow storage format will be resilient against > errors, providing an internal facility for the detection of errors > and the ability to isolate errors to as few data records as possible. > > Note that this requirement interacts with the choice of data > compression or encryption algorithm. The use of block compression > algorithms can serve to isolate errors to a single compression block, > unlike stream compressors, which may fail to resynchronize after a > single bit error, invalidating the entire message stream. Similarly, > the use of a stream cipher can serve to isolate errors in the > plaintext without amplifying them as, for example, a cipher in CBC > mode can. See the "Recommended Compression Error Resilience > Strategy" and "Recommended Encryption Error Resilience Strategy" > sections below for more on this interaction. > > The IPFIX Message format does not support data integrity assurance. > It is assumed that advanced error correction will be provided > externally. For simple error detection support, checksums may be > attached to messages via IPFIX Options according to the Message > Checksum Options Template defined in Section 8.1.1. > > 5.6. Creator Authentication and Confidentiality > > Storage of flow data across long time scales may also require > assurance that no unauthorized entity can read or modify the stored > data. Asymmetric-key cryptography can be applied to this problem, by > signing flow data with the private key of the creator, and encrypting > it with the public keys of those authorized to read it. The ideal > flow storage format will support the encryption and signing of flow > data. > > > > > Trammell, et al. Expires January 15, 2009 [Page 12] > > Internet-Draft IPFIX Files July 2008 >le can be indexed by a single key. > > Beyond this, properly addressing indexing is an application-specific > problem, as it inherently involves tradeoffs between storage > complexity and retrieval speed, and requirements vary widely based on > time scales and the types of queries used from site to site. > However, a generic standard flow storage format may provide limited > direct support for indexing and searching. > > The ideal flow storage format will support a limited table of > contents facility noting that the records in a file contain data > relating only to certain keys or values of keys, in order to keep > multi-file search implementations from having to scan a file for data > it does not contain. > > The IPFIX Message format has no direct support for indexing. > However, its template mechanism and the technique described in > "Reducing Redundancy in IPFIX and PSAMP Reports" > [I-D.ietf-ipfix-reducing-redundancy] can be used to describe the > contents of a file in a limited way. Additionally, as flow data is > often sorted and divided by time, the start and end time of the flows > in a file may be declared using the File Time Window Options Template > > > > Trammell, et al. Expires January 15, 2009 [Page 11] > > Internet-Draft IPFIX Files July 2008 > > > defined in Section 8.1.2. > > 5.5. Data Integrity > > When storing flow data over long time scales, especially for archival > purposes, it is important to ensure that hardware or software faults > do not introduce errors into the data over time. The ideal flow > storage format will support the detection and correction of encoding- > level errors in the data. > > Note that more advanced error correction is almost certainly best > handled at a layer below that addressed by this document. Error > correction is a topic well addressed by the storage industry in > general (e.g. by RAID and other technologies), and by specifying a > flow storage format based upon files, we can leverage these features > to meet this requirement. > > However, the ideal flow storage format will be resilient against > errors, providing an internal facility for the detection of errors > and the ability to isolate errors to as few data records as possible. > > Note that this requirement interacts with the choice of data > compression or encryption algorithm. The use of block compression > algorithms can serve to isolate errors to a single compression block, > unlike stream compressors, which may fail to resynchronize after a > single bit error, invalidating the entire message stream. Similarly, > the use of a stream cipher can serve to isolate errors in the > plaintext without amplifying them as, for example, a cipher in CBC > mode can. See the "Recommended Compression Error Resilience > Strategy" and "Recommended Encryption Error Resilience Strategy" > sections below for more on this interaction. > > The IPFIX Message format does not support data integrity assurance. > It is assumed that advanced error correction will be provided > externally. For simple error detection support, checksums may be > attached to messages via IPFIX Options according to the Message > Checksum Options Template defined in Section 8.1.1. > > 5.6. Creator Authentication and Confidentiality > > Storage of flow data across long time scales may also require > assurance that no unauthorized entity can read or modify the stored > data. Asymmetric-key cryptography can be applied to this problem, by > signing flow data with the private key of the creator, and encrypting > it with the public keys of those authorized to read it. The ideal > flow storage format will support the encryption and signing of flow > data. > > > > > Trammell, et al. Expires January 15, 2009 [Page 12] > > Internet-Draft IPFIX Files July 2008 > > As with error correction, this problem has been addressed well at a > layer below that addressed by this document. Instead of specifying a > particular choice of encryption technology, we can leverage the fact > that existing cryptographic technologies work quite well on data > stored in files to meet this requirement. > > Beyond support for the use of TLS for transport over TCP or DTLS for > transport over SCTP or UDP, both of which provide transient > authentication and confidentiality, the IPFIX protocol does not > support this requirement directly. It is assumed that this > requirement will be met externally. > > 5.7. Anonymization and Obfuscation > > To ensure the privacy of individuals and organizations at the > endpoints of communications represented by flow records, it is often > necessary to obfuscate or anonymize stored and exported flow data. > The ideal flow storage format will provide for a notation that a > given information element on a given record type represents > anonymized, rather than real, data. > > The IPFIX Message format presently has no support for anonymization > notation. It should be noted that anonymization is one of the > requirements given for IPFIX in [RFC3917]. The decision to qualify > this requirement with 'MAY' and not 'MUST' in the requirements > document, and its subsequent lack of specification in the current > version of the IPFIX protocol, is due to the fact that anonymization > algorithms are still an open area of research, and that there > currently exist no standardized methods for anonymization. > > No support is presently defined in [RFC5101] or this IPFIX-based File > Format for anonymization, as anonymization notation is an area of > open work for the IPFIX working group. > > 5.8. Session Auditability and Replayability > > Certain use cases for archival flow storage require the storage of > collection infrastructure details alongside the data itself. These > details include information about how and when data was received, and > where it was received from, and are useful for auditing as well as > for the replaying received data for testing purposes. > > The IPFIX Message format contains no direct support for auditability > and replayability, though the IPFIX Information Model does define > various Information Elements required to represent collection > infrastructure details. These details may be stored in IPFIX Files > using the Export Session Details Options Template defined in > Section 8.1.3 and the Message Details Options Template defined in > > > > Trammell, et al. Expires January 15, 2009 [Page 13] > > Internet-Draft IPFIX Files July 2008 > > > Section 8.1.4. > > 5.9. Performance Characteristics > > The ideal standard flow storage format will not have a significant > negative impact on the performance of the application generating or > processing flow data stored in the format. This is a non-functional > requirement, but it is important to note that a standard that implies > a significant performance penalty is unlikely to be widely > implemented and adopted. > > A static analysis of the IPFIX Message format would seem to suggest > that implementations of it are not particularly prone to slowness; > indeed, a template-based data representation is more easily subject > to optimization for common cases than representations that embed > structural information directly in the data stream (e.g. XML). > However, a full analysis of the impact of using IPFIX Messages as a > basis for flow data storage on read/write performance will require > more implementation experience and performance measurement. > > > 6. Applicability > > This section describes the specific applicability of IPFIX Files to > various use cases. IPFIX Files are particularly useful in a flow > collection and processing infrastructure using IPFIX > > > As with error correction, this problem has been addressed well at a > layer below that addressed by this document. Instead of specifying a > particular choice of encryption technology, we can leverage the fact > that existing cryptographic technologies work quite well on data > stored in files to meet this requirement. > > Beyond support for the use of TLS for transport over TCP or DTLS for > transport over SCTP or UDP, both of which provide transient > authentication and confidentiality, the IPFIX protocol does not > support this requirement directly. It is assumed that this > requirement will be met externally. > > 5.7. Anonymization and Obfuscation > > To ensure the privacy of individuals and organizations at the > endpoints of communications represented by flow records, it is often > necessary to obfuscate or anonymize stored and exported flow data. > The ideal flow storage format will provide for a notation that a > given information element on a given record type represents > anonymized, rather than real, data. > > The IPFIX Message format presently has no support for anonymization > notation. It should be noted that anonymization is one of the > requirements given for IPFIX in [RFC3917]. The decision to qualify > this requirement with 'MAY' and not 'MUST' in the requirements > document, and its subsequent lack of specification in the current > version of the IPFIX protocol, is due to the fact that anonymization > algorithms are still an open area of research, and that there > currently exist no standardized methods for anonymization. > > No support is presently defined in [RFC5101] or this IPFIX-based File > Format for anonymization, as anonymization notation is an area of > open work for the IPFIX working group. > > 5.8. Session Auditability and Replayability > > Certain use cases for archival flow storage require the storage of > collection infrastructure details alongside the data itself. These > details include information about how and when data was received, and > where it was received from, and are useful for auditing as well as > for the replaying received data for testing purposes. > > The IPFIX Message format contains no direct support for auditability > and replayability, though the IPFIX Information Model does define > various Information Elements required to represent collection > infrastructure details. These details may be stored in IPFIX Files > using the Export Session Details Options Template defined in > Section 8.1.3 and the Message Details Options Template defined in > > > > Trammell, et al. Expires January 15, 2009 [Page 13] > > Internet-Draft IPFIX Files July 2008 > > > Section 8.1.4. > > 5.9. Performance Characteristics > > The ideal standard flow storage format will not have a significant > negative impact on the performance of the application generating or > processing flow data stored in the format. This is a non-functional > requirement, but it is important to note that a standard that implies > a significant performance penalty is unlikely to be widely > implemented and adopted. > > A static analysis of the IPFIX Message format would seem to suggest > that implementations of it are not particularly prone to slowness; > indeed, a template-based data representation is more easily subject > to optimization for common cases than representations that embed > structural information directly in the data stream (e.g. XML). > However, a full analysis of the impact of using IPFIX Messages as a > basis for flow data storage on read/write performance will require > more implementation experience and performance measurement. > > > 6. Applicability > > This section describes the specific applicability of IPFIX Files to > various use cases. IPFIX Files are particularly useful in a flow > collection and processing infrastructure using IPF for flow export. > We explore the applicability and provide guidelines for using IPFIX > files for the storage of flow data collected by IPFIX Collecting > Processes and NetFlow V9 collectors, the testing of IPFIX Collecting > Processes, and diagnostics of IPFIX Devices. > > 6.1. Storage of IPFIX-collected Flow Data > > IPFIX Files can naturally be used to store flow data collected by an > IPFIX Collecting Process; indeed, this was one of the primary initial > motivations behind the file format described within this document. > Using IPFIX Files as such provides a single, standard, well- > understood encoding to be used for flow data on disk and on the wire, > and allows IPFIX implementations to leverage substantially the same > code for flow export and flow storage. In addition, the storage of > single Transport Sessions in IPFIX Files is particularly important > for network measurement research, allowing repeatability of > experiments by providing a format for the storage and exchange of > IPFIX flow trace data much as the libpcap format is used for > experiments on packet trace data. > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 14] > > Internet-Draft IPFIX Files July 2008 > > > 6.2. Storage of NetFlow V9-collected Flow Data > > Although the IPFIX protocol is based on the Cisco Netflow Services, > Version 9 (NetFlow V9) protocol [RFC3954], the two have diverged > since work began on IPFIX. However, since the NetFlow V9 information > model is a compatible subset of the IPFIX information model, it is > possible to use IPFIX files to store collected NetFlow V9 flow data. > This approach may be particularly useful in multi-vendor, multi- > protocol collection infrastructures using both NetFlow V9 and IPFIX > to export flow data. > > The applicability of IPFIX Files to this use case is outlined in > Appendix B. Is it important or even necessary to differentiate IPFIX and v9 data in the file? Though you have collectorProtocolVersion, is the original transport protocol so important? > 6.3. Testing IPFIX Collecting Processes > > IPFIX Files can be used to store IPFIX Messages for the testing of > IPFIX Collecting Processes. A variety of test cases may be stored in > IPFIX Files. First, IPFIX data sets collected in real network > environments and stored in an IPFIX File can be used as input to > check the behavior of new or extended implementations of IPFIX > Collectors. Furthermore, IPFIX Files can be used to validate the > operation of a given IPFIX Collecting Process in a new environment, > i.e., to test with recorded IPFIX data from the target network before > installing the Collecting Process in the network. > > The IPFIX File format can also be used to store artificial, non- > compliant reference messages for specific Collecting Process test > cases. Examples for such test cases are sets of IPFIX records with > undefined Information Elements, Data Records described by missing > Templates, or incorrectly framed messages or data sets. > Representative error handling test cases are defined in "IPFIX > Testing" [I-D.ietf-ipfix-testing]. > > Furthermore, fast replay of IPFIX records stored in a file can be > used for stress/load tests (e.g., high rate of incoming Data Records, > large Templates with high Information Element counts), as described > in "IPFIX Testing" [I-D.ietf-ipfix-testing]. The provisioning and > use of a set of reference files for testing simplifies the > performance of tests and increases the comparability of test results. > > 6.4. IPFIX Device Diagnostics > > As an IPFIX File can be used store any collection of flows, the > format may also be used for dumping and storing various types of flow > data for IPFIX Device diagnostics (e.g., the open flow cache of a > Metering Process or the flow backlog of an Exporting or Collecting > Process at thIX for flow export. > We explore the applicability and provide guidelines for using IPFIX > files for the storage of flow data collected by IPFIX Collecting > Processes and NetFlow V9 collectors, the testing of IPFIX Collecting > Processes, and diagnostics of IPFIX Devices. > > 6.1. Storage of IPFIX-collected Flow Data > > IPFIX Files can naturally be used to store flow data collected by an > IPFIX Collecting Process; indeed, this was one of the primary initial > motivations behind the file format described within this document. > Using IPFIX Files as such provides a single, standard, well- > understood encoding to be used for flow data on disk and on the wire, > and allows IPFIX implementations to leverage substantially the same > code for flow export and flow storage. In addition, the storage of > single Transport Sessions in IPFIX Files is particularly important > for network measurement research, allowing repeatability of > experiments by providing a format for the storage and exchange of > IPFIX flow trace data much as the libpcap format is used for > experiments on packet trace data. > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 14] > > Internet-Draft IPFIX Files July 2008 > > > 6.2. Storage of NetFlow V9-collected Flow Data > > Although the IPFIX protocol is based on the Cisco Netflow Services, > Version 9 (NetFlow V9) protocol [RFC3954], the two have diverged > since work began on IPFIX. However, since the NetFlow V9 information > model is a compatible subset of the IPFIX information model, it is > possible to use IPFIX files to store collected NetFlow V9 flow data. > This approach may be particularly useful in multi-vendor, multi- > protocol collection infrastructures using both NetFlow V9 and IPFIX > to export flow data. > > The applicability of IPFIX Files to this use case is outlined in > Appendix B. Is it important or even necessary to differentiate IPFIX and v9 data in the file? Though you have collectorProtocolVersion, is the original transport protocol so important? > 6.3. Testing IPFIX Collecting Processes > > IPFIX Files can be used to store IPFIX Messages for the testing of > IPFIX Collecting Processes. A variety of test cases may be stored in > IPFIX Files. First, IPFIX data sets collected in real network > environments and stored in an IPFIX File can be used as input to > check the behavior of new or extended implementations of IPFIX > Collectors. Furthermore, IPFIX Files can be used to validate the > operation of a given IPFIX Collecting Process in a new environment, > i.e., to test with recorded IPFIX data from the target network before > installing the Collecting Process in the network. > > The IPFIX File format can also be used to store artificial, non- > compliant reference messages for specific Collecting Process test > cases. Examples for such test cases are sets of IPFIX records with > undefined Information Elements, Data Records described by missing > Templates, or incorrectly framed messages or data sets. > Representative error handling test cases are defined in "IPFIX > Testing" [I-D.ietf-ipfix-testing]. > > Furthermore, fast replay of IPFIX records stored in a file can be > used for stress/load tests (e.g., high rate of incoming Data Records, > large Templates with high Information Element counts), as described > in "IPFIX Testing" [I-D.ietf-ipfix-testing]. The provisioning and > use of a set of reference files for testing simplifies the > performance of tests and increases the comparability of test results. > > 6.4. IPFIX Device Diagnostics > > As an IPFIX File can be used store any collection of flows, the > format may also be used for dumping and storing various types of flow > data for IPFIX Device diagnostics (e.g., the open flow cache of a > Metering Process or the flow backlog of an Exporting or Collecting > Process at e time of a process reset or crash). File-based storage > > > > Trammell, et al. Expires January 15, 2009 [Page 15] > > Internet-Draft IPFIX Files July 2008 > > > is preferable to remote transmission in such error-recovery > situations. > > > 7. Detailed Description > > An IPFIX File, as introduced in Section 3 and elaborated below, is at > its core simply an IPFIX Message stream serialized to some > filesystem. Any valid serialized IPFIX Message stream MUST be > accepted by a File Reader as a valid IPFIX file. In this way, the > filesystem is simply treated as another IPFIX transport alongside > SCTP, TCP, and UDP. In contrast to normal IPFIX operation, the time > between a File Writer writing an IPFIX Message stream to a File and a > File Reader reading it can be extremely variable. In other words, > this notional file transport has unusually high latency, as the File > Reader and File Writer do not necessarily run at the same time. > > This section specifies the detailed actions of File Readers and File > Writers in handling IPFIX Files, and further specifies actions of > File Writers in specific use cases. Unless otherwise specified > herein, where appropriate IPFIX File Writers MUST behave as IPFIX > Exporting Processes, and IPFIX File Readers MUST behave as IPFIX > Collecting Processes. > > 7.1. File Reader Specification > > An IPFIX File Reader MUST accept as valid any serialized IPFIX > Message stream that would be considered valid by one or more of the > other defined IPFIX transport layers. Practically, this means that > the union of template management features supported by SCTP, TCP, and > UDP MUST be supported in IPFIX Files. The following requirements > apply to IPFIX File Readers: > > o File Readers MUST accept IPFIX Messages containing Template Sets, > Options Template Sets, and Data Sets within the same message, as > with IPFIX over TCP or UDP. > > o File Readers MUST accept Template Sets that define templates > already defined within the file, as may occur with template > retransmission when using IPFIX over UDP as described in section > 10.3.6 of [RFC5101]. In the event of a conflict between a resent > definition and a previous definition, the File Reader MUST assume > that the new template replaces the old, as consistent with UDP > template expiration and ID reuse. > > o File Readers MUST accept Template Withdrawals as described in > section 8 of [RFC5101], provided that the Template to be withdrawn > is defined, as is the case with IPFIX over TCP and SCTP. > > > > Trammell, et al. Expires January 15, 2009 [Page 16] > > Internet-Draft IPFIX Files July 2008 > > > Note that some applications, particularly those storing large > collections of data over long periods of time, may benefit from the > ability to treat a collection of IPFIX Files as a single Transport > Session. A File Reader MAY be configurable to treat a collection of > Files (e.g., all the files in a directory) as a single Transport > Session. However, a File Reader MUST NOT treat a single IPFIX File > as containing multiple Transport Sessions. > > If an IPFIX File uses the technique described in "Reducing Redundancy > in IPFIX and PSAMP Reports" [I-D.ietf-ipfix-reducing-redundancy] AND > all of the non-Options Templates in the File contain the > commonPropertiesId Information Element, a File Reader MAY assume the > set of commonPropertiesId definitions provides a complete table of > contents for the File for searching purposes. > > 7.2. File Writer Specification > > While any valid serialized IPFIX Message stream is a valid IPFIX > File, the following recommendations will improve representation > simplicity and read performance in the general case, where possible. > > File Writers SHOULD emit eacthe time of a process reset or crash). File-based storage > > > > Trammell, et al. Expires January 15, 2009 [Page 15] > > Internet-Draft IPFIX Files July 2008 > > > is preferable to remote transmission in such error-recovery > situations. > > > 7. Detailed Description > > An IPFIX File, as introduced in Section 3 and elaborated below, is at > its core simply an IPFIX Message stream serialized to some > filesystem. Any valid serialized IPFIX Message stream MUST be > accepted by a File Reader as a valid IPFIX file. In this way, the > filesystem is simply treated as another IPFIX transport alongside > SCTP, TCP, and UDP. In contrast to normal IPFIX operation, the time > between a File Writer writing an IPFIX Message stream to a File and a > File Reader reading it can be extremely variable. In other words, > this notional file transport has unusually high latency, as the File > Reader and File Writer do not necessarily run at the same time. > > This section specifies the detailed actions of File Readers and File > Writers in handling IPFIX Files, and further specifies actions of > File Writers in specific use cases. Unless otherwise specified > herein, where appropriate IPFIX File Writers MUST behave as IPFIX > Exporting Processes, and IPFIX File Readers MUST behave as IPFIX > Collecting Processes. > > 7.1. File Reader Specification > > An IPFIX File Reader MUST accept as valid any serialized IPFIX > Message stream that would be considered valid by one or more of the > other defined IPFIX transport layers. Practically, this means that > the union of template management features supported by SCTP, TCP, and > UDP MUST be supported in IPFIX Files. The following requirements > apply to IPFIX File Readers: > > o File Readers MUST accept IPFIX Messages containing Template Sets, > Options Template Sets, and Data Sets within the same message, as > with IPFIX over TCP or UDP. > > o File Readers MUST accept Template Sets that define templates > already defined within the file, as may occur with template > retransmission when using IPFIX over UDP as described in section > 10.3.6 of [RFC5101]. In the event of a conflict between a resent > definition and a previous definition, the File Reader MUST assume > that the new template replaces the old, as consistent with UDP > template expiration and ID reuse. > > o File Readers MUST accept Template Withdrawals as described in > section 8 of [RFC5101], provided that the Template to be withdrawn > is defined, as is the case with IPFIX over TCP and SCTP. > > > > Trammell, et al. Expires January 15, 2009 [Page 16] > > Internet-Draft IPFIX Files July 2008 > > > Note that some applications, particularly those storing large > collections of data over long periods of time, may benefit from the > ability to treat a collection of IPFIX Files as a single Transport > Session. A File Reader MAY be configurable to treat a collection of > Files (e.g., all the files in a directory) as a single Transport > Session. However, a File Reader MUST NOT treat a single IPFIX File > as containing multiple Transport Sessions. > > If an IPFIX File uses the technique described in "Reducing Redundancy > in IPFIX and PSAMP Reports" [I-D.ietf-ipfix-reducing-redundancy] AND > all of the non-Options Templates in the File contain the > commonPropertiesId Information Element, a File Reader MAY assume the > set of commonPropertiesId definitions provides a complete table of > contents for the File for searching purposes. > > 7.2. File Writer Specification > > While any valid serialized IPFIX Message stream is a valid IPFIX > File, the following recommendations will improve representation > simplicity and read performance in the general case, where possible. > > File Writers SHOULD emit eh Template Set or Options Template Set to > appear in the file before any Data Set described by the Templates > within that Set, to ensure the File Reader can decode every Data Set > without waiting to process subsequent Templates or Options Templates. > > File Writers SHOULD emit Data Records described by Options Templates > to appear in the file before any Data Records which depend on the > scopes defined by those options. > > File Writers SHOULD use Template Withdrawals to withdraw Templates if > template IDs need to be reused. In this case, the new Templates > reusing those IDs SHOULD appear directly in the file after the > Template Withdrawals making the IDs available for reuse. Template > Withdrawals SHOULD NOT be used unless necessary to reuse template > IDs. You're saying that the writer should store up the TWM until a new template definition is received - and only then should it write the TWM immediately followed by the new template? Surely the writer should faithfully record the TWM as soon as it's seen? I think it's especially important wrt ipfix-export-per-sctp-stream. > Each IPFIX File is generally synonymous with a single Transport > Session. File Writers SHOULD store the Templates and Options > required to decode the data within the File in the File itself, and > File Readers SHOULD NOT use Templates or Options defined in one file > to decode or interpret Data Sets in another. > > File Writers SHOULD write IPFIX Messages within an IPFIX File in > ascending Export Time order. > > File Writers MAY write Data Records to an IPFIX File in any order. Obviously a different order would prevent the original data stream from being replayed. > However, File Writers that write flow records to an IPFIX File in > > > > Trammell, et al. Expires January 15, 2009 [Page 17] > > Internet-Draft IPFIX Files July 2008 > > > flowStartTime or flowEndTime order SHOULD be consistent in this > ordering within each File. > > 7.3. Specific File Writer Use Cases > > The specifications in this section apply to specific situations. > Each section below extends or modifies the base File Writer > specification in Section 7.2. Considerations for collocation of a > File Writer with IPFIX Collecting Processes and Metering Processes > are given, as are specific guidelines for using IPFIX Files for > archival storage, or as documents. Also covered are the use of IPFIX > Files in the testing and diagnostics of IPFIX Devices. > > 7.3.1. Collocating a File Writer with a Collecting Process > > When collocating a File Writer with an IPFIX Collecting Process for > archival storage of collected data in IPFIX Files as described in > Section 6.1, the following recommendations may improve the usefulness > of the stored data. > > The simplest way for a to store the data collected in a single > Transport Session is to simply write the incoming IPFIX Messages to > an IPFIX File as they are collected. However, the resulting files That seems to contradict the TWM in 7.2? > will lack information about the IPFIX Transport Session used to > export them, such as the network addresses of the Exporting and > Collecting Processes and the protocols used to transport them. In > this case, if information about the Transport Session is required, > the File Writer SHOULD store a single IPFIX Transport Session in an > IPFIX File and SHOULD record information about the Transport Session > using the Export Session Details Options Template described in > Section 8.1.3. > > Additional per-Message information MAY be recorded by the File Writer > using the Message Details Options Template described in > Section 8.1.4. Per-message information includes the time at which > each IPFIX Message was received at the Collecting Process, and can be > used to resend IPFIX Messages while keeping the original measurement > plane traffic profileach Template Set or Options Template Set to > appear in the file before any Data Set described by the Templates > within that Set, to ensure the File Reader can decode every Data Set > without waiting to process subsequent Templates or Options Templates. > > File Writers SHOULD emit Data Records described by Options Templates > to appear in the file before any Data Records which depend on the > scopes defined by those options. > > File Writers SHOULD use Template Withdrawals to withdraw Templates if > template IDs need to be reused. In this case, the new Templates > reusing those IDs SHOULD appear directly in the file after the > Template Withdrawals making the IDs available for reuse. Template > Withdrawals SHOULD NOT be used unless necessary to reuse template > IDs. You're saying that the writer should store up the TWM until a new template definition is received - and only then should it write the TWM immediately followed by the new template? Surely the writer should faithfully record the TWM as soon as it's seen? I think it's especially important wrt ipfix-export-per-sctp-stream. > Each IPFIX File is generally synonymous with a single Transport > Session. File Writers SHOULD store the Templates and Options > required to decode the data within the File in the File itself, and > File Readers SHOULD NOT use Templates or Options defined in one file > to decode or interpret Data Sets in another. > > File Writers SHOULD write IPFIX Messages within an IPFIX File in > ascending Export Time order. > > File Writers MAY write Data Records to an IPFIX File in any order. Obviously a different order would prevent the original data stream from being replayed. > However, File Writers that write flow records to an IPFIX File in > > > > Trammell, et al. Expires January 15, 2009 [Page 17] > > Internet-Draft IPFIX Files July 2008 > > > flowStartTime or flowEndTime order SHOULD be consistent in this > ordering within each File. > > 7.3. Specific File Writer Use Cases > > The specifications in this section apply to specific situations. > Each section below extends or modifies the base File Writer > specification in Section 7.2. Considerations for collocation of a > File Writer with IPFIX Collecting Processes and Metering Processes > are given, as are specific guidelines for using IPFIX Files for > archival storage, or as documents. Also covered are the use of IPFIX > Files in the testing and diagnostics of IPFIX Devices. > > 7.3.1. Collocating a File Writer with a Collecting Process > > When collocating a File Writer with an IPFIX Collecting Process for > archival storage of collected data in IPFIX Files as described in > Section 6.1, the following recommendations may improve the usefulness > of the stored data. > > The simplest way for a to store the data collected in a single > Transport Session is to simply write the incoming IPFIX Messages to > an IPFIX File as they are collected. However, the resulting files That seems to contradict the TWM in 7.2? > will lack information about the IPFIX Transport Session used to > export them, such as the network addresses of the Exporting and > Collecting Processes and the protocols used to transport them. In > this case, if information about the Transport Session is required, > the File Writer SHOULD store a single IPFIX Transport Session in an > IPFIX File and SHOULD record information about the Transport Session > using the Export Session Details Options Template described in > Section 8.1.3. > > Additional per-Message information MAY be recorded by the File Writer > using the Message Details Options Template described in > Section 8.1.4. Per-message information includes the time at which > each IPFIX Message was received at the Collecting Process, and can be > used to resend IPFIX Messages while keeping the original measurement > plane traffic profi. > > When collocating a File Writer with a Collecting Process, the Export > Time of each Message SHOULD be the Export Time of the Message > received by the Collecting Process containing the first Data Record > in the Message. Note that File Writers storing IPFIX data collected > from an IPFIX Collecting Process using SCTP as the transport protocol > SHOULD interleave messages from multiple streams in order to preserve > Export Time order, and SHOULD reorder the written messages as > necessary to ensure that each Template Set or Options Template Set > appears in the file before any Data Set described by the Templates > > > > Trammell, et al. Expires January 15, 2009 [Page 18] > > Internet-Draft IPFIX Files July 2008 > > > within that Set. > > 7.3.2. Collocating a File Writer with a Metering Process > > Note that File Writers may also be collocated directly with IPFIX > Metering Processes, for writing measured information directly to disk > without intermediate IPFIX Exporting or Collecting Processes. This > arrangement may be particularly useful when providing data to an > analysis environment with an IPFIX File based workflow, or when > testing Metering Processes during development. > > When collocating a File Writer with a Metering Process, note that > Information Elements associated with Exporting or Collecting > Processes are meaningless, and SHOULD NOT appear in the Export > Session Details Options Template described in Section 8.1.3 or the > Message Details Options Template described in Section 8.1.4. > > When collocating a File Writer with an Exporting Process, the Export > Time of each Message SHOULD be the time at which the first Data > Record in the Message was received from the Exporting Process. Ugh, you switched from discussing the MP to the EP? > > 7.3.3. Using IPFIX Files for Archival Storage > > While in the general case File Writers should store one Transport > Session per IPFIX File, some applications storing large collections > of data over long periods of time may benefit from the ability to > treat a collection of IPFIX Files as a single Transport Session. A > File Writer MAY be configurable to write data from a single Transport > Session into multiple IPFIX Files; however, File Writers supporting > such a configuration option MUST provide a configuration option to > support one-file-per-session behavior for interoperability purposes. > > File Writers compressing or encrypting archival data and File Readers > reading compressed or encrypted archival data SHOULD follow the > recommendations in Section 9. > > 7.3.4. Using IPFIX Files as Documents > > When IPFIX Files are used as documents, to store a set of flows > relevant to query, investigation, or other common context, or for the > publication of flow data sets relevant to network research, each File > MUST be readable as a single Transport Session, self-contained and > making no reference to metadata stored in separate Files, in order to > ensure interoperability. > > When writing Files to be used as documents, File Writers may emit the > special Data Records described by Options Templates before any other > Data Records in the File, in the following order, to ease the > > > > Trammell, et al. Expires January 15, 2009 [Page 19] > > Internet-Draft IPFIX Files July 2008 > > > inspection and use of documents by File Readers: > > o Time Window records described by the File Time Window Options > Template as defined in Section 8.1.2 below; followed by > > o commonPropertiesId definitions as described in "Reducing > Redundancy in IPFIX and PSAMP Reports" > [I-D.ietf-ipfix-reducing-redundancy]; followed by > > o Information Element Type Records as described in "Exporting Type > Information for IPFIX Information Elements" > [I-D.ietf-le. > > When collocating a File Writer with a Collecting Process, the Export > Time of each Message SHOULD be the Export Time of the Message > received by the Collecting Process containing the first Data Record > in the Message. Note that File Writers storing IPFIX data collected > from an IPFIX Collecting Process using SCTP as the transport protocol > SHOULD interleave messages from multiple streams in order to preserve > Export Time order, and SHOULD reorder the written messages as > necessary to ensure that each Template Set or Options Template Set > appears in the file before any Data Set described by the Templates > > > > Trammell, et al. Expires January 15, 2009 [Page 18] > > Internet-Draft IPFIX Files July 2008 > > > within that Set. > > 7.3.2. Collocating a File Writer with a Metering Process > > Note that File Writers may also be collocated directly with IPFIX > Metering Processes, for writing measured information directly to disk > without intermediate IPFIX Exporting or Collecting Processes. This > arrangement may be particularly useful when providing data to an > analysis environment with an IPFIX File based workflow, or when > testing Metering Processes during development. > > When collocating a File Writer with a Metering Process, note that > Information Elements associated with Exporting or Collecting > Processes are meaningless, and SHOULD NOT appear in the Export > Session Details Options Template described in Section 8.1.3 or the > Message Details Options Template described in Section 8.1.4. > > When collocating a File Writer with an Exporting Process, the Export > Time of each Message SHOULD be the time at which the first Data > Record in the Message was received from the Exporting Process. Ugh, you switched from discussing the MP to the EP? > > 7.3.3. Using IPFIX Files for Archival Storage > > While in the general case File Writers should store one Transport > Session per IPFIX File, some applications storing large collections > of data over long periods of time may benefit from the ability to > treat a collection of IPFIX Files as a single Transport Session. A > File Writer MAY be configurable to write data from a single Transport > Session into multiple IPFIX Files; however, File Writers supporting > such a configuration option MUST provide a configuration option to > support one-file-per-session behavior for interoperability purposes. > > File Writers compressing or encrypting archival data and File Readers > reading compressed or encrypted archival data SHOULD follow the > recommendations in Section 9. > > 7.3.4. Using IPFIX Files as Documents > > When IPFIX Files are used as documents, to store a set of flows > relevant to query, investigation, or other common context, or for the > publication of flow data sets relevant to network research, each File > MUST be readable as a single Transport Session, self-contained and > making no reference to metadata stored in separate Files, in order to > ensure interoperability. > > When writing Files to be used as documents, File Writers may emit the > special Data Records described by Options Templates before any other > Data Records in the File, in the following order, to ease the > > > > Trammell, et al. Expires January 15, 2009 [Page 19] > > Internet-Draft IPFIX Files July 2008 > > > inspection and use of documents by File Readers: > > o Time Window records described by the File Time Window Options > Template as defined in Section 8.1.2 below; followed by > > o commonPropertiesId definitions as described in "Reducing > Redundancy in IPFIX and PSAMP Reports" > [I-D.ietf-ipfix-reducing-redundancy]; followed by > > o Information Element Type Records as described in "Exporting Type > Information for IPFIX Information Elements" > [I-D.ietipfix-exporting-type]; followed by > > o Export Session details records described by the Export Session > Details Options Template as defined in Section 8.1.3 below. > > The Export Time of each Message within a File used as a document > SHOULD be the time at which the Message was written by the File > Writer. > > If an IPFIX File used as a document uses the technique described in > "Reducing Redundancy in IPFIX and PSAMP Reports" > [I-D.ietf-ipfix-reducing-redundancy] AND all of the non-Options > Templates in the File contain the commonPropertiesId Information > Element, a File Reader MAY assume the set of commonPropertiesId > definitions provides a complete table of contents for the File for > searching purposes. > > 7.3.5. Using IPFIX Files for Testing > > IPFIX Files can be used for testing IPFIX Collecting Processes in two > ways. First, IPFIX Files can be used to store specific flow data for > regression and stress testing of Collectors; there are no special > considerations for IPFIX Files used in this way. > > Second, IPFIX Files are useful for storing reference messages which > do not comply to the IPFIX Protocol in order to test the error > handling and recovery behavior of Collectors. Of course, IPFIX Files > intended to be used in this application necessarily MAY violate any > of of the specifications in this document or in [RFC5101], and such > files MUST NOT be transmitted to Collecting Processes or given as > input File Readers not under test. > > Note that an extremely simple IPFIX Exporting Process may be crafted > for testing purposes by simply reading an IPFIX File and transmitting > it directly to a Collecting Process. Similarly, an extremely simple > Collecting Process may be crafted for testing purposes by simply > accepting connections and/or IPFIX Messages from Exporting Processes > > > > Trammell, et al. Expires January 15, 2009 [Page 20] > > Internet-Draft IPFIX Files July 2008 > > > and writing the session's message stream to an IPFIX File. > > 7.3.6. Writing IPFIX Files for Device Diagnostics > > IPFIX Files can be used in the debugging of devices which use flow > data as internal state, as a common format for the representation of > flow tables. In such situations, the opaueOctets information element Que? > can be used to store additional non-IPFIX encoded, non-flow > information (e.g., stack backtraces, process state, etc.) within the > IPFIX File as in Section 10.1; the IPFIX flow table information could > also be embedded in a larger proprietary diagnostic format using > delimiters as in Section 10.2 > > > 8. File Format Metadata Specification > > This section defines the Options Templates used for IPFIX File > metadata, and the Information Elements they require. > > 8.1. Recommended Options Templates for IPFIX Files > > The following Options Templates allow IPFIX Message streams to meet > the requirements outlined above without extension to the message > format or protocol. They are defined in terms of existing > Information Elements defined in [RFC5102], the Information Elements > defined in "Exporting Type Information for IPFIX Information > Elements" [I-D.ietf-ipfix-exporting-type], as well as Information > Elements defined in Section 8.2. IPFIX File Readers and Writers > SHOULD support these options templates as defined below. > > In addition, IPFIX File Readers and Writers SHOULD support the > Options Templates defined in "Exporting Type Information for IPFIX > Information Elements" [I-D.ietf-ipfix-exporting-type] in order to > support self-description of enterprise-specific Information Elements. > > 8.1.1. Message Checksum Options Template > > The Message Checksum Options Template specifies the structure of a > Data Record for attaching an MD5 message checksum to an IPFIX > Message. An MD5 message checksum as described MAY be f-ipfix-exporting-type]; followed by > > o Export Session details records described by the Export Session > Details Options Template as defined in Section 8.1.3 below. > > The Export Time of each Message within a File used as a document > SHOULD be the time at which the Message was written by the File > Writer. > > If an IPFIX File used as a document uses the technique described in > "Reducing Redundancy in IPFIX and PSAMP Reports" > [I-D.ietf-ipfix-reducing-redundancy] AND all of the non-Options > Templates in the File contain the commonPropertiesId Information > Element, a File Reader MAY assume the set of commonPropertiesId > definitions provides a complete table of contents for the File for > searching purposes. > > 7.3.5. Using IPFIX Files for Testing > > IPFIX Files can be used for testing IPFIX Collecting Processes in two > ways. First, IPFIX Files can be used to store specific flow data for > regression and stress testing of Collectors; there are no special > considerations for IPFIX Files used in this way. > > Second, IPFIX Files are useful for storing reference messages which > do not comply to the IPFIX Protocol in order to test the error > handling and recovery behavior of Collectors. Of course, IPFIX Files > intended to be used in this application necessarily MAY violate any > of of the specifications in this document or in [RFC5101], and such > files MUST NOT be transmitted to Collecting Processes or given as > input File Readers not under test. > > Note that an extremely simple IPFIX Exporting Process may be crafted > for testing purposes by simply reading an IPFIX File and transmitting > it directly to a Collecting Process. Similarly, an extremely simple > Collecting Process may be crafted for testing purposes by simply > accepting connections and/or IPFIX Messages from Exporting Processes > > > > Trammell, et al. Expires January 15, 2009 [Page 20] > > Internet-Draft IPFIX Files July 2008 > > > and writing the session's message stream to an IPFIX File. > > 7.3.6. Writing IPFIX Files for Device Diagnostics > > IPFIX Files can be used in the debugging of devices which use flow > data as internal state, as a common format for the representation of > flow tables. In such situations, the opaueOctets information element Que? > can be used to store additional non-IPFIX encoded, non-flow > information (e.g., stack backtraces, process state, etc.) within the > IPFIX File as in Section 10.1; the IPFIX flow table information could > also be embedded in a larger proprietary diagnostic format using > delimiters as in Section 10.2 > > > 8. File Format Metadata Specification > > This section defines the Options Templates used for IPFIX File > metadata, and the Information Elements they require. > > 8.1. Recommended Options Templates for IPFIX Files > > The following Options Templates allow IPFIX Message streams to meet > the requirements outlined above without extension to the message > format or protocol. They are defined in terms of existing > Information Elements defined in [RFC5102], the Information Elements > defined in "Exporting Type Information for IPFIX Information > Elements" [I-D.ietf-ipfix-exporting-type], as well as Information > Elements defined in Section 8.2. IPFIX File Readers and Writers > SHOULD support these options templates as defined below. > > In addition, IPFIX File Readers and Writers SHOULD support the > Options Templates defined in "Exporting Type Information for IPFIX > Information Elements" [I-D.ietf-ipfix-exporting-type] in order to > support self-description of enterprise-specific Information Elements. > > 8.1.1. Message Checksum Options Template > > The Message Checksum Options Template specifies the structure of a > Data Record for attaching an MD5 message checksum to an IPFIX > Message. An MD5 message checksum as described MAY bused if long- > term data integrity is important to the application. The described > Data Record MUST appear only once per IPFIX Message, but MAY appear > anywhere within the Message. > > The template SHOULD contain the following Information Elements: > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 21] > > Internet-Draft IPFIX Files July 2008 > > > +--------------------+----------------------------------------------+ > | IE | Description | > +--------------------+----------------------------------------------+ > | messageScope | A marker denoting this Option applies to the | > | [scope] | whole IPFIX Message; content is ignored. | > | | This Information Element MUST be defined as | > | | a Scope Field. | > | messageMD5Checksum | The MD5 checksum of the containing IPFIX | > | | Message. | > +--------------------+----------------------------------------------+ > > 8.1.2. File Time Window Options Template > > The File Time Window Options Template specifies the structure of a > Data Record for attaching a time window to an IPFIX File; this Data > Record is referred to as a time window record. A time window record > defines the earliest flow start time and the latest flow end time of > the flow records within a File. One and only one time window record > MAY appear within an IPFIX File if the time window information is > available; a File Writer MUST NOT write more than one time window > record to an IPFIX File. A File Writer that writes a time window > record to a File MUST NOT write any Flow with a start time before the > beginning of the window or an end time after the end of the window to > that File. > > The template SHOULD contain the following Information Elements: > > +---------------------+---------------------------------------------+ > | IE | Description | > +---------------------+---------------------------------------------+ > | sessionScope | A marker denoting this Option applies to | > | [scope] | the whole IPFIX Transport Session (i.e., | > | | IPFIX File); content is ignored. This | > | | Information Element MUST be defined as a | > | | Scope Field. | > | minFlowStartSeconds | The start time of the earliest flow in the | > | | Transport Session (i.e., File) in epoch | > | | seconds. | > | maxFlowEndSeconds | The end time of the latest flow in the | > | | Transport Session (i.e., File) in epoch | > | | seconds. | > +---------------------+---------------------------------------------+ > > 8.1.3. Export Session Details Options Template > > The Export Session Details Options Template specifies the structure > of a Data Record for recording the details of an IPFIX Transport > Session in an IPFIX File. It is intended for use in storing a single > > > > Trammell, et al. Expires January 15, 2009 [Page 22] > > Internet-Draft IPFIX Files July 2008 > > > complete IPFIX Transport Session in a single IPFIX File. The > described Data Record SHOULD appear only once in a given IPFIX File. > > The template SHOULD contain the following Information Elements, > subject to applicability as noted on each Information Element: > > +----------------------------+--------------------------------------+ > | IE | Description | > +-----------------------e used if long- > term data integrity is important to the application. The described > Data Record MUST appear only once per IPFIX Message, but MAY appear > anywhere within the Message. > > The template SHOULD contain the following Information Elements: > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 21] > > Internet-Draft IPFIX Files July 2008 > > > +--------------------+----------------------------------------------+ > | IE | Description | > +--------------------+----------------------------------------------+ > | messageScope | A marker denoting this Option applies to the | > | [scope] | whole IPFIX Message; content is ignored. | > | | This Information Element MUST be defined as | > | | a Scope Field. | > | messageMD5Checksum | The MD5 checksum of the containing IPFIX | > | | Message. | > +--------------------+----------------------------------------------+ > > 8.1.2. File Time Window Options Template > > The File Time Window Options Template specifies the structure of a > Data Record for attaching a time window to an IPFIX File; this Data > Record is referred to as a time window record. A time window record > defines the earliest flow start time and the latest flow end time of > the flow records within a File. One and only one time window record > MAY appear within an IPFIX File if the time window information is > available; a File Writer MUST NOT write more than one time window > record to an IPFIX File. A File Writer that writes a time window > record to a File MUST NOT write any Flow with a start time before the > beginning of the window or an end time after the end of the window to > that File. > > The template SHOULD contain the following Information Elements: > > +---------------------+---------------------------------------------+ > | IE | Description | > +---------------------+---------------------------------------------+ > | sessionScope | A marker denoting this Option applies to | > | [scope] | the whole IPFIX Transport Session (i.e., | > | | IPFIX File); content is ignored. This | > | | Information Element MUST be defined as a | > | | Scope Field. | > | minFlowStartSeconds | The start time of the earliest flow in the | > | | Transport Session (i.e., File) in epoch | > | | seconds. | > | maxFlowEndSeconds | The end time of the latest flow in the | > | | Transport Session (i.e., File) in epoch | > | | seconds. | > +---------------------+---------------------------------------------+ > > 8.1.3. Export Session Details Options Template > > The Export Session Details Options Template specifies the structure > of a Data Record for recording the details of an IPFIX Transport > Session in an IPFIX File. It is intended for use in storing a single > > > > Trammell, et al. Expires January 15, 2009 [Page 22] > > Internet-Draft IPFIX Files July 2008 > > > complete IPFIX Transport Session in a single IPFIX File. The > described Data Record SHOULD appear only once in a given IPFIX File. > > The template SHOULD contain the following Information Elements, > subject to applicability as noted on each Information Element: > > +----------------------------+--------------------------------------+ > | IE | Description | > +--------------------------+--------------------------------------+ > | sessionScope [scope] | A marker denoting this Option | > | | applies to the whole IPFIX Transport | > | | Session (i.e., IPFIX File); content | > | | is ignored. This Information | > | | Element MUST be defined as a Scope | > | | Field. | > | exporterIPv4Address | IPv4 address of the IPFIX Exporting | > | | Process from which the Messages in | > | | this Transport Session were | > | | received. Present only for | > | | Exporting Processes with an IPv4 | > | | interface. For multi-homed SCTP | > | | associations, this SHOULD be the | > | | primary path endpoint address of the | > | | Exporting Process. | > | exporterIPv6Address | IPv6 address of the IPFIX Exporting | > | | Process from which the Messages in | > | | this Transport Session were | > | | received. Present only for | > | | Exporting Processes with an IPv6 | > | | interface. For multi-homed SCTP | > | | associations, this SHOULD be the | > | | primary path endpoint address of the | > | | Exporting Process. | > | exporterTransportPort | The source port from which the | > | | Messages in this Transport Session | > | | were received. | > | collectorIPv4Address | IPv4 address of the IPFIX Collecting | > | | Process which received the Messages | > | | in this Transport Session. Present | > | | only for Collecting Processes with | > | | an IPv4 interface. For multi-homed | > | | SCTP associations, this SHOULD be | > | | the primary path endpoint address of | > | | the Collecting Process. | > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 23] > > Internet-Draft IPFIX Files July 2008 > > > | collectorIPv6Address | IPv6 address of the IPFIX Collecting | > | | Process which received the Messages | > | | in this Transport Session. Present | > | | only for Collecting Processes with | > | | an IPv6 interface. For multi-homed | > | | SCTP associations, this SHOULD be | > | | the primary path endpoint address of | > | | the Collecting Process. | > | collectorTransportPort | The destination port on which the | > | | Messages in this Transport Session | > | | were received. | > | collectorTransportProtocol | The IP Protocol Identifier of the | > | | transport protocol used to transport | > | | Messages within this Transport | > | | Session. | > | collectorProtocolVersion | The version of the IPFIX Protocol | > | | used to -------+--------------------------------------+ > | sessionScope [scope] | A marker denoting this Option | > | | applies to the whole IPFIX Transport | > | | Session (i.e., IPFIX File); content | > | | is ignored. This Information | > | | Element MUST be defined as a Scope | > | | Field. | > | exporterIPv4Address | IPv4 address of the IPFIX Exporting | > | | Process from which the Messages in | > | | this Transport Session were | > | | received. Present only for | > | | Exporting Processes with an IPv4 | > | | interface. For multi-homed SCTP | > | | associations, this SHOULD be the | > | | primary path endpoint address of the | > | | Exporting Process. | > | exporterIPv6Address | IPv6 address of the IPFIX Exporting | > | | Process from which the Messages in | > | | this Transport Session were | > | | received. Present only for | > | | Exporting Processes with an IPv6 | > | | interface. For multi-homed SCTP | > | | associations, this SHOULD be the | > | | primary path endpoint address of the | > | | Exporting Process. | > | exporterTransportPort | The source port from which the | > | | Messages in this Transport Session | > | | were received. | > | collectorIPv4Address | IPv4 address of the IPFIX Collecting | > | | Process which received the Messages | > | | in this Transport Session. Present | > | | only for Collecting Processes with | > | | an IPv4 interface. For multi-homed | > | | SCTP associations, this SHOULD be | > | | the primary path endpoint address of | > | | the Collecting Process. | > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 23] > > Internet-Draft IPFIX Files July 2008 > > > | collectorIPv6Address | IPv6 address of the IPFIX Collecting | > | | Process which received the Messages | > | | in this Transport Session. Present | > | | only for Collecting Processes with | > | | an IPv6 interface. For multi-homed | > | | SCTP associations, this SHOULD be | > | | the primary path endpoint address of | > | | the Collecting Process. | > | collectorTransportPort | The destination port on which the | > | | Messages in this Transport Session | > | | were received. | > | collectorTransportProtocol | The IP Protocol Identifier of the | > | | transport protocol used to transport | > | | Messages within this Transport | > | | Session. | > | collectorProtocolVersion | The version of the IPFIX Protocol | > | | used ttransport Messages within | > | | this Transport Session. | The version of the IPFIX Protocol is always "10". Surely you mean "The version of the Export Protocol ..." ? :-) > | minExportSeconds | The Export Time of the first Message | > | | in the Transport Session. | > | maxExportSeconds | The Export Time of the last Message | > | | in the Transport Session. | > +----------------------------+--------------------------------------+ > > 8.1.4. Message Details Options Template > > The Message Details Options Template specifies the structure of a > Data Record for attaching additional export details to an IPFIX > Message. These details include the time at which a message was > received and information about the export and collection > infrastructure used to transport the Message. This Options Template > also allows the storage of the export session metadata provided the > Export Session Details Options Template, for storing information from > multiple Transport Sessions in the same IPFIX File. > > The template SHOULD contain the following Information Elements, > subject to applicability as noted for each Information Element. Note > that when used in conjunction with the Export Session Details Options > Template, when storing a single complete IPFIX Transport Session in > an IPFIX File, this template SHOULD contain only the messageScope and > collectionTimeMilliseconds Information Elements, and the > exportSctpStreamId Information Element for Messages transported via > SCTP. > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 24] > > Internet-Draft IPFIX Files July 2008 > > > +----------------------------+--------------------------------------+ > | IE | Description | > +----------------------------+--------------------------------------+ > | messageScope [scope] | A marker denoting this Option | > | | applies to the whole IPFIX message; | > | | content is ignored. This | > | | Information Element MUST be defined | > | | as a Scope Field. | > | collectionTimeMilliseconds | The absolute time at which this | > | | Message was received by the IPFIX | > | | Collecting Process. | > | exporterIPv4Address | IPv4 address of the IPFIX Exporting | > | | Process from which this Message was | > | | received. Present only for | > | | Exporting Processes with an IPv4 | > | | interface, and if this information | > | | is not available via the Export | > | | Session Details Options Template. | > | | For multi-homed SCTP associations, | > | | this SHOULD be the primary path | > | | endpoint address of the Exporting | > | | Process. | > | exporterIPv6Address | IPv6 address of the IPFIX Exporting | > | | Process this Message was received. | > | | Present only for Exporting Processes | > | | with an IPv6 interface, and if this | > | | information is not available via the | > | | Export Session Details Options | > | | Template. For multi-homed SCTP | > | o transport Messages within | > | | this Transport Session. | The version of the IPFIX Protocol is always "10". Surely you mean "The version of the Export Protocol ..." ? :-) > | minExportSeconds | The Export Time of the first Message | > | | in the Transport Session. | > | maxExportSeconds | The Export Time of the last Message | > | | in the Transport Session. | > +----------------------------+--------------------------------------+ > > 8.1.4. Message Details Options Template > > The Message Details Options Template specifies the structure of a > Data Record for attaching additional export details to an IPFIX > Message. These details include the time at which a message was > received and information about the export and collection > infrastructure used to transport the Message. This Options Template > also allows the storage of the export session metadata provided the > Export Session Details Options Template, for storing information from > multiple Transport Sessions in the same IPFIX File. > > The template SHOULD contain the following Information Elements, > subject to applicability as noted for each Information Element. Note > that when used in conjunction with the Export Session Details Options > Template, when storing a single complete IPFIX Transport Session in > an IPFIX File, this template SHOULD contain only the messageScope and > collectionTimeMilliseconds Information Elements, and the > exportSctpStreamId Information Element for Messages transported via > SCTP. > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 24] > > Internet-Draft IPFIX Files July 2008 > > > +----------------------------+--------------------------------------+ > | IE | Description | > +----------------------------+--------------------------------------+ > | messageScope [scope] | A marker denoting this Option | > | | applies to the whole IPFIX message; | > | | content is ignored. This | > | | Information Element MUST be defined | > | | as a Scope Field. | > | collectionTimeMilliseconds | The absolute time at which this | > | | Message was received by the IPFIX | > | | Collecting Process. | > | exporterIPv4Address | IPv4 address of the IPFIX Exporting | > | | Process from which this Message was | > | | received. Present only for | > | | Exporting Processes with an IPv4 | > | | interface, and if this information | > | | is not available via the Export | > | | Session Details Options Template. | > | | For multi-homed SCTP associations, | > | | this SHOULD be the primary path | > | | endpoint address of the Exporting | > | | Process. | > | exporterIPv6Address | IPv6 address of the IPFIX Exporting | > | | Process this Message was received. | > | | Present only for Exporting Processes | > | | with an IPv6 interface, and if this | > | | information is not available via the | > | | Export Session Details Options | > | | Template. For multi-homed SCTP | > | | associations, this SHOULD be the | > | | primary path endpoint address of the | > | | Exporting Process. | > | exporterTransportPort | The source port from which this | > | | Message received. Present only if | > | | this information is not available | > | | via the Export Session Details | > | | Options Template. | > | collectorIPv4Address | IPv4 address of the IPFIX Collecting | > | | Process which received this Message. | > | | Present only for Collecting | > | | Processes with an IPv4 interface, | > | | and if this information is not | > | | available via the Export Session | > | | Details Options Template. For | > | | multi-homed SCTP associations, this | > | | SHOULD be the primary path endpoint | > | | address of the Collecting Process. | > > > > > Trammell, et al. Expires January 15, 2009 [Page 25] > > Internet-Draft IPFIX Files July 2008 > > > | collectorIPv6Address | IPv6 address of the IPFIX Collecting | > | | Process which received this Message. | > | | Present only for Collecting | > | | Processes with an IPv6 interface, | > | | and if this information is not | > | | available via the Export Session | > | | Details Options Template. For | > | | multi-homed SCTP associations, this | > | | SHOULD be the primary path endpoint | > | | address of the Collecting Process. | > | collectorTransportPort | The destination port on which this | > | | Message was received. Present only | > | | if this information is not available | > | | via the Export Session Details | > | | Options Template. | > | collectorTransportProtocol | The IP Protocol Identifier of the | > | | transport protocol used to transport | > | | this Message. Present only if this | > | | information is not available via the | > | | Export Session Details Options | > | | Template. | > | collectorProtocolVersion | The version of the IPFIX Protocol | > | | used to transport this Message. | Again, you probably meant "The version of the Export Protocol ..." ? > | | Present only if this information is | > | | not available via the Export Session | > | | Details Options Template. | > | exportSctpStreamId | The SCTP stream used to transport | > | | this Message. Present only if the | > | | Message was transported via SCTP. | > +----------------------------+--------------------------------------+ > > 8.2. Recommended Information Elements for IPFIX Files > > The following Information Elements are used by the options templates > in Section 8.1 to allow IPFIX Message streams to meet the > requirements outlined above without extension of the message format > | associations, this SHOULD be the | > | | primary path endpoint address of the | > | | Exporting Process. | > | exporterTransportPort | The source port from which this | > | | Message received. Present only if | > | | this information is not available | > | | via the Export Session Details | > | | Options Template. | > | collectorIPv4Address | IPv4 address of the IPFIX Collecting | > | | Process which received this Message. | > | | Present only for Collecting | > | | Processes with an IPv4 interface, | > | | and if this information is not | > | | available via the Export Session | > | | Details Options Template. For | > | | multi-homed SCTP associations, this | > | | SHOULD be the primary path endpoint | > | | address of the Collecting Process. | > > > > > Trammell, et al. Expires January 15, 2009 [Page 25] > > Internet-Draft IPFIX Files July 2008 > > > | collectorIPv6Address | IPv6 address of the IPFIX Collecting | > | | Process which received this Message. | > | | Present only for Collecting | > | | Processes with an IPv6 interface, | > | | and if this information is not | > | | available via the Export Session | > | | Details Options Template. For | > | | multi-homed SCTP associations, this | > | | SHOULD be the primary path endpoint | > | | address of the Collecting Process. | > | collectorTransportPort | The destination port on which this | > | | Message was received. Present only | > | | if this information is not available | > | | via the Export Session Details | > | | Options Template. | > | collectorTransportProtocol | The IP Protocol Identifier of the | > | | transport protocol used to transport | > | | this Message. Present only if this | > | | information is not available via the | > | | Export Session Details Options | > | | Template. | > | collectorProtocolVersion | The version of the IPFIX Protocol | > | | used to transport this Message. | Again, you probably meant "The version of the Export Protocol ..." ? > | | Present only if this information is | > | | not available via the Export Session | > | | Details Options Template. | > | exportSctpStreamId | The SCTP stream used to transport | > | | this Message. Present only if the | > | | Message was transported via SCTP. | > +----------------------------+--------------------------------------+ > > 8.2. Recommended Information Elements for IPFIX Files > > The following Information Elements are used by the options templates > in Section 8.1 to allow IPFIX Message streams to meet the > requirements outlined above without extension of the message format > or protocol. IPFIX File Readers and Writers SHOULD support these > Information Elements as defined below. > > In addition, IPFIX File Readers and Writers SHOULD support the > Information Elements defined in "Exporting Type Information for IPFIX > Information Elements" [I-D.ietf-ipfix-exporting-type] in order to > support full self-description of Information Elements. > > 8.2.1. collectionTimeMilliseconds > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 26] > > Internet-Draft IPFIX Files July 2008 > > > Description: The absolute timestamp at which the data within the > scope containing this Information Element was received by a > Collecting Process. This Information Element SHOULD be bound to > its containing IPFIX Message via IPFIX Options and the > messageScope Information Element, as defined below. > > Abstract Data Type: dateTimeMilliseconds > > ElementId: TBD1 > > Status: current > > 8.2.2. exportSctpStreamId > > Description: The value of the SCTP Stream Identifier used by the > Exporting Process for exporting IPFIX Message data. This is > carried in the Stream Identifier field of the header of the SCTP > DATA chunk containing the IPFIX Message(s). > > Abstract Data Type: unsigned16 > > Data Type Semantics: identifier > > ElementId: TBD2 > > Status: current > > 8.2.3. maxExportSeconds > > Description: The absolute Export Time of the latest IPFIX Message > within the scope containing this Information Element. This > Information Element SHOULD be bound to its containing IPFIX > Transport Session (i.e., File) via an options record and the > sessionScope Information Element, as defined below, and SHOULD > appear only once in a given IPFIX File. > > Abstract Data Type: dateTimeSeconds > > ElementId: TBD3 > > Status: current > > Units: seconds > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 27] > > Internet-Draft IPFIX Files July 2008 > > > 8.2.4. maxFlowEndSeconds > > Description: The latest absolute timestamp of the last packet > within any Flow within the scope containing this Information > Element, rounded up to the second. This Information Element > SHOULD be bound to its containing IPFIX Transport Session (i.e., > File) via an IPFIX Options and the sessionScope Information "record" -------------------------^ P. > Element, as defined below, and SHOULD appear only once in a given > IPFIX File. > > Abstract Data Type: dateTimeSeconds > > ElementId: TBD4 > > Status: current > > Units: seconds > > 8.2.5. messageMD5Checksum > > Description: The MD5 checksum of the IPFIX Message containing this > record. This Information Element SHOULD be bound to its > containing IPFIX Message via an options record and the > messageScope Information Element, as defined below, and SHOULD > appear only once in a given IPFIX Message. To calculate the value > of this Information Element, first buffer the containing IPFIX > Message, setting the value of this Information Element to all > zeroes. Then caluclate the MD5 checksum of the resulting buffer > as defined in [RFC1321], place the resulting value in this > Information Element, and export the buffered message. > > Abstract Data Type: octetArray (16 bytes) > > ElementId: TBD5 > > Status: current > > Reference: RFC 1321, The MD5 Message-Digest Algorithm [RFC1321] > > 8.2.6. messageScope > > Description: The presence of this Information Element as scope in > an Options Template signifies that the options described by the > Template apply to the IPFIX Message that contains them. It is > defined for general purpose message scoping of options, and > proposed speci or protocol. IPFIX File Readers and Writers SHOULD support these > Information Elements as defined below. > > In addition, IPFIX File Readers and Writers SHOULD support the > Information Elements defined in "Exporting Type Information for IPFIX > Information Elements" [I-D.ietf-ipfix-exporting-type] in order to > support full self-description of Information Elements. > > 8.2.1. collectionTimeMilliseconds > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 26] > > Internet-Draft IPFIX Files July 2008 > > > Description: The absolute timestamp at which the data within the > scope containing this Information Element was received by a > Collecting Process. This Information Element SHOULD be bound to > its containing IPFIX Message via IPFIX Options and the > messageScope Information Element, as defined below. > > Abstract Data Type: dateTimeMilliseconds > > ElementId: TBD1 > > Status: current > > 8.2.2. exportSctpStreamId > > Description: The value of the SCTP Stream Identifier used by the > Exporting Process for exporting IPFIX Message data. This is > carried in the Stream Identifier field of the header of the SCTP > DATA chunk containing the IPFIX Message(s). > > Abstract Data Type: unsigned16 > > Data Type Semantics: identifier > > ElementId: TBD2 > > Status: current > > 8.2.3. maxExportSeconds > > Description: The absolute Export Time of the latest IPFIX Message > within the scope containing this Information Element. This > Information Element SHOULD be bound to its containing IPFIX > Transport Session (i.e., File) via an options record and the > sessionScope Information Element, as defined below, and SHOULD > appear only once in a given IPFIX File. > > Abstract Data Type: dateTimeSeconds > > ElementId: TBD3 > > Status: current > > Units: seconds > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 27] > > Internet-Draft IPFIX Files July 2008 > > > 8.2.4. maxFlowEndSeconds > > Description: The latest absolute timestamp of the last packet > within any Flow within the scope containing this Information > Element, rounded up to the second. This Information Element > SHOULD be bound to its containing IPFIX Transport Session (i.e., > File) via an IPFIX Options and the sessionScope Information "record" -------------------------^ P. > Element, as defined below, and SHOULD appear only once in a given > IPFIX File. > > Abstract Data Type: dateTimeSeconds > > ElementId: TBD4 > > Status: current > > Units: seconds > > 8.2.5. messageMD5Checksum > > Description: The MD5 checksum of the IPFIX Message containing this > record. This Information Element SHOULD be bound to its > containing IPFIX Message via an options record and the > messageScope Information Element, as defined below, and SHOULD > appear only once in a given IPFIX Message. To calculate the value > of this Information Element, first buffer the containing IPFIX > Message, setting the value of this Information Element to all > zeroes. Then caluclate the MD5 checksum of the resulting buffer > as defined in [RFC1321], place the resulting value in this > Information Element, and export the buffered message. > > Abstract Data Type: octetArray (16 bytes) > > ElementId: TBD5 > > Status: current > > Reference: RFC 1321, The MD5 Message-Digest Algorithm [RFC1321] > > 8.2.6. messageScope > > Description: The presence of this Information Element as scope in > an Options Template signifies that the options described by the > Template apply to the IPFIX Message that contains them. It is > defined for general purpose message scoping of options, and > proposed spefically to allow the attachment a checksum to a > message via IPFIX Options. The value of this Information Element > MUST be written as 0 by the File Writer or Exporting Process. The > > > > Trammell, et al. Expires January 15, 2009 [Page 28] > > Internet-Draft IPFIX Files July 2008 > > > value of this Information Element MUST be ignored by the File > Reader or the Collecting Process. > > Abstract Data Type: octet > > ElementId: TBD6 > > Status: current > > 8.2.7. minExportSeconds > > Description: The absolute Export Time of the earliest IPFIX Message > within the scope containing this Information Element. This > Information Element SHOULD be bound to its containing IPFIX > Transport Session (i.e., File) via an options record and the > sessionScope Information Element, as defined below, and SHOULD > appear only once in a given IPFIX File. > > Abstract Data Type: dateTimeSeconds > > ElementId: TBD7 > > Status: current > > Units: seconds > > 8.2.8. minFlowStartSeconds > > Description: The earliest absolute timestamp of the first packet > within any Flow within the scope containing this Information > Element, rounded down to the second. This Information Element > SHOULD be bound to its containing IPFIX Transport Session (i.e., > File) via an options record and the sessionScope Information > Element, as defined below, and SHOULD appear only once in a given > IPFIX File. > > Abstract Data Type: dateTimeSeconds > > ElementId: TBD8 > > Status: current > > Units: seconds > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 29] > > Internet-Draft IPFIX Files July 2008 > > > 8.2.9. opaqueOctets > > Description: This Information Element is used to encapsulate non- > IPFIX data into an IPFIX Message stream, for the purpose of > allowing a non-IPFIX data processor to store a data stream inline > within an IPFIX file. A Collecting Process or File Writer MUST > NOT try to interpret this binary data. This Information Element > differs from paddingOctets as its contents are meaningful in some > non-IPFIX context, while the contents of paddingOctets MUST be > 0x00 and are intended only for Information Element alignment. > > Abstract Data Type: octet > > ElementId: TBD9 > > Status: current > > 8.2.10. sessionScope > > Description: The presence of this Information Element as scope in > an Options Template signifies that the options described by the > Template apply to the IPFIX Transport Session that contains them. > Note that as all options are implicitly scoped to Transport > Session and Observation Domain, this Information Element is > equivalent to a "null" scope. It is defined for general purpose > session scoping of options, and proposed specifically to allow the > attachment of time window to a file via IPFIX Options. The value > of this Information Element MUST be written as 0 by the File > Writer or Exporting Process. The value of this Information > Element MUST be ignored by the File Reader or the Collecting > Process. > > Abstract Data Type: octet > > ElementId: TBD10 > > Status: current > > > 9. Recommended Error Resilience Strategies > > This section describes recommended methods for making IPFIX Files > resilient to errors during storage. It is intended primarily for > applications using IPFIX Files for long-term archival storage of flow > data. > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 30] > > Internet-Draft IPFIX Files July 2008 > > > 9.1. Compression Error Resilience > > Note that, since any file may be compressed and decompressed with a > cifically to allow the attachment a checksum to a > message via IPFIX Options. The value of this Information Element > MUST be written as 0 by the File Writer or Exporting Process. The > > > > Trammell, et al. Expires January 15, 2009 [Page 28] > > Internet-Draft IPFIX Files July 2008 > > > value of this Information Element MUST be ignored by the File > Reader or the Collecting Process. > > Abstract Data Type: octet > > ElementId: TBD6 > > Status: current > > 8.2.7. minExportSeconds > > Description: The absolute Export Time of the earliest IPFIX Message > within the scope containing this Information Element. This > Information Element SHOULD be bound to its containing IPFIX > Transport Session (i.e., File) via an options record and the > sessionScope Information Element, as defined below, and SHOULD > appear only once in a given IPFIX File. > > Abstract Data Type: dateTimeSeconds > > ElementId: TBD7 > > Status: current > > Units: seconds > > 8.2.8. minFlowStartSeconds > > Description: The earliest absolute timestamp of the first packet > within any Flow within the scope containing this Information > Element, rounded down to the second. This Information Element > SHOULD be bound to its containing IPFIX Transport Session (i.e., > File) via an options record and the sessionScope Information > Element, as defined below, and SHOULD appear only once in a given > IPFIX File. > > Abstract Data Type: dateTimeSeconds > > ElementId: TBD8 > > Status: current > > Units: seconds > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 29] > > Internet-Draft IPFIX Files July 2008 > > > 8.2.9. opaqueOctets > > Description: This Information Element is used to encapsulate non- > IPFIX data into an IPFIX Message stream, for the purpose of > allowing a non-IPFIX data processor to store a data stream inline > within an IPFIX file. A Collecting Process or File Writer MUST > NOT try to interpret this binary data. This Information Element > differs from paddingOctets as its contents are meaningful in some > non-IPFIX context, while the contents of paddingOctets MUST be > 0x00 and are intended only for Information Element alignment. > > Abstract Data Type: octet > > ElementId: TBD9 > > Status: current > > 8.2.10. sessionScope > > Description: The presence of this Information Element as scope in > an Options Template signifies that the options described by the > Template apply to the IPFIX Transport Session that contains them. > Note that as all options are implicitly scoped to Transport > Session and Observation Domain, this Information Element is > equivalent to a "null" scope. It is defined for general purpose > session scoping of options, and proposed specifically to allow the > attachment of time window to a file via IPFIX Options. The value > of this Information Element MUST be written as 0 by the File > Writer or Exporting Process. The value of this Information > Element MUST be ignored by the File Reader or the Collecting > Process. > > Abstract Data Type: octet > > ElementId: TBD10 > > Status: current > > > 9. Recommended Error Resilience Strategies > > This section describes recommended methods for making IPFIX Files > resilient to errors during storage. It is intended primarily for > applications using IPFIX Files for long-term archival storage of flow > data. > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 30] > > Internet-Draft IPFIX Files July 2008 > > > 9.1. Compression Error Resilience > > Note that, since any file may be compressed and decompressed with a variety of widely available tools implementing a variety of > compression standards (both specified and de facto), compression of > IPFIX File data can be accomplished externally. However, compression > at the file level is not particularly resilient to errors; in the > worst case, a single bit error in a stream-compressed file may result > in the loss of the entire file. > > To limit the impact of errors on the recoverability of compressed > data, we recommend the use of block compression where possible. > Ideally, the block compression algorithm should support the > identification and isolation of blocks containing errors; bzip2 is an > example of such a block compressor. > > Since the block boundary of a block-compressed IPFIX File may fall in > the middle of an IPFIX Message, resynchronization of an IPFIX Message > stream by a File Reader after a compression error requires some care. > The beginning of an IPFIX Message may be identified by its header > signature (the Version field of the Message Header, 0x00 0x0A, > followed by a 16-bit Message Length), but simply searching for the > first occurance of the Version field is insufficient, since these two > bytes may occur in valid IPFIX Template or Data Sets. > > Therefore, we propose the following algorithm for File Readers to > resynchronize an IPFIX Message Stream after skipping a compressed > block containing errors: > > 1. Search after the error for the first occurrence of the octet > string 0x00, 0x0A (the IPFIX Message Header Version field.) > > 2. Treat this field as the beginning of a candidate IPFIX Message. > Read the two bytes following the Version field as a Message > Length, and seek to that offset from the beginning of the > candidate IPFIX Message. > > 3. If the first two octets after the candidate IPFIX Message are > 0x00, 0x0A (i.e., the IPFIX Message Header Version field of the > next message in the stream), or if the end of the file is reached > precisely at the end of the candidate IPFIX Message, presume that > the candidate IPFIX Message is valid, and begin reading the IPFIX > File from the start of the candidate IPFIX Message. > > 4. If not, or if the seek reaches end-of-file or another block > containing errors before finding the end of the candidate > message, go back to step 1, starting the search two bytes from > the start of the candidate IPFIX Message. > > > > Trammell, et al. Expires January 15, 2009 [Page 31] > > Internet-Draft IPFIX Files July 2008 > > > The algorithm above will improperly identify a non-message as a > message approximately 1 in 2^32 times, assuming random IPFIX data. > It may be expanded to consider multiple candidate IPFIX Messages in > order to increase reliability. > > In applications (e.g. archival storage) in which error resilience is > very important, File Writers SHOULD use block compression algorithms, > and MAY attempt to align IPFIX Messages within compression blocks to > ease resynchronization after errors, if such is supported by the > chosen block compressor. File Readers SHOULD use the > resynchronization algorithm above to minimize data loss due to > compression errors. > > 9.2. Encryption Error Resilience > > File-level encryption has error resilience issues similar to file- > level compression. Single bit errors in the encrypted data stream > can result in unreadability of the entire remaining file, dependent > on the encryption method used. The use of CBC (Cipher Block > Chaining) mode, which suffers from this low error resilience, is > relatively common. > > In applications (e.g. archival storage) in which error resilience is > very important, File Writers SHOULD use a stream cipher, for example > a block cipher in OFB (Output Feedback) mode (often referred to as > stream mode) instead of modes lik> variety of widely available tools implementing a variety of > compression standards (both specified and de facto), compression of > IPFIX File data can be accomplished externally. However, compression > at the file level is not particularly resilient to errors; in the > worst case, a single bit error in a stream-compressed file may result > in the loss of the entire file. > > To limit the impact of errors on the recoverability of compressed > data, we recommend the use of block compression where possible. > Ideally, the block compression algorithm should support the > identification and isolation of blocks containing errors; bzip2 is an > example of such a block compressor. > > Since the block boundary of a block-compressed IPFIX File may fall in > the middle of an IPFIX Message, resynchronization of an IPFIX Message > stream by a File Reader after a compression error requires some care. > The beginning of an IPFIX Message may be identified by its header > signature (the Version field of the Message Header, 0x00 0x0A, > followed by a 16-bit Message Length), but simply searching for the > first occurance of the Version field is insufficient, since these two > bytes may occur in valid IPFIX Template or Data Sets. > > Therefore, we propose the following algorithm for File Readers to > resynchronize an IPFIX Message Stream after skipping a compressed > block containing errors: > > 1. Search after the error for the first occurrence of the octet > string 0x00, 0x0A (the IPFIX Message Header Version field.) > > 2. Treat this field as the beginning of a candidate IPFIX Message. > Read the two bytes following the Version field as a Message > Length, and seek to that offset from the beginning of the > candidate IPFIX Message. > > 3. If the first two octets after the candidate IPFIX Message are > 0x00, 0x0A (i.e., the IPFIX Message Header Version field of the > next message in the stream), or if the end of the file is reached > precisely at the end of the candidate IPFIX Message, presume that > the candidate IPFIX Message is valid, and begin reading the IPFIX > File from the start of the candidate IPFIX Message. > > 4. If not, or if the seek reaches end-of-file or another block > containing errors before finding the end of the candidate > message, go back to step 1, starting the search two bytes from > the start of the candidate IPFIX Message. > > > > Trammell, et al. Expires January 15, 2009 [Page 31] > > Internet-Draft IPFIX Files July 2008 > > > The algorithm above will improperly identify a non-message as a > message approximately 1 in 2^32 times, assuming random IPFIX data. > It may be expanded to consider multiple candidate IPFIX Messages in > order to increase reliability. > > In applications (e.g. archival storage) in which error resilience is > very important, File Writers SHOULD use block compression algorithms, > and MAY attempt to align IPFIX Messages within compression blocks to > ease resynchronization after errors, if such is supported by the > chosen block compressor. File Readers SHOULD use the > resynchronization algorithm above to minimize data loss due to > compression errors. > > 9.2. Encryption Error Resilience > > File-level encryption has error resilience issues similar to file- > level compression. Single bit errors in the encrypted data stream > can result in unreadability of the entire remaining file, dependent > on the encryption method used. The use of CBC (Cipher Block > Chaining) mode, which suffers from this low error resilience, is > relatively common. > > In applications (e.g. archival storage) in which error resilience is > very important, File Writers SHOULD use a stream cipher, for example > a block cipher in OFB (Output Feedback) mode (often referred to as > stream mode) instead of modes le CBC when encrypting, since errors > are not amplified by stream ciphers: A single-bit error in the > ciphertext results in a single bit error in the plaintext. > Alternatively File Writers SHOULD use any other cipher which can > resynchronize after bit errors. An example is a block cipher in CBC > mode that is reinitialized after a specific amount of data has been > encrypted. The maximum data loss per bit-error is then up to the > next reinitialization point. In this case, File Writers SHOULD also > use the Message Checksum Options Template to attach a checksum to > each IPFIX Message in the IPFIX File, in order to support the > recognition of errors in the decrypted data. > > > 10. Recommended File Integration Strategies > > This section describes methods for integrating IPFIX File data with > other file formats. > > 10.1. Encapsulation of Non-IPFIX Data in IPFIX Files > > At times it may be useful to export or store non-IPFIX data inline in > an IPFIX File or Message stream. To do this cleanly, this data must > be encapsulated into IPFIX Messages so that an IPFIX File Reader or > > > > Trammell, et al. Expires January 15, 2009 [Page 32] > > Internet-Draft IPFIX Files July 2008 > > > Collecting Process can handle it without any need to interpret it. > At the same time, this data must not be changed during transmission > or storage. The opaqueOctets Information Element as defined in > Section 8.2.9 is provided for this encapsulation. > > Processing the encapsulated non-IPFIX data is left to a separate > processing mechanisms that can identify encapsulated non-IPFIX data > in an IPFIX message stream, but need not have any other IPFIX > handling capability, except the ability to skip over all IPFIX > messages that do not encapsulate non-IPFIX data. > > The Message Checksum Options Template, described in Section 8.1.1 may > be used as a uniform mechanism to identify errors within encapsulated > data. > > Note that this mechanism can only encapsulate data objects up to > 65,515 octets in length. If the space available in one IPFIX Message > is not enough for the amount of data to be encapsulated, then the > data must be broken into smaller segments that are encapsulated into > consecutive IPFIX Messages. Any additional structuring or semantics > of the raw data is outside the scope of IPFIX and must be implemented > within the encapsulated binary data itself. Furthermore, the raw > encapsulated data cannot be assumed by an IPFIX File Reader to have > any specific format. > > 10.2. Encapsulation of IPFIX Files within Other File Formats > > Consequently, it may also be useful to reverse the encapsulation, > that is, to export or store IPFIX data inline within a non-IPFIX file > or data stream. This makes sense when the other file format is not > compatible with the encapsulation described above in Section 10.1. > Generally speaking, the encapsulation here will be specific to the > format of the containing file. For example, IPFIX files may be > embedded in XML elements using hex or Base64 encoding, or in raw > binary files using start and end delimiters or some form of run- > length encoding. As there are as many potential encapsulations here > as there are potential file formats, the specifics of each are out of > scope for this specification. > > > 11. Security Considerations > > The IPFIX-based file format itself does not directly introduce > security issues. Rather it is used to store information which may > for privacy or business reasons be considered sensitive. The file > format must therefore provide appropriate procedures to guarantee the > integrity and confidentiality of the stored information. > > > > > Trammell, et al. Expires January 15, 2009 [Page 33] > > Internet-Draft IPFIX Files July 2008 > > > ike CBC when encrypting, since errors > are not amplified by stream ciphers: A single-bit error in the > ciphertext results in a single bit error in the plaintext. > Alternatively File Writers SHOULD use any other cipher which can > resynchronize after bit errors. An example is a block cipher in CBC > mode that is reinitialized after a specific amount of data has been > encrypted. The maximum data loss per bit-error is then up to the > next reinitialization point. In this case, File Writers SHOULD also > use the Message Checksum Options Template to attach a checksum to > each IPFIX Message in the IPFIX File, in order to support the > recognition of errors in the decrypted data. > > > 10. Recommended File Integration Strategies > > This section describes methods for integrating IPFIX File data with > other file formats. > > 10.1. Encapsulation of Non-IPFIX Data in IPFIX Files > > At times it may be useful to export or store non-IPFIX data inline in > an IPFIX File or Message stream. To do this cleanly, this data must > be encapsulated into IPFIX Messages so that an IPFIX File Reader or > > > > Trammell, et al. Expires January 15, 2009 [Page 32] > > Internet-Draft IPFIX Files July 2008 > > > Collecting Process can handle it without any need to interpret it. > At the same time, this data must not be changed during transmission > or storage. The opaqueOctets Information Element as defined in > Section 8.2.9 is provided for this encapsulation. > > Processing the encapsulated non-IPFIX data is left to a separate > processing mechanisms that can identify encapsulated non-IPFIX data > in an IPFIX message stream, but need not have any other IPFIX > handling capability, except the ability to skip over all IPFIX > messages that do not encapsulate non-IPFIX data. > > The Message Checksum Options Template, described in Section 8.1.1 may > be used as a uniform mechanism to identify errors within encapsulated > data. > > Note that this mechanism can only encapsulate data objects up to > 65,515 octets in length. If the space available in one IPFIX Message > is not enough for the amount of data to be encapsulated, then the > data must be broken into smaller segments that are encapsulated into > consecutive IPFIX Messages. Any additional structuring or semantics > of the raw data is outside the scope of IPFIX and must be implemented > within the encapsulated binary data itself. Furthermore, the raw > encapsulated data cannot be assumed by an IPFIX File Reader to have > any specific format. > > 10.2. Encapsulation of IPFIX Files within Other File Formats > > Consequently, it may also be useful to reverse the encapsulation, > that is, to export or store IPFIX data inline within a non-IPFIX file > or data stream. This makes sense when the other file format is not > compatible with the encapsulation described above in Section 10.1. > Generally speaking, the encapsulation here will be specific to the > format of the containing file. For example, IPFIX files may be > embedded in XML elements using hex or Base64 encoding, or in raw > binary files using start and end delimiters or some form of run- > length encoding. As there are as many potential encapsulations here > as there are potential file formats, the specifics of each are out of > scope for this specification. > > > 11. Security Considerations > > The IPFIX-based file format itself does not directly introduce > security issues. Rather it is used to store information which may > for privacy or business reasons be considered sensitive. The file > format must therefore provide appropriate procedures to guarantee the > integrity and confidentiality of the stored information. > > > > > Trammell, et al. Expires January 15, 2009 [Page 33] > > Internet-Draft IPFIX Files July 2008 > > > The underlying protocol used to exchange the information that will be > stored using the format proposed in this document must as well apply > appropriate procedures to guarantee the integrity and confidentiality > of the exported information. Such issues are addressed in [RFC5101]. > > Implementors of IPFIX File Writers which store data taken from an > IPFIX Collecting Process using TLS or DTLS for transport security > should note that IPFIX Files may present a potential breach of > confidentiality if IPFIX data collected using TLS or DTLS is stored > in unencrypted files, and should consider providing an external file > encryption option to mitigate this risk. > > > 12. IANA Considerations > > This document specifies the creation of several new IPFIX Information > Elements in the IPFIX Information Element registry located at > http://www.iana.org/assignments/ipfix, as defined in Section 8.2 > above. IANA has assigned the following Information Element numbers > for their respective Information Elements as specified below: > > o Information Element number TBD1 for the collectionTimeMilliseconds > Information Element. > > o Information Element number TBD2 for the exportSctpStreamId > Information Element. > > o Information Element number TBD3 for the maxExportSeconds > Information Element. > > o Information Element number TBD4 for the maxFlowEndSeconds > Information Element. > > o Information Element number TBD5 for the messageMD5Checksum > Information Element. > > o Information Element number TBD6 for the messageScope Information > Element. > > o Information Element number TBD7 for the minExportSeconds > Information Element. > > o Information Element number TBD8 for the minFlowStartSeconds > Information Element. > > o Information Element number TBD9 for the opaqueOctets Information > Element. > > > > > Trammell, et al. Expires January 15, 2009 [Page 34] > > Internet-Draft IPFIX Files July 2008 > > > o Information Element number TBD10 for the sessionScope Information > Element. > > [NOTE for IANA: The text TBDn should be replaced with the respective > assigned Information Element numbers where they appear in this > document.] > > > 13. Acknowledgements > > Thanks to Maurizio Molina, Tom Kosnar, and Andreas Kind for technical > assistance with the requirements for a standard flow storage format. > Thanks to Benoit Claise, Paul Aitken, and Andrew Johnson for their > reviews and feedback. > > > 14. References > > 14.1. Normative References > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > RFC 5102, January 2008. > > [I-D.ietf-ipfix-reducing-redundancy] > Boschi, E., "Reducing Redundancy in IP Flow Information > Export (IPFIX) and Packet Sampling (PSAMP) Reports", > draft-ietf-ipfix-reducing-redundancy-04 (work in > progress), May 2007. > > [I-D.ietf-ipfix-exporting-type] > Boschi, E., Trammell, B., Mark, L., and T. Zseby, > "Exporting Type Information for IPFIX Information > Elements", draft-ietf-ipfix-exporting-type-01 (work in > progress), February 2008. > > [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, > April 1992. > > 14.2. Informative References > > [I-D.ietf-ipfix-arch] > Sadasivan, G. and N. Brownlee, "Architecture Model for IP > Flow Information Export", draft-ietf-ipfix-arch-02 (work > > > > Trammell, et al. Expires January 15, 2009 [Pag The underlying protocol used to exchange the information that will be > stored using the format proposed in this document must as well apply > appropriate procedures to guarantee the integrity and confidentiality > of the exported information. Such issues are addressed in [RFC5101]. > > Implementors of IPFIX File Writers which store data taken from an > IPFIX Collecting Process using TLS or DTLS for transport security > should note that IPFIX Files may present a potential breach of > confidentiality if IPFIX data collected using TLS or DTLS is stored > in unencrypted files, and should consider providing an external file > encryption option to mitigate this risk. > > > 12. IANA Considerations > > This document specifies the creation of several new IPFIX Information > Elements in the IPFIX Information Element registry located at > http://www.iana.org/assignments/ipfix, as defined in Section 8.2 > above. IANA has assigned the following Information Element numbers > for their respective Information Elements as specified below: > > o Information Element number TBD1 for the collectionTimeMilliseconds > Information Element. > > o Information Element number TBD2 for the exportSctpStreamId > Information Element. > > o Information Element number TBD3 for the maxExportSeconds > Information Element. > > o Information Element number TBD4 for the maxFlowEndSeconds > Information Element. > > o Information Element number TBD5 for the messageMD5Checksum > Information Element. > > o Information Element number TBD6 for the messageScope Information > Element. > > o Information Element number TBD7 for the minExportSeconds > Information Element. > > o Information Element number TBD8 for the minFlowStartSeconds > Information Element. > > o Information Element number TBD9 for the opaqueOctets Information > Element. > > > > > Trammell, et al. Expires January 15, 2009 [Page 34] > > Internet-Draft IPFIX Files July 2008 > > > o Information Element number TBD10 for the sessionScope Information > Element. > > [NOTE for IANA: The text TBDn should be replaced with the respective > assigned Information Element numbers where they appear in this > document.] > > > 13. Acknowledgements > > Thanks to Maurizio Molina, Tom Kosnar, and Andreas Kind for technical > assistance with the requirements for a standard flow storage format. > Thanks to Benoit Claise, Paul Aitken, and Andrew Johnson for their > reviews and feedback. > > > 14. References > > 14.1. Normative References > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", RFC 5101, January 2008. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > RFC 5102, January 2008. > > [I-D.ietf-ipfix-reducing-redundancy] > Boschi, E., "Reducing Redundancy in IP Flow Information > Export (IPFIX) and Packet Sampling (PSAMP) Reports", > draft-ietf-ipfix-reducing-redundancy-04 (work in > progress), May 2007. > > [I-D.ietf-ipfix-exporting-type] > Boschi, E., Trammell, B., Mark, L., and T. Zseby, > "Exporting Type Information for IPFIX Information > Elements", draft-ietf-ipfix-exporting-type-01 (work in > progress), February 2008. > > [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, > April 1992. > > 14.2. Informative References > > [I-D.ietf-ipfix-arch] > Sadasivan, G. and N. Brownlee, "Architecture Model for IP > Flow Information Export", draft-ietf-ipfix-arch-02 (work > > > > Trammell, et al. Expires January 15, 2009 [Pe 35] > > Internet-Draft IPFIX Files July 2008 > > > in progress), October 2003. > > [I-D.ietf-ipfix-as] > Zseby, T., "IPFIX Applicability", draft-ietf-ipfix-as-12 > (work in progress), July 2007. > > [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export > Using IP Flow Information Export (IPFIX)", RFC 5103, > January 2008. > > [I-D.ietf-ipfix-testing] > Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP > Flow Information eXport (IPFIX) Testing", > draft-ietf-ipfix-testing-05 (work in progress), > April 2008. > > [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version > 9", RFC 3954, October 2004. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export (IPFIX)", > RFC 3917, October 2004. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [SAINT2007] > Trammell, B., Boschi, E., Mark, L., and T. Zseby, > "Requirements for a standardized flow storage solution", > in Proceedings of the SAINT 2007 workshop on Internet > Measurement Technology, Hiroshima, Japan, January 2007. > > > Appendix A. Example IPFIX File > > In this section we will explore an example IPFIX File which > demonstrates the various features of the IPFIX File format. This > file contains flow records described by a single Template. This file > also contains a File Time Window record to note the start and end > time of the data, and an Export Session Details record to record > collection infrastructure information. Each Message within this File > also contains a Message Checksum record, as this file may be > externally encrypted and/or stored as an archive. The structure of > this file is shown in Figure 2. > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 36] > > Internet-Draft IPFIX Files July 2008 > > > +=================================================+ > | IPFIX Message seq. 0 | > | +---------------------------------------------+ | > | | Template Set (id 2) 1 rec | | > | | Data Tmpl. id 256 | | > | +---------------------------------------------+ | > | | Options Template Set (id 3) 3 recs | | > | | File Time Window Opt. Tmpl. id 257 | | > | | Message Checksum Opt. Tmpl. id 259 | | > | | Export Session Details Opt. Tmpl. id 258 | | > | +---------------------------------------------+ | > | | Data Set (id 259) [Message Checksum] 1 rec | | > | +---------------------------------------------+ | > +=================================================+ > | IPFIX Message seq. 1 | > | +---------------------------------------------+ | > | | Data Set (id 257) [File Time Window] 1 rec | | > | +---------------------------------------------+ | > | | Data Set (id 258) [Export Session] 1 rec | | > | +---------------------------------------------+ | > | | Data Set (id 259) [Message Checksum] 1 rec | | > | +---------------------------------------------+ | > +=================================================+ > | IPFIX Message seq. 4 | > | +---------------------------------------------+ | > | | Data Set (id 256) 50 recs | | > | | contains flow data | | > age 35] > > Internet-Draft IPFIX Files July 2008 > > > in progress), October 2003. > > [I-D.ietf-ipfix-as] > Zseby, T., "IPFIX Applicability", draft-ietf-ipfix-as-12 > (work in progress), July 2007. > > [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export > Using IP Flow Information Export (IPFIX)", RFC 5103, > January 2008. > > [I-D.ietf-ipfix-testing] > Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP > Flow Information eXport (IPFIX) Testing", > draft-ietf-ipfix-testing-05 (work in progress), > April 2008. > > [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version > 9", RFC 3954, October 2004. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export (IPFIX)", > RFC 3917, October 2004. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [SAINT2007] > Trammell, B., Boschi, E., Mark, L., and T. Zseby, > "Requirements for a standardized flow storage solution", > in Proceedings of the SAINT 2007 workshop on Internet > Measurement Technology, Hiroshima, Japan, January 2007. > > > Appendix A. Example IPFIX File > > In this section we will explore an example IPFIX File which > demonstrates the various features of the IPFIX File format. This > file contains flow records described by a single Template. This file > also contains a File Time Window record to note the start and end > time of the data, and an Export Session Details record to record > collection infrastructure information. Each Message within this File > also contains a Message Checksum record, as this file may be > externally encrypted and/or stored as an archive. The structure of > this file is shown in Figure 2. > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 36] > > Internet-Draft IPFIX Files July 2008 > > > +=================================================+ > | IPFIX Message seq. 0 | > | +---------------------------------------------+ | > | | Template Set (id 2) 1 rec | | > | | Data Tmpl. id 256 | | > | +---------------------------------------------+ | > | | Options Template Set (id 3) 3 recs | | > | | File Time Window Opt. Tmpl. id 257 | | > | | Message Checksum Opt. Tmpl. id 259 | | > | | Export Session Details Opt. Tmpl. id 258 | | > | +---------------------------------------------+ | > | | Data Set (id 259) [Message Checksum] 1 rec | | > | +---------------------------------------------+ | > +=================================================+ > | IPFIX Message seq. 1 | > | +---------------------------------------------+ | > | | Data Set (id 257) [File Time Window] 1 rec | | > | +---------------------------------------------+ | > | | Data Set (id 258) [Export Session] 1 rec | | > | +---------------------------------------------+ | > | | Data Set (id 259) [Message Checksum] 1 rec | | > | +---------------------------------------------+ | > +=================================================+ > | IPFIX Message seq. 4 | > | +---------------------------------------------+ | > | | Data Set (id 256) 50 recs | | > | | contains flow data | | > | +---------------------------------------------+ | > | | Data Set (id 259) [Message Checksum] 1 rec | | > | +---------------------------------------------+ | > +=================================================+ > | IPFIX Message seq. 55 | > | . . . | > > Figure 2: File Example Structure > > The template describing the data records contains a flow start > timestamp, an IPv4 5-tuple, and packet and octet total counts. The > Template Set defining this is as shown in Figure 3 below: > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 37] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 40 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 256 | Field Count = 8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| flowStartSeconds = 150 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| dest.IPv4Address = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceTransportPort = 7 | Field Length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| dest.TransportPort = 11 | Field Length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| protocolIdentifier = 4 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| octetTotalCount = 85 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| packetTotalCount = 86 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 3: File Example Data Template > > A.1. Example Options Templates > > This is followed by an Options Template Set containing the options > templates required to read the File: the File Time Window Options > Template defined in Section 8.1.2 above, the Export Session Details > Options Template defined in Section 8.1.3 above, and the Message > Checksum Options Template defined in Section 8.1.1 above. This > Options Template Set is shown in Figure 4 and Figure 5 below: > > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 38] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 3 | Length = 80 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 257 | Field Count = 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope Field Count = 1 |0| sessionScope = TBD10 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 1 |0| minFlowStartSeconds = TBD8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| maxFlowEndSeconds = TBD4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 | Template ID = 259 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Count = 2 | Scope Field Count = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| messageScope = TBD6 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| messageMD5Checksum = TBD5 | Field Length = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 4: File Example Options Templates (Time Window and Checksum) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 39] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 258 | Field Count = 9 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope Field Count = 1 |0| sessionScope = TBD10 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 1 |0| exporterIPv4Address = 130 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| collectorIPv4Address = 211 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| exporterTransportPort = 217 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 2 |0| col.TransportPort = 216 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 2 |0| col.TransportProtocol = 215 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 1 |0| col.ProtocolVersion = 214 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 1 |0| minExportSeconds = TBD7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| maxExportSeconds = TBD3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 | set padding (2 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 5: File Example Options Templates, Continued (Session Details) > > A.2. Example Supplemental Options Data > > Following the templates required to decode the file is the > supplemental options information used to describe the file's contents > and type information. First comes the File Time Window record; it > notes that the file contains data from 9 October 2007 between > 00:01:13 and 23:56:27 UTC, and appears as in Figure 6: > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 40] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 257 | Length = 13 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sessionScope | minFlowStartSeconds > | 0 | 2007-10-09 00:01:13 UTC . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | maxFlowEndSeconds > . . . | 2007-10-09 23:56:27 UTC . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > . . . | > +-+-+-+-+-+-+-+-+ > > Figure 6: File Example Time Window > > This is followed by information about how the data in the file was > collected, in the Export Session Details record. This record notes > that the session stored in this file was sent via SCTP from an > exporter at 192.0.2.30 port 32769 to an collector at 192.0.2.40 port > 4739, and contains messages exported between 00:01:57 and 23:57:12 > UTC on 9 October 2007; it is represented in its Data Set as in > Figure 7: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 41] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 258 | Length = 27 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sessionScope | exporterIPv4Address > | 0 | 192.0.2.30 . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | collectorIPv4Address > . . . | 192.0.2.31 . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | exporterTransportPort | cTPort > . . . | 32769 | 4739 . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | cTProtocol | cPVersion | > . . . | 132 | 10 | . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > minExportSeconds | > . . . 2007-10-09 00:01:57 UTC | . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > maxExportSeconds | > . . . 2007-10-09 23:57:12 UTC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 7: File Example Export Session Details > > A.3. Example Message Checksum > > Each IPFIX Message within the file is completed with a Message > Checksum record; the structure of this record within its Data Set is > as in Figure 8: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 259 | Length = 24 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | messageScope | | > | 0 | | > +-+-+-+-+-+-+-+-+ | > | messageMD5Checksum | > | (16 byte MD5 checksum of options message) | > | | > | | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | set padding (3 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 8: File Example Message Checksum > > > > Trammell, et al. Expires January 15, 2009 [Page 42] > > Internet-Draft IPFIX Files July 2008 > > > A.4. File Example Data Set > > After the templates and supplemental options information comes the > data itself. The first record of an example Data Set is shown with > its message and set headers in Figure 9: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version = 10 | Length = 1296 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Export Time = 2007-10-09 00:01:57 UTC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Observation Domain ID = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 256 | Length = 1254 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | flowStartSeconds | > | 2007-10-09 00:01:13 UTC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceIPv4Address | > | 192.0.2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | destinationIPv4Address | > | 192.0.2.3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceTransportPort | destinationTransportPort | > | 32770 | 80 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | protocolId | totalOctetCount > | 6 | 18000 . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | totalPacketCount > . . . | 65 . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (49 more records) > . . . | > +-+-+-+-+-+-+-+-+ > > Figure 9: File Example Data Set > > A.5. Complete File Example > > Bringing together the examples above and adding message headers as > appropriate, a hex dump of the first 317 bytes of the example file > constructed above would appear as in the annotated Figure 10 below. > > > > Trammell, et al. Expires January 15, 2009 [Page 43] > > Internet-Draft IPFIX Files July 2008 > > > [EDITOR'S NOTE: In this figure, xx refers to unassigned IANA IE > numbers as in the IANA Considerations section above; cs refers to > message checksum bytes that depend on the rest of the message > contents. These will have to be replaced if we keep this example > once the IE numbers are assigned.] > > 0:|00 0A 00 A0 47 0A B6 E5 00 00 00 00 00 00 00 01 > [^ first message header (length 160 bytes) --> > 16:|00 02 00 28 01 00 00 08 00 96 00 04 00 08 00 04 > [^ data template set --> > 32: 00 0C 00 04 00 07 00 02 00 0B 00 02 00 04 00 01 > > 48: 00 55 00 04 00 56 00 04|00 03 00 50 01 01 00 03 > [^ opt template set --> > 64: 00 01 xx xx 00 01 xx xx 00 04 xx xx 00 04 01 03 > > 80: 00 02 00 01 xx xx 00 01 xx xx 00 10 01 02 00 09 > > 96: 00 01 xx xx 00 01 00 82 00 04 00 D3 00 04 00 D9 > > 112: 00 02 00 D8 00 02 00 D7 00 01 00 D0 00 01 xx xx > > 128: 00 04 xx xx 00 04 00 00|01 03 00 18 00 cs cs cs > [^ checksum record --> > 144: cs cs cs cs cs cs cs cs cs cs cs cs cs 00 00 00 > > 176:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01 > [^ second message header (length 80 bytes) --> > 192:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02 > [^ time window rec -> [ session detail rec ^ --> > 208: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84 > > 224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 cs > [ message checksum rec ^ --> > 240: cs cs cs cs cs cs cs cs cs cs cs cs cs cs cs 00 > > 256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 > [^ third message header (length 1296 bytes) --> > 272:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03 > [^ set hdr ][^ first data rec --> > 288: 80 02 00 50 06 00 00 46 50 00 00 00 41 > > Figure 10: File Example Hex Dump > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 44] > > Internet-Draft IPFIX Files July 2008 > > > Appendix B. Applicability of IPFIX Files to NetFlow V9 flow storage > > As the IPFIX Message format is nearly a superset of the NetFlow V9 > packet format, IPFIX Files can be used for store NetFlow V9 data > relatively easily. This section describes a method for doing so. > The differences between the two protocols are outlined in > Appendix B.1 below. A simple, lightweight, message-for-message > translation method for transforming V9 Packets into IPFIX Messages > for storage within IPFIX Files is described in Appendix B.2. An > example of this translation method is given in Appendix B.3. > > B.1. Comparing NetFlow V9 to IPFIX > > With a few caveats, the IPFIX Protocol is a superset of the NetFlow > V9 protocol, having evolved from it largely through a process of > feature addition to bring it into compliance with the IPFIX > Requirements and the needs of stakeholders within the IPFIX Working > Group. This appendix outlines the differences between the two > protocols. It is informative only, and presented as an exploration > of the two protocols to motivate the usage of IPFIX Files to store > V9-collected flow data. > > B.1.1. Message Header Format > > Both NetFlow V9 and IPFIX use streams of messages prefixed by a > message header, though the message header differs significantly > between the two. Note that in NetFlow V9 terminology, these messages > are called packets, and messages must be delimited by datagram > boundaries. IPFIX does not have this constraint. The header formats > are detailed below: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version Number | Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sysUpTime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | UNIX Secs | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 11: NetFlow V9 Packet Header Format > > > > > > Trammell, et al. Expires January 15, 2009 [Page 45] > > Internet-Draft IPFIX Files July 2008 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Export Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Observation Domain ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 12: IPFIX Message Header Format > > Version Number: The IPFIX Version Number MUST be 10, while the > NetFlow V9 Version Number MUST be 9. > > Length vs. Count: The Count field in the NetFlow V9 packet header > counts records in the message (including data and template > records), while the Length field in the IPFIX Message Header > counts octets in the message. Note that this implies that NetFlow > V9 collectors must rely on datagram boundaries or some other > external delimeter; or otherwise must completely consume a message > before finding its end. > > System Uptime: System uptime in milliseconds is exported in the > NetFlow V9 packet header. This field is not present in the IPFIX > Message Header, and must be exported using an IPFIX Option if > required. > > Export Time: Aside from being called UNIX Secs in the NetFlow V9 > packet header specification, the export time in seconds since 1 > January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX > message headers. > > Sequence Number: The NetFlow V9 Sequence Number counts packets, > while the IPFIX Sequence Number counts records in Data Sets. Both > are scoped to Observation Domain. > > Observation Domain ID: Similarly, the NetFlow V9 sourceID has > become the IPFIX Observation Domain ID. > > B.1.2. Set Header Format > > Set headers are identical between NetFlow V9 and IPFIX; that is, each > Set (FlowSet in NetFlow V9 terminology) is prefixed by a 4-byte set > header containing the Set ID and the length of the set in octets. > > > > > Trammell, et al. Expires January 15, 2009 [Page 46] > > Internet-Draft IPFIX Files July 2008 > > > Note that the special Set IDs are different between IPFIX and NetFlow > V9. IPFIX Template Sets are identified by Set ID 2, while NetFlow V9 > Template FlowSets are identified by Set ID 0. Similarly, IPFIX > Options Template Sets are identified by Set ID 3, while NetFlow V9 > Options Template FlowSets are identified by Set ID 1. > > Both protocols reserve Set IDs 0-255, and use Set IDs 256-65535 for > Data Sets (or FlowSets, in NetFlow V9 terminology). > > B.1.3. Template Format > > Template FlowSets in NetFlow V9 support a subset of functionality of > those in IPFIX. Specifically, NetFlow V9 does not have any support > for vendor-specific Information Elements as IPFIX does, so there is > no enterprise bit or facility for associating a private enterprise > number with an information element. > > Options Template FlowSets in NetFlow V9 are similar to Options > Template Sets in IPFIX in the same way. > > B.1.4. Information Model > > The NetFlow V9 field type definitions are a compatible subset of, and > have evolved in concert with, the IPFIX Information Model. IPFIX > Information Element numbers in the range 1-127 are defined by the > IPFIX Information Model [RFC5102] to be compatible with the > corresponding NetFlow V9 field types. > > B.1.5. Template Management > > NetFlow V9 has no concept of a Transport Session as in IPFIX, as > NetFlow V9 was designed with a connectionless transport in mind. > Template IDs are therefore scoped to an Exporting Process lifetime > (i.e., an Exporting Process instance between restarts). There is no > facility in NetFlow V9 as in IPFIX for Template withdrawal or > Template ID reuse. Template retransmission at the Exporter works as > in UDP-based IPFIX Exporting Processes. > > B.1.6. Transport > > In practice, though NetFlow V9 is designed to be transport- > independent, it is transported only over UDP. There is no facility > as in IPFIX for full connection-oriented transport without datagram > boundaries, due to the use of a record count field as opposed to a > message length field in the packet header. There is no support in > NetFlow V9 for transport layer security via TLS or DTLS. > > > > > > Trammell, et al. Expires January 15, 2009 [Page 47] > > Internet-Draft IPFIX Files July 2008 > > > B.2. A Method for Transforming NetFlow V9 messages to IPFIX > > This appendix describes a method for transforming NetFlow V9 Packets > into IPFIX Messages, which can be used to store NetFlow V9 data in > IPFIX Files. A process transforming NetFlow V9 Packets into IPFIX > Messages must handle the fact that NetFlow V9 Packets and IPFIX > Messages are framed differently, that sequence numbering works > differently, and that the NetFlow V9 field type definitions are only > compatible with the IPFIX Information Model field and/or information > element numbers below Information Element number 128. > > For each incoming NetFlow V9 packet, the transformation process must: > > 1. Verify that the Version field of the packet header is 9. > > 2. Verify that the Sequence Number field of the packet header is > valid. > > 3. Scan the packet to: > > 1. verify that it contains no Templates with field numbers > outside the range 1-127; > > 2. verify that it contains no FlowSets with Set IDs between 2 > and 255 inclusive; > > 3. verify that it contains the number of records in FlowSets, > Template FlowSets, and Options Template FlowSets declared in > the Count field of the packet header; and > > 4. count the number of records in FlowSets for calculating the > IPFIX Sequence number. > > 4. Calculate a Sequence Number for each IPFIX Observation Domain by > storing the last Sequence Number sent for each Observation Domain > plus the count of records in FlowSets in the previous step to be > sent as the Sequence Number for the IPFIX Message within that > Observation Domain following this one. > > 5. Generate a new IPFIX Message Header with: > > 1. a Version field of 10; > > 2. a Length field with the number of octets in the IPFIX > Message, generally available by subtracting 4 from the length > of the NetFlow V9 packet as returned from the transport layer > (accounting for the difference in message header lengths); > > > > > Trammell, et al. Expires January 15, 2009 [Page 48] > > Internet-Draft IPFIX Files July 2008 > > > 3. the Sequence Number calculated for this message by the > Sequence Number calculation step; and > > 4. Export Time and Observation Domain ID taken from the UNIX > secs and Source ID fields of the NetFlow V9 packet header, > respectively. > > 6. Copy each FlowSet from the Netflow V9 packet to the IPFIX Message > after the header. Replace Set ID 0 with Set ID 2 for Template > Sets, and Set ID 1 with Set ID 3 for Options Template Sets. > > Note that this process loses system uptime information; if such > information is required, the transformation process will have to > export that information using IPFIX Options. This may require a more > sophisticated transformation process structure. > > B.3. NetFlow V9 Transformation Example > > The following two figures show a single NetFlow V9 packet with > templates and the corresponding IPFIX Message, exporting a single > flow record representing 60,303 octets sent from 192.0.2.2 to > 192.0.2.3. This would be the 3rd packet exported in Observation > Domain 33 from the NetFlow V9 exporter, containing records starting > with the 12th record (packet and record sequence numbers count from > 0). > > The ** symbol in the IPFIX example shows those fields that required > modification from the NetFlow V9 packet by the transformation > process. > > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 49] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version = 9 | Count = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Uptime = 3750405 ms (1:02:30.405) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Export Time = 1171557627 epoch sec (2007-02-15 16:40:27) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Observation Domain ID = 33 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 0 | Set Length = 20 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 256 | Field Count = 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPV4_SRC_ADDR = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPV4_DST_ADDR = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IN_BYTES = 1 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 256 | Set Length = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPV4_SRC_ADDR | > | 192.0.2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPV4_DST_ADDR | > | 192.0.2.3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IN_BYTES | > | 60303 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 13: Example NetFlow V9 Packet > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 50] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ** Version = 10 | ** Length = 52 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Export Time = 1171557627 epoch sec (2007-02-15 16:40:27) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ** Sequence Number = 11 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Observation Domain ID = 33 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ** Set ID = 2 | Set Length = 20 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 256 | Field Count = 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationIPv4Address = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| octetDeltaCount = 1 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 256 | Set Length = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceIPv4Address | > | 192.0.2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | destinationIPv4Address | > | 192.0.2.3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | octetDeltaCount | > | 60303 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 14: Corresponding Example IPFIX Message > > > Authors' Addresses > > Brian Trammell > Hitachi Europe > c/o ETH Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 13 > Email: brian.trammell@hitachi-eu.com > > > > > Trammell, et al. Expires January 15, 2009 [Page 51] > > Internet-Draft IPFIX Files July 2008 > > > Elisa Boschi > Hitachi Europe > c/o ETH Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 57 > Email: elisa.boschi@hitachi-eu.com > > > Lutz Mark > Fraunhofer IFAM > Weiner Str. 12 > 38259 Bremen > Germany > > Phone: +49 421 2246206 > Email: lutz.mark@ifam.fraunhofer.de > > > Tanja Zseby > Fraunhofer Institute for Open Communication Systems > Kaiserin-Augusta-Allee 31 > 10589 Berlin > Germany > > Phone: +49 30 3463 7153 > Email: tanja.zseby@fokus.fraunhofer.de > > > Arno Wagner > Swiss Federal Institute of Technology Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 04 > Email: arno@wagner.name > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 52] > > Internet-Draft IPFIX Files July 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 53] > > -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix | +---------------------------------------------+ | > | | Data Set (id 259) [Message Checksum] 1 rec | | > | +---------------------------------------------+ | > +=================================================+ > | IPFIX Message seq. 55 | > | . . . | > > Figure 2: File Example Structure > > The template describing the data records contains a flow start > timestamp, an IPv4 5-tuple, and packet and octet total counts. The > Template Set defining this is as shown in Figure 3 below: > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 37] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 40 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 256 | Field Count = 8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| flowStartSeconds = 150 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| dest.IPv4Address = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceTransportPort = 7 | Field Length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| dest.TransportPort = 11 | Field Length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| protocolIdentifier = 4 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| octetTotalCount = 85 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| packetTotalCount = 86 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 3: File Example Data Template > > A.1. Example Options Templates > > This is followed by an Options Template Set containing the options > templates required to read the File: the File Time Window Options > Template defined in Section 8.1.2 above, the Export Session Details > Options Template defined in Section 8.1.3 above, and the Message > Checksum Options Template defined in Section 8.1.1 above. This > Options Template Set is shown in Figure 4 and Figure 5 below: > > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 38] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 3 | Length = 80 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 257 | Field Count = 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope Field Count = 1 |0| sessionScope = TBD10 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 1 |0| minFlowStartSeconds = TBD8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| maxFlowEndSeconds = TBD4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 | Template ID = 259 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Count = 2 | Scope Field Count = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| messageScope = TBD6 | Field Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| messageMD5Checksum = TBD5 | Field Length = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 4: File Example Options Templates (Time Window and Checksum) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 39] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 258 | Field Count = 9 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope Field Count = 1 |0| sessionScope = TBD10 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 1 |0| exporterIPv4Address = 130 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| collectorIPv4Address = 211 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| exporterTransportPort = 217 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 2 |0| col.TransportPort = 216 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 2 |0| col.TransportProtocol = 215 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 1 |0| col.ProtocolVersion = 214 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 1 |0| minExportSeconds = TBD7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| maxExportSeconds = TBD3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 | set padding (2 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 5: File Example Options Templates, Continued (Session Details) > > A.2. Example Supplemental Options Data > > Following the templates required to decode the file is the > supplemental options information used to describe the file's contents > and type information. First comes the File Time Window record; it > notes that the file contains data from 9 October 2007 between > 00:01:13 and 23:56:27 UTC, and appears as in Figure 6: > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 40] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 257 | Length = 13 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sessionScope | minFlowStartSeconds > | 0 | 2007-10-09 00:01:13 UTC . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | maxFlowEndSeconds > . . . | 2007-10-09 23:56:27 UTC . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > . . . | > +-+-+-+-+-+-+-+-+ > > Figure 6: File Example Time Window > > This is followed by information about how the data in the file was > collected, in the Export Session Details record. This record notes > that the session stored in this file was sent via SCTP from an > exporter at 192.0.2.30 port 32769 to an collector at 192.0.2.40 port > 4739, and contains messages exported between 00:01:57 and 23:57:12 > UTC on 9 October 2007; it is represented in its Data Set as in > Figure 7: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 41] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 258 | Length = 27 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sessionScope | exporterIPv4Address > | 0 | 192.0.2.30 . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | collectorIPv4Address > . . . | 192.0.2.31 . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | exporterTransportPort | cTPort > . . . | 32769 | 4739 . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | cTProtocol | cPVersion | > . . . | 132 | 10 | . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > minExportSeconds | > . . . 2007-10-09 00:01:57 UTC | . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > maxExportSeconds | > . . . 2007-10-09 23:57:12 UTC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 7: File Example Export Session Details > > A.3. Example Message Checksum > > Each IPFIX Message within the file is completed with a Message > Checksum record; the structure of this record within its Data Set is > as in Figure 8: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 259 | Length = 24 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | messageScope | | > | 0 | | > +-+-+-+-+-+-+-+-+ | > | messageMD5Checksum | > | (16 byte MD5 checksum of options message) | > | | > | | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | set padding (3 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 8: File Example Message Checksum > > > > Trammell, et al. Expires January 15, 2009 [Page 42] > > Internet-Draft IPFIX Files July 2008 > > > A.4. File Example Data Set > > After the templates and supplemental options information comes the > data itself. The first record of an example Data Set is shown with > its message and set headers in Figure 9: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version = 10 | Length = 1296 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Export Time = 2007-10-09 00:01:57 UTC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Observation Domain ID = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 256 | Length = 1254 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | flowStartSeconds | > | 2007-10-09 00:01:13 UTC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceIPv4Address | > | 192.0.2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | destinationIPv4Address | > | 192.0.2.3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceTransportPort | destinationTransportPort | > | 32770 | 80 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | protocolId | totalOctetCount > | 6 | 18000 . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | totalPacketCount > . . . | 65 . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (49 more records) > . . . | > +-+-+-+-+-+-+-+-+ > > Figure 9: File Example Data Set > > A.5. Complete File Example > > Bringing together the examples above and adding message headers as > appropriate, a hex dump of the first 317 bytes of the example file > constructed above would appear as in the annotated Figure 10 below. > > > > Trammell, et al. Expires January 15, 2009 [Page 43] > > Internet-Draft IPFIX Files July 2008 > > > [EDITOR'S NOTE: In this figure, xx refers to unassigned IANA IE > numbers as in the IANA Considerations section above; cs refers to > message checksum bytes that depend on the rest of the message > contents. These will have to be replaced if we keep this example > once the IE numbers are assigned.] > > 0:|00 0A 00 A0 47 0A B6 E5 00 00 00 00 00 00 00 01 > [^ first message header (length 160 bytes) --> > 16:|00 02 00 28 01 00 00 08 00 96 00 04 00 08 00 04 > [^ data template set --> > 32: 00 0C 00 04 00 07 00 02 00 0B 00 02 00 04 00 01 > > 48: 00 55 00 04 00 56 00 04|00 03 00 50 01 01 00 03 > [^ opt template set --> > 64: 00 01 xx xx 00 01 xx xx 00 04 xx xx 00 04 01 03 > > 80: 00 02 00 01 xx xx 00 01 xx xx 00 10 01 02 00 09 > > 96: 00 01 xx xx 00 01 00 82 00 04 00 D3 00 04 00 D9 > > 112: 00 02 00 D8 00 02 00 D7 00 01 00 D0 00 01 xx xx > > 128: 00 04 xx xx 00 04 00 00|01 03 00 18 00 cs cs cs > [^ checksum record --> > 144: cs cs cs cs cs cs cs cs cs cs cs cs cs 00 00 00 > > 176:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01 > [^ second message header (length 80 bytes) --> > 192:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02 > [^ time window rec -> [ session detail rec ^ --> > 208: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84 > > 224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 cs > [ message checksum rec ^ --> > 240: cs cs cs cs cs cs cs cs cs cs cs cs cs cs cs 00 > > 256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 > [^ third message header (length 1296 bytes) --> > 272:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03 > [^ set hdr ][^ first data rec --> > 288: 80 02 00 50 06 00 00 46 50 00 00 00 41 > > Figure 10: File Example Hex Dump > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 44] > > Internet-Draft IPFIX Files July 2008 > > > Appendix B. Applicability of IPFIX Files to NetFlow V9 flow storage > > As the IPFIX Message format is nearly a superset of the NetFlow V9 > packet format, IPFIX Files can be used for store NetFlow V9 data > relatively easily. This section describes a method for doing so. > The differences between the two protocols are outlined in > Appendix B.1 below. A simple, lightweight, message-for-message > translation method for transforming V9 Packets into IPFIX Messages > for storage within IPFIX Files is described in Appendix B.2. An > example of this translation method is given in Appendix B.3. > > B.1. Comparing NetFlow V9 to IPFIX > > With a few caveats, the IPFIX Protocol is a superset of the NetFlow > V9 protocol, having evolved from it largely through a process of > feature addition to bring it into compliance with the IPFIX > Requirements and the needs of stakeholders within the IPFIX Working > Group. This appendix outlines the differences between the two > protocols. It is informative only, and presented as an exploration > of the two protocols to motivate the usage of IPFIX Files to store > V9-collected flow data. > > B.1.1. Message Header Format > > Both NetFlow V9 and IPFIX use streams of messages prefixed by a > message header, though the message header differs significantly > between the two. Note that in NetFlow V9 terminology, these messages > are called packets, and messages must be delimited by datagram > boundaries. IPFIX does not have this constraint. The header formats > are detailed below: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version Number | Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sysUpTime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | UNIX Secs | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 11: NetFlow V9 Packet Header Format > > > > > > Trammell, et al. Expires January 15, 2009 [Page 45] > > Internet-Draft IPFIX Files July 2008 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Export Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Observation Domain ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 12: IPFIX Message Header Format > > Version Number: The IPFIX Version Number MUST be 10, while the > NetFlow V9 Version Number MUST be 9. > > Length vs. Count: The Count field in the NetFlow V9 packet header > counts records in the message (including data and template > records), while the Length field in the IPFIX Message Header > counts octets in the message. Note that this implies that NetFlow > V9 collectors must rely on datagram boundaries or some other > external delimeter; or otherwise must completely consume a message > before finding its end. > > System Uptime: System uptime in milliseconds is exported in the > NetFlow V9 packet header. This field is not present in the IPFIX > Message Header, and must be exported using an IPFIX Option if > required. > > Export Time: Aside from being called UNIX Secs in the NetFlow V9 > packet header specification, the export time in seconds since 1 > January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX > message headers. > > Sequence Number: The NetFlow V9 Sequence Number counts packets, > while the IPFIX Sequence Number counts records in Data Sets. Both > are scoped to Observation Domain. > > Observation Domain ID: Similarly, the NetFlow V9 sourceID has > become the IPFIX Observation Domain ID. > > B.1.2. Set Header Format > > Set headers are identical between NetFlow V9 and IPFIX; that is, each > Set (FlowSet in NetFlow V9 terminology) is prefixed by a 4-byte set > header containing the Set ID and the length of the set in octets. > > > > > Trammell, et al. Expires January 15, 2009 [Page 46] > > Internet-Draft IPFIX Files July 2008 > > > Note that the special Set IDs are different between IPFIX and NetFlow > V9. IPFIX Template Sets are identified by Set ID 2, while NetFlow V9 > Template FlowSets are identified by Set ID 0. Similarly, IPFIX > Options Template Sets are identified by Set ID 3, while NetFlow V9 > Options Template FlowSets are identified by Set ID 1. > > Both protocols reserve Set IDs 0-255, and use Set IDs 256-65535 for > Data Sets (or FlowSets, in NetFlow V9 terminology). > > B.1.3. Template Format > > Template FlowSets in NetFlow V9 support a subset of functionality of > those in IPFIX. Specifically, NetFlow V9 does not have any support > for vendor-specific Information Elements as IPFIX does, so there is > no enterprise bit or facility for associating a private enterprise > number with an information element. > > Options Template FlowSets in NetFlow V9 are similar to Options > Template Sets in IPFIX in the same way. > > B.1.4. Information Model > > The NetFlow V9 field type definitions are a compatible subset of, and > have evolved in concert with, the IPFIX Information Model. IPFIX > Information Element numbers in the range 1-127 are defined by the > IPFIX Information Model [RFC5102] to be compatible with the > corresponding NetFlow V9 field types. > > B.1.5. Template Management > > NetFlow V9 has no concept of a Transport Session as in IPFIX, as > NetFlow V9 was designed with a connectionless transport in mind. > Template IDs are therefore scoped to an Exporting Process lifetime > (i.e., an Exporting Process instance between restarts). There is no > facility in NetFlow V9 as in IPFIX for Template withdrawal or > Template ID reuse. Template retransmission at the Exporter works as > in UDP-based IPFIX Exporting Processes. > > B.1.6. Transport > > In practice, though NetFlow V9 is designed to be transport- > independent, it is transported only over UDP. There is no facility > as in IPFIX for full connection-oriented transport without datagram > boundaries, due to the use of a record count field as opposed to a > message length field in the packet header. There is no support in > NetFlow V9 for transport layer security via TLS or DTLS. > > > > > > Trammell, et al. Expires January 15, 2009 [Page 47] > > Internet-Draft IPFIX Files July 2008 > > > B.2. A Method for Transforming NetFlow V9 messages to IPFIX > > This appendix describes a method for transforming NetFlow V9 Packets > into IPFIX Messages, which can be used to store NetFlow V9 data in > IPFIX Files. A process transforming NetFlow V9 Packets into IPFIX > Messages must handle the fact that NetFlow V9 Packets and IPFIX > Messages are framed differently, that sequence numbering works > differently, and that the NetFlow V9 field type definitions are only > compatible with the IPFIX Information Model field and/or information > element numbers below Information Element number 128. > > For each incoming NetFlow V9 packet, the transformation process must: > > 1. Verify that the Version field of the packet header is 9. > > 2. Verify that the Sequence Number field of the packet header is > valid. > > 3. Scan the packet to: > > 1. verify that it contains no Templates with field numbers > outside the range 1-127; > > 2. verify that it contains no FlowSets with Set IDs between 2 > and 255 inclusive; > > 3. verify that it contains the number of records in FlowSets, > Template FlowSets, and Options Template FlowSets declared in > the Count field of the packet header; and > > 4. count the number of records in FlowSets for calculating the > IPFIX Sequence number. > > 4. Calculate a Sequence Number for each IPFIX Observation Domain by > storing the last Sequence Number sent for each Observation Domain > plus the count of records in FlowSets in the previous step to be > sent as the Sequence Number for the IPFIX Message within that > Observation Domain following this one. > > 5. Generate a new IPFIX Message Header with: > > 1. a Version field of 10; > > 2. a Length field with the number of octets in the IPFIX > Message, generally available by subtracting 4 from the length > of the NetFlow V9 packet as returned from the transport layer > (accounting for the difference in message header lengths); > > > > > Trammell, et al. Expires January 15, 2009 [Page 48] > > Internet-Draft IPFIX Files July 2008 > > > 3. the Sequence Number calculated for this message by the > Sequence Number calculation step; and > > 4. Export Time and Observation Domain ID taken from the UNIX > secs and Source ID fields of the NetFlow V9 packet header, > respectively. > > 6. Copy each FlowSet from the Netflow V9 packet to the IPFIX Message > after the header. Replace Set ID 0 with Set ID 2 for Template > Sets, and Set ID 1 with Set ID 3 for Options Template Sets. > > Note that this process loses system uptime information; if such > information is required, the transformation process will have to > export that information using IPFIX Options. This may require a more > sophisticated transformation process structure. > > B.3. NetFlow V9 Transformation Example > > The following two figures show a single NetFlow V9 packet with > templates and the corresponding IPFIX Message, exporting a single > flow record representing 60,303 octets sent from 192.0.2.2 to > 192.0.2.3. This would be the 3rd packet exported in Observation > Domain 33 from the NetFlow V9 exporter, containing records starting > with the 12th record (packet and record sequence numbers count from > 0). > > The ** symbol in the IPFIX example shows those fields that required > modification from the NetFlow V9 packet by the transformation > process. > > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 49] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version = 9 | Count = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Uptime = 3750405 ms (1:02:30.405) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Export Time = 1171557627 epoch sec (2007-02-15 16:40:27) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Observation Domain ID = 33 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 0 | Set Length = 20 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 256 | Field Count = 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPV4_SRC_ADDR = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPV4_DST_ADDR = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IN_BYTES = 1 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 256 | Set Length = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPV4_SRC_ADDR | > | 192.0.2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPV4_DST_ADDR | > | 192.0.2.3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IN_BYTES | > | 60303 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 13: Example NetFlow V9 Packet > > > > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 50] > > Internet-Draft IPFIX Files July 2008 > > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ** Version = 10 | ** Length = 52 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Export Time = 1171557627 epoch sec (2007-02-15 16:40:27) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ** Sequence Number = 11 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Observation Domain ID = 33 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ** Set ID = 2 | Set Length = 20 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 256 | Field Count = 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationIPv4Address = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| octetDeltaCount = 1 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 256 | Set Length = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sourceIPv4Address | > | 192.0.2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | destinationIPv4Address | > | 192.0.2.3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | octetDeltaCount | > | 60303 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 14: Corresponding Example IPFIX Message > > > Authors' Addresses > > Brian Trammell > Hitachi Europe > c/o ETH Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 13 > Email: brian.trammell@hitachi-eu.com > > > > > Trammell, et al. Expires January 15, 2009 [Page 51] > > Internet-Draft IPFIX Files July 2008 > > > Elisa Boschi > Hitachi Europe > c/o ETH Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 57 > Email: elisa.boschi@hitachi-eu.com > > > Lutz Mark > Fraunhofer IFAM > Weiner Str. 12 > 38259 Bremen > Germany > > Phone: +49 421 2246206 > Email: lutz.mark@ifam.fraunhofer.de > > > Tanja Zseby > Fraunhofer Institute for Open Communication Systems > Kaiserin-Augusta-Allee 31 > 10589 Berlin > Germany > > Phone: +49 30 3463 7153 > Email: tanja.zseby@fokus.fraunhofer.de > > > Arno Wagner > Swiss Federal Institute of Technology Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 04 > Email: arno@wagner.name > > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 52] > > Internet-Draft IPFIX Files July 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Trammell, et al. Expires January 15, 2009 [Page 53] > > -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Jul 30 04:36:00 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035743A68B0; Wed, 30 Jul 2008 04:36:00 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E08AD28C249 for ; Wed, 30 Jul 2008 04:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.824 X-Spam-Level: X-Spam-Status: No, score=-4.824 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GEdFR7yQ3dO for ; Wed, 30 Jul 2008 04:35:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 634EF3A68A1 for ; Wed, 30 Jul 2008 04:35:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,278,1215388800"; d="scan'208";a="15797988" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2008 11:36:09 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6UBa80u030401 for ; Wed, 30 Jul 2008 13:36:08 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6UBa8PB004822 for ; Wed, 30 Jul 2008 11:36:08 GMT Received: from [10.61.97.133] (dhcp-10-61-97-133.cisco.com [10.61.97.133]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6UBa8I10464 for ; Wed, 30 Jul 2008 12:36:08 +0100 (BST) Message-ID: <48905228.5050801@cisco.com> Date: Wed, 30 Jul 2008 12:36:08 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <4887317F.2010008@cisco.com> In-Reply-To: <4887317F.2010008@cisco.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5262; t=1217417769; x=1218281769; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20=20[IPFIX]=20RFC=205102=20diagrams=20ar e=20back=20to=20front? |Sender:=20; bh=41Zmafl8tNaopVcXv6yaaHYkIjgJdTVmZeH9DbfDPp0=; b=aOU9VRXDTCcgr3dej9vidTIIcxjyACbN3xQxDMXaDhbMB4fzCVRmzyICSG Q9E2HtARR1HxEYBdAY0wX3EsQmzVkNg0vDag/0qENh4Dt8lf6qBVBehUpElz XQxRRK+4t2; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [IPFIX] RFC 5102 diagrams are back to front? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear All, I didn't see any reply to this issue on the mailing list, nobody mentioned it in the IPFIX WG meeting, and nobody discussed the issue with me here in Dublin. So I'm not sure whether to conclude that nobody implemented these fields yet, or just that nobody understood the issue? What I propose is to deprecate the isMulticast and ipv4Options fields in favour of new IEs with similar definitions, except that the bit order is reversed as shown below. Does anyone disagree? P. > Looking at the RFC 5102 diagrams for the definitions of the following > elements: isMulticast, ipv4Options, ipv6ExtensionHeaders, tcpOptions > > - we appear to have drawn the diagrams back to front :-( > > > eg, isMulticast is depicted thus: > > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | MCv4 | RES. | RES. | T | IPv6 multicast scope | > +------+------+------+------+------+------+------+------+ > > Bit 0: set to 1 if IPv4 multicast > Bits 1-2: reserved for future use > Bit 4: set to value of T flag, if IPv6 multicast > Bits 4-7: set to value of multicast scope if IPv6 multicast > > > Whereas it should have been drawn thus: > > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | IPv6 multicast scope | T | RES. | RES. | MCv4 | > +------+------+------+------+------+------+------+------+ > > > - so that MCv4 is in the LSB position, with a value of 1 - rather than a > value of 128, as currently depicted. > > Our implementation uses the LSB for MCv4, per the latter diagram. Has > anyone implemented this field with MCv4 in the MSB position? > > > Again, ipv4Options is depicted as: > > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ... > +------+------+------+------+------+------+------+------+ > > > Whereas it should have been drawn thus: > > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | ... > +------+------+------+------+------+------+------+------+ > > Because RFC 791 defines: > > EOOL = 0 > NOP = 1 > SEC = 2 > LSR = 3 > ... > > The latter is trivial to implement as (1 << option_num), whereas what's > depicted in RFC 5102 would be more complicated to implement. > > Has anyone implemented this field yet? Which bits are you using? > > > > Fortunately the depictions of fragmentFlags and tcpControlBits _do_ > align with the corresponding RFCs. > > ie, for fragmentFlags: > > RFC 5102: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | R | D | M | D | D | D | D | D | > | S | F | F | C | C | C | C | C | > +---+---+---+---+---+---+---+---+ > > RFC 791: > > 0 1 2 > +---+---+---+ > | | D | M | > | 0 | F | F | > +---+---+---+ > > > And for tcpControlBits: > > RFC 5102: > > 0 1 2 3 4 5 6 7 > +-----+-----+-----+-----+-----+-----+-----+-----+ > | Reserved | URG | ACK | PSH | RST | SYN | FIN | > +-----+-----+-----+-----+-----+-----+-----+-----+ > > RFC 793: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Port | Destination Port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Acknowledgment Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data | |U|A|P|R|S|F| | > | Offset| Reserved |R|C|S|S|Y|I| Window | > | | |G|K|H|T|N|N| | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Checksum | Urgent Pointer | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | data | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Two other RFC 5102 diagrams (for mplsTopLabelExp and > mplsTopLabelStackSection) still need to be verified. > -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Jul 30 04:36:00 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035743A68B0; Wed, 30 Jul 2008 04:36:00 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E08AD28C249 for ; Wed, 30 Jul 2008 04:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.824 X-Spam-Level: X-Spam-Status: No, score=-4.824 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GEdFR7yQ3dO for ; Wed, 30 Jul 2008 04:35:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 634EF3A68A1 for ; Wed, 30 Jul 2008 04:35:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,278,1215388800"; d="scan'208";a="15797988" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2008 11:36:09 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6UBa80u030401 for ; Wed, 30 Jul 2008 13:36:08 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6UBa8PB004822 for ; Wed, 30 Jul 2008 11:36:08 GMT Received: from [10.61.97.133] (dhcp-10-61-97-133.cisco.com [10.61.97.133]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6UBa8I10464 for ; Wed, 30 Jul 2008 12:36:08 +0100 (BST) Message-ID: <48905228.5050801@cisco.com> Date: Wed, 30 Jul 2008 12:36:08 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <4887317F.2010008@cisco.com> In-Reply-To: <4887317F.2010008@cisco.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5262; t=1217417769; x=1218281769; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20=20[IPFIX]=20RFC=205102=20diagrams=20ar e=20back=20to=20front? |Sender:=20; bh=41Zmafl8tNaopVcXv6yaaHYkIjgJdTVmZeH9DbfDPp0=; b=aOU9VRXDTCcgr3dej9vidTIIcxjyACbN3xQxDMXaDhbMB4fzCVRmzyICSG Q9E2HtARR1HxEYBdAY0wX3EsQmzVkNg0vDag/0qENh4Dt8lf6qBVBehUpElz XQxRRK+4t2; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [IPFIX] RFC 5102 diagrams are back to front? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear All, I didn't see any reply to this issue on the mailing list, nobody mentioned it in the IPFIX WG meeting, and nobody discussed the issue with me here in Dublin. So I'm not sure whether to conclude that nobody implemented these fields yet, or just that nobody understood the issue? What I propose is to deprecate the isMulticast and ipv4Options fields in favour of new IEs with similar definitions, except that the bit order is reversed as shown below. Does anyone disagree? P. > Looking at the RFC 5102 diagrams for the definitions of the following > elements: isMulticast, ipv4Options, ipv6ExtensionHeaders, tcpOptions > > - we appear to have drawn the diagrams back to front :-( > > > eg, isMulticast is depicted thus: > > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | MCv4 | RES. | RES. | T | IPv6 multicast scope | > +------+------+------+------+------+------+------+------+ > > Bit 0: set to 1 if IPv4 multicast > Bits 1-2: reserved for future use > Bit 4: set to value of T flag, if IPv6 multicast > Bits 4-7: set to value of multicast scope if IPv6 multicast > > > Whereas it should have been drawn thus: > > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | IPv6 multicast scope | T | RES. | RES. | MCv4 | > +------+------+------+------+------+------+------+------+ > > > - so that MCv4 is in the LSB position, with a value of 1 - rather than a > value of 128, as currently depicted. > > Our implementation uses the LSB for MCv4, per the latter diagram. Has > anyone implemented this field with MCv4 in the MSB position? > > > Again, ipv4Options is depicted as: > > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ... > +------+------+------+------+------+------+------+------+ > > > Whereas it should have been drawn thus: > > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | ... > +------+------+------+------+------+------+------+------+ > > Because RFC 791 defines: > > EOOL = 0 > NOP = 1 > SEC = 2 > LSR = 3 > ... > > The latter is trivial to implement as (1 << option_num), whereas what's > depicted in RFC 5102 would be more complicated to implement. > > Has anyone implemented this field yet? Which bits are you using? > > > > Fortunately the depictions of fragmentFlags and tcpControlBits _do_ > align with the corresponding RFCs. > > ie, for fragmentFlags: > > RFC 5102: > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | R | D | M | D | D | D | D | D | > | S | F | F | C | C | C | C | C | > +---+---+---+---+---+---+---+---+ > > RFC 791: > > 0 1 2 > +---+---+---+ > | | D | M | > | 0 | F | F | > +---+---+---+ > > > And for tcpControlBits: > > RFC 5102: > > 0 1 2 3 4 5 6 7 > +-----+-----+-----+-----+-----+-----+-----+-----+ > | Reserved | URG | ACK | PSH | RST | SYN | FIN | > +-----+-----+-----+-----+-----+-----+-----+-----+ > > RFC 793: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Port | Destination Port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Acknowledgment Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data | |U|A|P|R|S|F| | > | Offset| Reserved |R|C|S|S|Y|I| Window | > | | |G|K|H|T|N|N| | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Checksum | Urgent Pointer | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | data | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Two other RFC 5102 diagrams (for mplsTopLabelExp and > mplsTopLabelStackSection) still need to be verified. > -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Jul 30 05:35:04 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDF13A6903; Wed, 30 Jul 2008 05:35:04 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E053A68B3 for ; Wed, 30 Jul 2008 05:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNRy+q1+c02V for ; Wed, 30 Jul 2008 05:34:58 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 8DB9528C341 for ; Wed, 30 Jul 2008 05:34:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D0D66D9410; Wed, 30 Jul 2008 14:34:45 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Nwr+wTuFU55C; Wed, 30 Jul 2008 14:34:45 +0200 (MEST) Received: from [130.129.20.57] (unknown [130.129.20.57]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 446C6D936D; Wed, 30 Jul 2008 14:34:45 +0200 (MEST) Message-Id: From: Brian Trammell To: Paul Aitken In-Reply-To: <48905228.5050801@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 30 Jul 2008 13:34:44 +0100 References: <4887317F.2010008@cisco.com> <48905228.5050801@cisco.com> X-Mailer: Apple Mail (2.928.1) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] RFC 5102 diagrams are back to front? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, all, This would seem to be the correct, indeed probably the only, thing to do. The naming of these new IEs could prove problematic, though. I'd prefer to avoid the drifting-API idiom of sticking numbers on (e.g., ipv6ExtensionHeaders2) -- what should we do about this? Cheers, Brian On Jul 30, 2008, at 12:36 PM, Paul Aitken wrote: > Dear All, > > I didn't see any reply to this issue on the mailing list, nobody > mentioned it in the IPFIX WG meeting, and nobody discussed the issue > with me here in Dublin. > > So I'm not sure whether to conclude that nobody implemented these > fields yet, or just that nobody understood the issue? > > What I propose is to deprecate the isMulticast and ipv4Options > fields in favour of new IEs with similar definitions, except that > the bit order is reversed as shown below. > > Does anyone disagree? > > P. > >> Looking at the RFC 5102 diagrams for the definitions of the >> following elements: isMulticast, ipv4Options, ipv6ExtensionHeaders, >> tcpOptions >> - we appear to have drawn the diagrams back to front :-( >> eg, From ipfix-bounces@ietf.org Wed Jul 30 05:35:04 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDF13A6903; Wed, 30 Jul 2008 05:35:04 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E053A68B3 for ; Wed, 30 Jul 2008 05:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNRy+q1+c02V for ; Wed, 30 Jul 2008 05:34:58 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 8DB9528C341 for ; Wed, 30 Jul 2008 05:34:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D0D66D9410; Wed, 30 Jul 2008 14:34:45 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Nwr+wTuFU55C; Wed, 30 Jul 2008 14:34:45 +0200 (MEST) Received: from [130.129.20.57] (unknown [130.129.20.57]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 446C6D936D; Wed, 30 Jul 2008 14:34:45 +0200 (MEST) Message-Id: From: Brian Trammell To: Paul Aitken In-Reply-To: <48905228.5050801@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 30 Jul 2008 13:34:44 +0100 References: <4887317F.2010008@cisco.com> <48905228.5050801@cisco.com> X-Mailer: Apple Mail (2.928.1) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] RFC 5102 diagrams are back to front? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, all, This would seem to be the correct, indeed probably the only, thing to do. The naming of these new IEs could prove problematic, though. I'd prefer to avoid the drifting-API idiom of sticking numbers on (e.g., ipv6ExtensionHeaders2) -- what should we do about this? Cheers, Brian On Jul 30, 2008, at 12:36 PM, Paul Aitken wrote: > Dear All, > > I didn't see any reply to this issue on the mailing list, nobody > mentioned it in the IPFIX WG meeting, and nobody discussed the issue > with me here in Dublin. > > So I'm not sure whether to conclude that nobody implemented these > fields yet, or just that nobody understood the issue? > > What I propose is to deprecate the isMulticast and ipv4Options > fields in favour of new IEs with similar definitions, except that > the bit order is reversed as shown below. > > Does anyone disagree? > > P. > >> Looking at the RFC 5102 diagrams for the definitions of the >> following elements: isMulticast, ipv4Options, ipv6ExtensionHeaders, >> tcpOptions >> - we appear to have drawn the diagrams back to front :-( >> egisMulticast is depicted thus: >> 0 1 2 3 4 5 6 7 >> +------+------+------+------+------+------+------+------+ >> | MCv4 | RES. | RES. | T | IPv6 multicast scope | >> +------+------+------+------+------+------+------+------+ >> Bit 0: set to 1 if IPv4 multicast >> Bits 1-2: reserved for future use >> Bit 4: set to value of T flag, if IPv6 multicast >> Bits 4-7: set to value of multicast scope if IPv6 multicast >> Whereas it should have been drawn thus: >> 0 1 2 3 4 5 6 7 >> +------+------+------+------+------+------+------+------+ >> | IPv6 multicast scope | T | RES. | RES. | MCv4 | >> +------+------+------+------+------+------+------+------+ >> - so that MCv4 is in the LSB position, with a value of 1 - rather >> than a value of 128, as currently depicted. >> Our implementation uses the LSB for MCv4, per the latter diagram. >> Has anyone implemented this field with MCv4 in the MSB position? >> Again, ipv4Options is depicted as: >> 0 1 2 3 4 5 6 7 >> +------+------+------+------+------+------+------+------+ >> | EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ... >> +------+------+------+------+------+------+------+------+ >> Whereas it should have been drawn thus: >> 0 1 2 3 4 5 6 7 >> +------+------+------+------+------+------+------+------+ >> | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | ... >> +------+------+------+------+------+------+------+------+ >> Because RFC 791 defines: >> EOOL = 0 >> NOP = 1 >> SEC = 2 >> LSR = 3 >> ... >> The latter is trivial to implement as (1 << option_num), whereas >> what's depicted in RFC 5102 would be more complicated to implement. >> Has anyone implemented this field yet? Which bits are you using? >> Fortunately the depictions of fragmentFlags and tcpControlBits _do_ >> align with the corresponding RFCs. >> ie, for fragmentFlags: >> RFC 5102: >> 0 1 2 3 4 5 6 7 >> +---+---+---+---+---+---+---+---+ >> | R | D | M | D | D | D | D | D | >> | S | F | F | C | C | C | C | C | >> +---+---+---+---+---+---+---+---+ >> RFC 791: >> 0 1 2 >> +---+---+---+ >> | | D | M | >> | 0 | F | F | >> +---+---+---+ >> And for tcpControlBits: >> RFC 5102: >> 0 1 2 3 4 5 6 7 >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> | Reserved | URG | ACK | PSH | RST | SYN | FIN | >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> RFC 793: >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Source Port | Destination Port | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Acknowledgment Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Data | |U|A|P|R|S|F| | >> | Offset| Reserved |R|C|S|S|Y|I| Window | >> | | |G|K|H|T|N|N| | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Checksum | Urgent Pointer | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Options | Padding | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | data | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Two other RFC 5102 diagrams (for mplsTopLabelExp and >> mplsTopLabelStackSection) still need to be verified. > > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix , isMulticast is depicted thus: >> 0 1 2 3 4 5 6 7 >> +------+------+------+------+------+------+------+------+ >> | MCv4 | RES. | RES. | T | IPv6 multicast scope | >> +------+------+------+------+------+------+------+------+ >> Bit 0: set to 1 if IPv4 multicast >> Bits 1-2: reserved for future use >> Bit 4: set to value of T flag, if IPv6 multicast >> Bits 4-7: set to value of multicast scope if IPv6 multicast >> Whereas it should have been drawn thus: >> 0 1 2 3 4 5 6 7 >> +------+------+------+------+------+------+------+------+ >> | IPv6 multicast scope | T | RES. | RES. | MCv4 | >> +------+------+------+------+------+------+------+------+ >> - so that MCv4 is in the LSB position, with a value of 1 - rather >> than a value of 128, as currently depicted. >> Our implementation uses the LSB for MCv4, per the latter diagram. >> Has anyone implemented this field with MCv4 in the MSB position? >> Again, ipv4Options is depicted as: >> 0 1 2 3 4 5 6 7 >> +------+------+------+------+------+------+------+------+ >> | EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ... >> +------+------+------+------+------+------+------+------+ >> Whereas it should have been drawn thus: >> 0 1 2 3 4 5 6 7 >> +------+------+------+------+------+------+------+------+ >> | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | ... >> +------+------+------+------+------+------+------+------+ >> Because RFC 791 defines: >> EOOL = 0 >> NOP = 1 >> SEC = 2 >> LSR = 3 >> ... >> The latter is trivial to implement as (1 << option_num), whereas >> what's depicted in RFC 5102 would be more complicated to implement. >> Has anyone implemented this field yet? Which bits are you using? >> Fortunately the depictions of fragmentFlags and tcpControlBits _do_ >> align with the corresponding RFCs. >> ie, for fragmentFlags: >> RFC 5102: >> 0 1 2 3 4 5 6 7 >> +---+---+---+---+---+---+---+---+ >> | R | D | M | D | D | D | D | D | >> | S | F | F | C | C | C | C | C | >> +---+---+---+---+---+---+---+---+ >> RFC 791: >> 0 1 2 >> +---+---+---+ >> | | D | M | >> | 0 | F | F | >> +---+---+---+ >> And for tcpControlBits: >> RFC 5102: >> 0 1 2 3 4 5 6 7 >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> | Reserved | URG | ACK | PSH | RST | SYN | FIN | >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> RFC 793: >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Source Port | Destination Port | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Acknowledgment Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Data | |U|A|P|R|S|F| | >> | Offset| Reserved |R|C|S|S|Y|I| Window | >> | | |G|K|H|T|N|N| | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Checksum | Urgent Pointer | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Options | Padding | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | data | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Two other RFC 5102 diagrams (for mplsTopLabelExp and >> mplsTopLabelStackSection) still need to be verified. > > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Jul 30 06:24:53 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C153A6900; Wed, 30 Jul 2008 06:24:53 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C627E3A6900 for ; Wed, 30 Jul 2008 06:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1EVPS5U0w8S for ; Wed, 30 Jul 2008 06:24:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7B7433A68BF for ; Wed, 30 Jul 2008 06:24:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,279,1215388800"; d="scan'208";a="15813112" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2008 13:25:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6UDP57l000610; Wed, 30 Jul 2008 15:25:05 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6UDP5Ij014720; Wed, 30 Jul 2008 13:25:05 GMT Received: from [10.61.97.133] (dhcp-10-61-97-133.cisco.com [10.61.97.133]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6UDP4I20830; Wed, 30 Jul 2008 14:25:04 +0100 (BST) Message-ID: <48906BB0.9090204@cisco.com> Date: Wed, 30 Jul 2008 14:25:04 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Brian Trammell References: <4887317F.2010008@cisco.com> <48905228.5050801@cisco.com> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1150; t=1217424305; x=1218288305; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20RFC=205102=20diagrams=20are=2 0back=20to=20front? |Sender:=20; bh=+aCowkxc5iRNraph77Di8cDd7v0SqlGO//pd1q9zSUA=; b=OpfoL431iSd4SKUWPGWlzKgOPl3gMp8RqVZ2vUfx09xkaS/l0gKIQGN252 fyU+EEZ/+6SsZPWP8f7tiAvSSHv48jdn4jjuINty2fBtCiRpquhHhiq+CGPI lGhhwcaP5c; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] RFC 5102 diagrams are back to front? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, > This would seem to be the correct, indeed probably the only, thing to do. > > The naming of these new IEs could prove problematic, though. I'd prefer > to avoid the drifting-API idiom of sticking numbers on (e.g., > ipv6ExtensionHeaders2) -- what should we do about this? We could potentially keep the same name, since the IDs would be different. However, that could potentially lead to confusion, eg if two implementations both claim to export "isMulticast" yet one uses the deprecated definition. Some potential options are: to append a version number (eg, "isMulticast-2") or a date (eg, "isMulticast-0808"), or most obviously, to pick more appropriate names. eg, "isMulticast" implies a boolean; perhaps it should become "multicastInfo" due to the other fields it also contains. However, I'm not so sure how best to rename ipv4Options. However, new names are unnecessary if no-one is already implementing these fields... we would simply deprecate the existing definitions and create new ones which the first implementations would use. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Jul 30 06:24:53 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C153A6900; Wed, 30 Jul 2008 06:24:53 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C627E3A6900 for ; Wed, 30 Jul 2008 06:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1EVPS5U0w8S for ; Wed, 30 Jul 2008 06:24:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7B7433A68BF for ; Wed, 30 Jul 2008 06:24:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,279,1215388800"; d="scan'208";a="15813112" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2008 13:25:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6UDP57l000610; Wed, 30 Jul 2008 15:25:05 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6UDP5Ij014720; Wed, 30 Jul 2008 13:25:05 GMT Received: from [10.61.97.133] (dhcp-10-61-97-133.cisco.com [10.61.97.133]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6UDP4I20830; Wed, 30 Jul 2008 14:25:04 +0100 (BST) Message-ID: <48906BB0.9090204@cisco.com> Date: Wed, 30 Jul 2008 14:25:04 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Brian Trammell References: <4887317F.2010008@cisco.com> <48905228.5050801@cisco.com> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1150; t=1217424305; x=1218288305; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20RFC=205102=20diagrams=20are=2 0back=20to=20front? |Sender:=20; bh=+aCowkxc5iRNraph77Di8cDd7v0SqlGO//pd1q9zSUA=; b=OpfoL431iSd4SKUWPGWlzKgOPl3gMp8RqVZ2vUfx09xkaS/l0gKIQGN252 fyU+EEZ/+6SsZPWP8f7tiAvSSHv48jdn4jjuINty2fBtCiRpquhHhiq+CGPI lGhhwcaP5c; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] RFC 5102 diagrams are back to front? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, > This would seem to be the correct, indeed probably the only, thing to do. > > The naming of these new IEs could prove problematic, though. I'd prefer > to avoid the drifting-API idiom of sticking numbers on (e.g., > ipv6ExtensionHeaders2) -- what should we do about this? We could potentially keep the same name, since the IDs would be different. However, that could potentially lead to confusion, eg if two implementations both claim to export "isMulticast" yet one uses the deprecated definition. Some potential options are: to append a version number (eg, "isMulticast-2") or a date (eg, "isMulticast-0808"), or most obviously, to pick more appropriate names. eg, "isMulticast" implies a boolean; perhaps it should become "multicastInfo" due to the other fields it also contains. However, I'm not so sure how best to rename ipv4Options. However, new names are unnecessary if no-one is already implementing these fields... we would simply deprecate the existing definitions and create new ones which the first implementations would use. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Jul 30 06:32:45 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E42C3A6843; Wed, 30 Jul 2008 06:32:45 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169DA3A68A2 for ; Wed, 30 Jul 2008 06:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpktBXEnlrdh for ; Wed, 30 Jul 2008 06:32:43 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 20A953A6783 for ; Wed, 30 Jul 2008 06:32:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A0CE9D9410; Wed, 30 Jul 2008 15:32:56 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CmUxCoT5fbqn; Wed, 30 Jul 2008 15:32:56 +0200 (MEST) Received: from argent.meeting.ietf.org (unknown [130.129.20.57]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 52015D9325; Wed, 30 Jul 2008 15:32:56 +0200 (MEST) Message-Id: From: Brian Trammell To: Paul Aitken In-Reply-To: <48906BB0.9090204@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 30 Jul 2008 14:32:55 +0100 References: <4887317F.2010008@cisco.com> <48905228.5050801@cisco.com> <48906BB0.9090204@cisco.com> X-Mailer: Apple Mail (2.928.1) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] RFC 5102 diagrams are back to front? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, On Jul 30, 2008, at 2:25 PM, Paul Aitken wrote: > Brian, > >> This would seem to be the correct, indeed probably the only, thing >> to do. >> The naming of these new IEs could prove problematic, though. I'd >> prefer to avoid the drifting-API idiom of sticking numbers on >> (e.g., ipv6ExtensionHeaders2) -- what should we do about this? > > We could potentially keep the same name, since the IDs would be > different. However, that could potentially lead to confusion, eg if > two implementations both claim to export "isMulticast" yet one uses > the deprecated definition. Though I suppose 5102 does not explicitly disallow it, I'm really, really leery of having two IEs with the same name in the registry. The potential for confusion is absolute. > Some potential options are: to append a version number (eg, > "isMulticast-2") or a date (eg, "isMulticast-0808"), or most > obviously, to pick more appropriate names. > > eg, "isMulticast" implies a boolean; perhaps it should become > "multicastInfo" due to the other fields it also contains. However, > I'm not so sure how best to rename ipv4Options. > > However, new names are unnecessary if no-one is already implementing > these fields... we would simply deprecate the existing definitions > and create new ones which the first implementations would use. Would this require an errata document to 5102, or could we just fix the descriptions in the IANA registry? _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Jul 30 06:32:45 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E42C3A6843; Wed, 30 Jul 2008 06:32:45 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169DA3A68A2 for ; Wed, 30 Jul 2008 06:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpktBXEnlrdh for ; Wed, 30 Jul 2008 06:32:43 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 20A953A6783 for ; Wed, 30 Jul 2008 06:32:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A0CE9D9410; Wed, 30 Jul 2008 15:32:56 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CmUxCoT5fbqn; Wed, 30 Jul 2008 15:32:56 +0200 (MEST) Received: from argent.meeting.ietf.org (unknown [130.129.20.57]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 52015D9325; Wed, 30 Jul 2008 15:32:56 +0200 (MEST) Message-Id: From: Brian Trammell To: Paul Aitken In-Reply-To: <48906BB0.9090204@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 30 Jul 2008 14:32:55 +0100 References: <4887317F.2010008@cisco.com> <48905228.5050801@cisco.com> <48906BB0.9090204@cisco.com> X-Mailer: Apple Mail (2.928.1) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] RFC 5102 diagrams are back to front? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, On Jul 30, 2008, at 2:25 PM, Paul Aitken wrote: > Brian, > >> This would seem to be the correct, indeed probably the only, thing >> to do. >> The naming of these new IEs could prove problematic, though. I'd >> prefer to avoid the drifting-API idiom of sticking numbers on >> (e.g., ipv6ExtensionHeaders2) -- what should we do about this? > > We could potentially keep the same name, since the IDs would be > different. However, that could potentially lead to confusion, eg if > two implementations both claim to export "isMulticast" yet one uses > the deprecated definition. Though I suppose 5102 does not explicitly disallow it, I'm really, really leery of having two IEs with the same name in the registry. The potential for confusion is absolute. > Some potential options are: to append a version number (eg, > "isMulticast-2") or a date (eg, "isMulticast-0808"), or most > obviously, to pick more appropriate names. > > eg, "isMulticast" implies a boolean; perhaps it should become > "multicastInfo" due to the other fields it also contains. However, > I'm not so sure how best to rename ipv4Options. > > However, new names are unnecessary if no-one is already implementing > these fields... we would simply deprecate the existing definitions > and create new ones which the first implementations would use. Would this require an errata document to 5102, or could we just fix the descriptions in the IANA registry? _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Jul 30 10:48:10 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E4328C3A5; Wed, 30 Jul 2008 10:48:09 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BAD3A6C3E for ; Wed, 30 Jul 2008 10:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.724 X-Spam-Level: X-Spam-Status: No, score=-5.724 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jrj3R5Cry5kS for ; Wed, 30 Jul 2008 10:48:04 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id D4ED93A6C3B for ; Wed, 30 Jul 2008 10:48:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0CB6BD938D; Wed, 30 Jul 2008 19:48:09 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MSG00655kBKn; Wed, 30 Jul 2008 19:48:08 +0200 (MEST) Received: from [130.129.20.57] (unknown [130.129.20.57]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8A3CFD936D; Wed, 30 Jul 2008 19:48:08 +0200 (MEST) Message-Id: <1D69719B-E0AB-4826-B153-E249E847B8D8@tik.ee.ethz.ch> From: Brian Trammell To: Paul Aitken In-Reply-To: <488DEF65.8060602@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 30 Jul 2008 18:48:07 +0100 References: <488DEF65.8060602@cisco.com> X-Mailer: Apple Mail (2.928.1) Cc: ipfix@ietf.org Subject: Re: [IPFIX] review: draft-ietf-ipfix-file-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, Thanks for your comments; comments on comments inline... On Jul 28, 2008, at 5:10 PM, Paul Aitken wrote: > Brian, All, > > As a general comment, consider how ipfix-file should work with ipfix- > compression. eg should/must data be de-compressed before storage? > Consider xref with section 9.1. Hm. There should definitely be some reference between compression and file; however, given the WGLC on file and planned September IESG submission, and the fact that compression is still quite experimental and not yet accepted as a WG item, the reference should probably go in the other direction (i.e., ipfix-compression should probably include interoperability with ipfix-file) >> 1. Introduction >> This document proposes a file format based upon IPFIX, designed to >> facilitiate interoperability and reusability among a wide variety >> of >> flow storage, processing, and analysis tools. It begins with an >> overview of the IPFIX File format, and a quick summary of how IPFIX >> Files work in Section 3. It then explores the motivation for >> proposing a standardized flow file format and using IPFIX as the >> basis for this newFrom ipfix-bounces@ietf.org Wed Jul 30 10:48:10 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E4328C3A5; Wed, 30 Jul 2008 10:48:09 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BAD3A6C3E for ; Wed, 30 Jul 2008 10:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.724 X-Spam-Level: X-Spam-Status: No, score=-5.724 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jrj3R5Cry5kS for ; Wed, 30 Jul 2008 10:48:04 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id D4ED93A6C3B for ; Wed, 30 Jul 2008 10:48:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0CB6BD938D; Wed, 30 Jul 2008 19:48:09 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MSG00655kBKn; Wed, 30 Jul 2008 19:48:08 +0200 (MEST) Received: from [130.129.20.57] (unknown [130.129.20.57]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8A3CFD936D; Wed, 30 Jul 2008 19:48:08 +0200 (MEST) Message-Id: <1D69719B-E0AB-4826-B153-E249E847B8D8@tik.ee.ethz.ch> From: Brian Trammell To: Paul Aitken In-Reply-To: <488DEF65.8060602@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 30 Jul 2008 18:48:07 +0100 References: <488DEF65.8060602@cisco.com> X-Mailer: Apple Mail (2.928.1) Cc: ipfix@ietf.org Subject: Re: [IPFIX] review: draft-ietf-ipfix-file-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, Thanks for your comments; comments on comments inline... On Jul 28, 2008, at 5:10 PM, Paul Aitken wrote: > Brian, All, > > As a general comment, consider how ipfix-file should work with ipfix- > compression. eg should/must data be de-compressed before storage? > Consider xref with section 9.1. Hm. There should definitely be some reference between compression and file; however, given the WGLC on file and planned September IESG submission, and the fact that compression is still quite experimental and not yet accepted as a WG item, the reference should probably go in the other direction (i.e., ipfix-compression should probably include interoperability with ipfix-file) >> 1. Introduction >> This document proposes a file format based upon IPFIX, designed to >> facilitiate interoperability and reusability among a wide variety >> of >> flow storage, processing, and analysis tools. It begins with an >> overview of the IPFIX File format, and a quick summary of how IPFIX >> Files work in Section 3. It then explores the motivation for >> proposing a standardized flow file format and using IPFIX as the >> basis for this new file format in Section 4. > > This seems back to front. Surely the motivation should come first? We went back and forth on this for a while; Section 3 is the "executive summary", basically, that answers the "okay so what's a file, because I don't want to read a fifty page RFC to find out?" question. The motivation then starts the document proper. >> 6.2. Storage of NetFlow V9-collected Flow Data >> Although the IPFIX protocol is based on the Cisco Netflow Services, >> Version 9 (NetFlow V9) protocol [RFC3954], the two have diverged >> since work began on IPFIX. However, since the NetFlow V9 >> information >> model is a compatible subset of the IPFIX information model, it is >> possible to use IPFIX files to store collected NetFlow V9 flow >> data. >> This approach may be particularly useful in multi-vendor, multi- >> protocol collection infrastructures using both NetFlow V9 and IPFIX >> to export flow data. >> The applicability of IPFIX Files to this use case is outlined in >> Appendix B. > > Is it important or even necessary to differentiate IPFIX and v9 data > in the file? Though you have collectorProtocolVersion, is the > original transport protocol so important? The only use case I can think of right now would be storing data for testing and replay of a V9/IPFIX mixed collection environment. >> 7.2. File Writer Specification >> >> File Writers SHOULD use Template Withdrawals to withdraw >> Templates if >> template IDs need to be reused. In this case, the new Templates >> reusing those IDs SHOULD appear directly in the file after the >> Template Withdrawals making the IDs available for reuse. Template >> Withdrawals SHOULD NOT be used unless necessary to reuse template >> IDs. > > You're saying that the writer should store up the TWM until a new > template definition is received - and only then should it write the > TWM immediately followed by the new template? Actually, IIRC this language came from a previous version of 5153, and should indeed be fixed up a bit. The first SHOULD should be a MAY, and the reuse timing requirement should be relaxed, which is to say, removed; will fix. > Surely the writer should faithfully record the TWM as soon as it's > seen? I think it's especially important wrt ipfix-export-per-sctp- > stream. Indeed; this caveat is missing in section 7.3.1, and should be added. >> Each IPFIX File is generally synonymous with a single Transport >> Session. File Writers SHOULD store the Templates and Options >> required to decode the data within the File in the File itself, and >> File Readers SHOULD NOT use Templates or Options defined in one >> file >> to decode or interpret Data Sets in another. >> File Writers SHOULD write IPFIX Messages within an IPFIX File in >> ascending Export Time order. >> File Writers MAY write Data Records to an IPFIX File in any order. > > Obviously a different order would prevent the original data stream > from being replayed. yes... are you suggesting pointing this out explicitly? >> 7.3.2. Collocating a File Writer with a Metering Process >> Note that File Writers may also be collocated directly with IPFIX >> Metering Processes, for writing measured information directly to >> disk >> without intermediate IPFIX Exporting or Collecting Processes. This >> arrangement may be particularly useful when providing data to an >> analysis environment with an IPFIX File based workflow, or when >> testing Metering Processes during development. >> When collocating a File Writer with a Metering Process, note that >> Information Elements associated with Exporting or Collecting >> Processes are meaningless, and SHOULD NOT appear in the Export >> Session Details Options Template described in Section 8.1.3 or the >> Message Details Options Template described in Section 8.1.4. >> When collocating a File Writer with an Exporting Process, the >> Export >> Time of each Message SHOULD be the time at which the first Data >> Record in the Message was received from the Exporting Process. > > Ugh, you switched from discussing the MP to the EP? >> 8.1.3. Export Session Details Options Template >> >> | collectorProtocolVersion | The version of the IPFIX >> Protocol | >> | | used to transport Messages >> within | >> | | this Transport >> Session. | > > The version of the IPFIX Protocol is always "10". > Surely you mean "The version of the Export Protocol ..." ? :-) IPFIX could go to 11 in the future, but yes, we should be explicit that this is for V9/IPFIX interop. We should also make this explicitly optional. >> 8.2.4. maxFlowEndSeconds >> Description: The latest absolute timestamp of the last packet >> within any Flow within the scope containing this Information >> Element, rounded up to the second. This Information Element >> SHOULD be bound to its containing IPFIX Transport Session (i.e., >> File) via an IPFIX Options and the sessionScope Information > > "record" -------------------------^ Yep. Thanks. Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix file format in Section 4. > > This seems back to front. Surely the motivation should come first? We went back and forth on this for a while; Section 3 is the "executive summary", basically, that answers the "okay so what's a file, because I don't want to read a fifty page RFC to find out?" question. The motivation then starts the document proper. >> 6.2. Storage of NetFlow V9-collected Flow Data >> Although the IPFIX protocol is based on the Cisco Netflow Services, >> Version 9 (NetFlow V9) protocol [RFC3954], the two have diverged >> since work began on IPFIX. However, since the NetFlow V9 >> information >> model is a compatible subset of the IPFIX information model, it is >> possible to use IPFIX files to store collected NetFlow V9 flow >> data. >> This approach may be particularly useful in multi-vendor, multi- >> protocol collection infrastructures using both NetFlow V9 and IPFIX >> to export flow data. >> The applicability of IPFIX Files to this use case is outlined in >> Appendix B. > > Is it important or even necessary to differentiate IPFIX and v9 data > in the file? Though you have collectorProtocolVersion, is the > original transport protocol so important? The only use case I can think of right now would be storing data for testing and replay of a V9/IPFIX mixed collection environment. >> 7.2. File Writer Specification >> >> File Writers SHOULD use Template Withdrawals to withdraw >> Templates if >> template IDs need to be reused. In this case, the new Templates >> reusing those IDs SHOULD appear directly in the file after the >> Template Withdrawals making the IDs available for reuse. Template >> Withdrawals SHOULD NOT be used unless necessary to reuse template >> IDs. > > You're saying that the writer should store up the TWM until a new > template definition is received - and only then should it write the > TWM immediately followed by the new template? Actually, IIRC this language came from a previous version of 5153, and should indeed be fixed up a bit. The first SHOULD should be a MAY, and the reuse timing requirement should be relaxed, which is to say, removed; will fix. > Surely the writer should faithfully record the TWM as soon as it's > seen? I think it's especially important wrt ipfix-export-per-sctp- > stream. Indeed; this caveat is missing in section 7.3.1, and should be added. >> Each IPFIX File is generally synonymous with a single Transport >> Session. File Writers SHOULD store the Templates and Options >> required to decode the data within the File in the File itself, and >> File Readers SHOULD NOT use Templates or Options defined in one >> file >> to decode or interpret Data Sets in another. >> File Writers SHOULD write IPFIX Messages within an IPFIX File in >> ascending Export Time order. >> File Writers MAY write Data Records to an IPFIX File in any order. > > Obviously a different order would prevent the original data stream > from being replayed. yes... are you suggesting pointing this out explicitly? >> 7.3.2. Collocating a File Writer with a Metering Process >> Note that File Writers may also be collocated directly with IPFIX >> Metering Processes, for writing measured information directly to >> disk >> without intermediate IPFIX Exporting or Collecting Processes. This >> arrangement may be particularly useful when providing data to an >> analysis environment with an IPFIX File based workflow, or when >> testing Metering Processes during development. >> When collocating a File Writer with a Metering Process, note that >> Information Elements associated with Exporting or Collecting >> Processes are meaningless, and SHOULD NOT appear in the Export >> Session Details Options Template described in Section 8.1.3 or the >> Message Details Options Template described in Section 8.1.4. >> When collocating a File Writer with an Exporting Process, the >> Export >> Time of each Message SHOULD be the time at which the first Data >> Record in the Message was received from the Exporting Process. > > Ugh, you switched from discussing the MP to the EP? >> 8.1.3. Export Session Details Options Template >> >> | collectorProtocolVersion | The version of the IPFIX >> Protocol | >> | | used to transport Messages >> within | >> | | this Transport >> Session. | > > The version of the IPFIX Protocol is always "10". > Surely you mean "The version of the Export Protocol ..." ? :-) IPFIX could go to 11 in the future, but yes, we should be explicit that this is for V9/IPFIX interop. We should also make this explicitly optional. >> 8.2.4. maxFlowEndSeconds >> Description: The latest absolute timestamp of the last packet >> within any Flow within the scope containing this Information >> Element, rounded up to the second. This Information Element >> SHOULD be bound to its containing IPFIX Transport Session (i.e., >> File) via an IPFIX Options and the sessionScope Information > > "record" -------------------------^ Yep. Thanks. Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Jul 30 11:00:13 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5C43A6876; Wed, 30 Jul 2008 11:00:13 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D382C3A6876 for ; Wed, 30 Jul 2008 11:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.016 X-Spam-Level: X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dk1IqN-+jAJB for ; Wed, 30 Jul 2008 11:00:12 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id C68923A6843 for ; Wed, 30 Jul 2008 11:00:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7B993D938D; Wed, 30 Jul 2008 19:52:23 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id i7Xltb3r1Ahn; Wed, 30 Jul 2008 19:52:23 +0200 (MEST) Received: from [130.129.20.57] (unknown [130.129.20.57]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2F0E6D936D; Wed, 30 Jul 2008 19:52:23 +0200 (MEST) Message-Id: <22BAC8EC-0670-4977-8F74-BA482E6F55A7@tik.ee.ethz.ch> From: Brian Trammell To: Paul Aitken In-Reply-To: <1D69719B-E0AB-4826-B153-E249E847B8D8@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 30 Jul 2008 18:52:22 +0100 References: <488DEF65.8060602@cisco.com> <1D69719B-E0AB-4826-B153-E249E847B8D8@tik.ee.ethz.ch> X-Mailer: Apple Mail (2.928.1) Cc: ipfix@ietf.org Subject: Re: [IPFIX] review: draft-ietf-ipfix-file-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, D'oh, forgot to answer one little one. On Jul 30, 2008, at 6:48 PM, Brian Trammell wrote: > Paul, > > Thanks for your comments; comments on comments inline... > > On Jul 28, 2008, at 5:10 PM, Paul Aitken wrote: > >>> 7.3.2. Collocating a File Writer with a Metering Process >>> Note that File Writers may also be collocated directly with IPFIX >>> Metering Processes, for writing measured information directly to >>> disk >>> without intermediate IPFIX Exporting or Collecting Processes. This >>> arrangement may be particularly useful when providing data to an >>> analysis environment with an IPFIX File based workflow, or when >>> testing Metering Processes during development. >>> When collocating a File Writer with a Metering Process, note that >>> Information Elements associated with Exporting or Collecting >>> Processes are meaningless, and SHOULD NOT appear in the Export >>> Session Details Options Template described in Section 8.1.3 or the >>> Message Details Options Template described in Section 8.1.4. >>> When collocating a File Writer with an ExpFrom ipfix-bounces@ietf.org Wed Jul 30 11:00:13 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5C43A6876; Wed, 30 Jul 2008 11:00:13 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D382C3A6876 for ; Wed, 30 Jul 2008 11:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.016 X-Spam-Level: X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dk1IqN-+jAJB for ; Wed, 30 Jul 2008 11:00:12 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id C68923A6843 for ; Wed, 30 Jul 2008 11:00:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7B993D938D; Wed, 30 Jul 2008 19:52:23 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id i7Xltb3r1Ahn; Wed, 30 Jul 2008 19:52:23 +0200 (MEST) Received: from [130.129.20.57] (unknown [130.129.20.57]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2F0E6D936D; Wed, 30 Jul 2008 19:52:23 +0200 (MEST) Message-Id: <22BAC8EC-0670-4977-8F74-BA482E6F55A7@tik.ee.ethz.ch> From: Brian Trammell To: Paul Aitken In-Reply-To: <1D69719B-E0AB-4826-B153-E249E847B8D8@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 30 Jul 2008 18:52:22 +0100 References: <488DEF65.8060602@cisco.com> <1D69719B-E0AB-4826-B153-E249E847B8D8@tik.ee.ethz.ch> X-Mailer: Apple Mail (2.928.1) Cc: ipfix@ietf.org Subject: Re: [IPFIX] review: draft-ietf-ipfix-file-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Paul, D'oh, forgot to answer one little one. On Jul 30, 2008, at 6:48 PM, Brian Trammell wrote: > Paul, > > Thanks for your comments; comments on comments inline... > > On Jul 28, 2008, at 5:10 PM, Paul Aitken wrote: > >>> 7.3.2. Collocating a File Writer with a Metering Process >>> Note that File Writers may also be collocated directly with IPFIX >>> Metering Processes, for writing measured information directly to >>> disk >>> without intermediate IPFIX Exporting or Collecting Processes. This >>> arrangement may be particularly useful when providing data to an >>> analysis environment with an IPFIX File based workflow, or when >>> testing Metering Processes during development. >>> When collocating a File Writer with a Metering Process, note that >>> Information Elements associated with Exporting or Collecting >>> Processes are meaningless, and SHOULD NOT appear in the Export >>> Session Details Options Template described in Section 8.1.3 or the >>> Message Details Options Template described in Section 8.1.4. >>> When collocating a File Writer with an Expororting Process, the >>> Export >>> Time of each Message SHOULD be the time at which the first Data >>> Record in the Message was received from the Exporting Process. >> >> Ugh, you switched from discussing the MP to the EP? Copy/paste. thanks for the catch; will fix. Thanks, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ting Process, the >>> Export >>> Time of each Message SHOULD be the time at which the first Data >>> Record in the Message was received from the Exporting Process. >> >> Ugh, you switched from discussing the MP to the EP? Copy/paste. thanks for the catch; will fix. Thanks, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Jul 30 13:46:41 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCAA3A6923; Wed, 30 Jul 2008 13:46:40 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC90A3A691A for ; Wed, 30 Jul 2008 13:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvQlPt+5abOj for ; Wed, 30 Jul 2008 13:46:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2B5563A6923 for ; Wed, 30 Jul 2008 13:46:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,281,1215388800"; d="scan'208";a="15843350" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2008 20:46:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6UKkqGa002713; Wed, 30 Jul 2008 22:46:52 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6UKkqwa019524; Wed, 30 Jul 2008 20:46:52 GMT Received: from [10.61.96.200] (dhcp-10-61-96-200.cisco.com [10.61.96.200]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6UKkpI05700; Wed, 30 Jul 2008 21:46:51 +0100 (BST) Message-ID: <4890D33B.1060907@cisco.com> Date: Wed, 30 Jul 2008 21:46:51 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Brian Trammell References: <488DEF65.8060602@cisco.com> <1D69719B-E0AB-4826-B153-E249E847B8D8@tik.ee.ethz.ch> In-Reply-To: <1D69719B-E0AB-4826-B153-E249E847B8D8@tik.ee.ethz.ch> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7667; t=1217450812; x=1218314812; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20review=3A=20draft-ietf-ipfix- file-02.txt |Sender:=20; bh=3iv0CAuSApA2pzAMsVf5qRjxtWhUzOGFdDBasZnwFuM=; b=c1Rrfo5dko0LeXHAMLcvJjJBWVVbGBTLfiUzLx95mCKrs0rKGMjv1V+ALd OV6bAx3/I12gy1B6/q7QvmGm3tn2IaHwHFi+toqURMxcgL6ZuVMZY1iGgXfZ SFlFcHsJpB; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] review: draft-ietf-ipfix-file-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, > Thanks for your comments; comments on comments inline... Inline, as ever... >> As a general comment, consider how ipfix-file should work with >> ipfix-compression. eg should/must data be de-compressed before storage? >> Consider xref with section 9.1. > > Hm. There should definitely be some reference between compressFrom ipfix-bounces@ietf.org Wed Jul 30 13:46:41 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCAA3A6923; Wed, 30 Jul 2008 13:46:40 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC90A3A691A for ; Wed, 30 Jul 2008 13:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvQlPt+5abOj for ; Wed, 30 Jul 2008 13:46:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2B5563A6923 for ; Wed, 30 Jul 2008 13:46:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,281,1215388800"; d="scan'208";a="15843350" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2008 20:46:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6UKkqGa002713; Wed, 30 Jul 2008 22:46:52 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6UKkqwa019524; Wed, 30 Jul 2008 20:46:52 GMT Received: from [10.61.96.200] (dhcp-10-61-96-200.cisco.com [10.61.96.200]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id m6UKkpI05700; Wed, 30 Jul 2008 21:46:51 +0100 (BST) Message-ID: <4890D33B.1060907@cisco.com> Date: Wed, 30 Jul 2008 21:46:51 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 MIME-Version: 1.0 To: Brian Trammell References: <488DEF65.8060602@cisco.com> <1D69719B-E0AB-4826-B153-E249E847B8D8@tik.ee.ethz.ch> In-Reply-To: <1D69719B-E0AB-4826-B153-E249E847B8D8@tik.ee.ethz.ch> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7667; t=1217450812; x=1218314812; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20review=3A=20draft-ietf-ipfix- file-02.txt |Sender:=20; bh=3iv0CAuSApA2pzAMsVf5qRjxtWhUzOGFdDBasZnwFuM=; b=c1Rrfo5dko0LeXHAMLcvJjJBWVVbGBTLfiUzLx95mCKrs0rKGMjv1V+ALd OV6bAx3/I12gy1B6/q7QvmGm3tn2IaHwHFi+toqURMxcgL6ZuVMZY1iGgXfZ SFlFcHsJpB; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] review: draft-ietf-ipfix-file-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Brian, > Thanks for your comments; comments on comments inline... Inline, as ever... >> As a general comment, consider how ipfix-file should work with >> ipfix-compression. eg should/must data be de-compressed before storage? >> Consider xref with section 9.1. > > Hm. There should definitely be some reference between compressioion and > file; however, given the WGLC on file and planned September IESG > submission, and the fact that compression is still quite experimental > and not yet accepted as a WG item, the reference should probably go in > the other direction (i.e., ipfix-compression should probably include > interoperability with ipfix-file) I'm looking for a statement on how we envisage file / anonymisation / compression / whatever comes next all working together. Clearly there are pros and cons of various combinations, so it's probably worth each subsequent draft noting what those may be and making relevant recommendations. >>> 1. Introduction >>> This document proposes a file format based upon IPFIX, designed to >>> facilitiate interoperability and reusability among a wide variety of >>> flow storage, processing, and analysis tools. It begins with an >>> overview of the IPFIX File format, and a quick summary of how IPFIX >>> Files work in Section 3. It then explores the motivation for >>> proposing a standardized flow file format and using IPFIX as the >>> basis for this new file format in Section 4. >> >> This seems back to front. Surely the motivation should come first? > > We went back and forth on this for a while; Section 3 is the "executive > summary", basically, that answers the "okay so what's a file, because I > don't want to read a fifty page RFC to find out?" question. The > motivation then starts the document proper. Yeah, but we're all engineers here. Executive summaries are for your management reports if your manager is too stupid or lazy to understand them. >>> 6.2. Storage of NetFlow V9-collected Flow Data >>> Although the IPFIX protocol is based on the Cisco Netflow Services, >>> Version 9 (NetFlow V9) protocol [RFC3954], the two have diverged >>> since work began on IPFIX. However, since the NetFlow V9 information >>> model is a compatible subset of the IPFIX information model, it is >>> possible to use IPFIX files to store collected NetFlow V9 flow data. >>> This approach may be particularly useful in multi-vendor, multi- >>> protocol collection infrastructures using both NetFlow V9 and IPFIX >>> to export flow data. >>> The applicability of IPFIX Files to this use case is outlined in >>> Appendix B. >> >> Is it important or even necessary to differentiate IPFIX and v9 data >> in the file? Though you have collectorProtocolVersion, is the original >> transport protocol so important? > > The only use case I can think of right now would be storing data for > testing and replay of a V9/IPFIX mixed collection environment. Right. Actually, I like that this is backwards compatible with existing v1/5/7/8/9 netflow, as well as potentially forwards compatible with whatever may come after IPFIX. >>> 7.2. File Writer Specification >>> >>> File Writers SHOULD use Template Withdrawals to withdraw Templates if >>> template IDs need to be reused. In this case, the new Templates >>> reusing those IDs SHOULD appear directly in the file after the >>> Template Withdrawals making the IDs available for reuse. Template >>> Withdrawals SHOULD NOT be used unless necessary to reuse template >>> IDs. >> >> You're saying that the writer should store up the TWM until a new >> template definition is received - and only then should it write the >> TWM immediately followed by the new template? > > Actually, IIRC this language came from a previous version of 5153, and > should indeed be fixed up a bit. The first SHOULD should be a MAY, and > the reuse timing requirement should be relaxed, which is to say, > removed; will fix. Thanks. I hope 5153 doesn't need fixed too? >> Surely the writer should faithfully record the TWM as soon as it's >> seen? I think it's especially important wrt ipfix-export-per-sctp-stream. > > Indeed; this caveat is missing in section 7.3.1, and should be added. Thanks. >>> Each IPFIX File is generally synonymous with a single Transport >>> Session. File Writers SHOULD store the Templates and Options >>> required ton and > file; however, given the WGLC on file and planned September IESG > submission, and the fact that compression is still quite experimental > and not yet accepted as a WG item, the reference should probably go in > the other direction (i.e., ipfix-compression should probably include > interoperability with ipfix-file) I'm looking for a statement on how we envisage file / anonymisation / compression / whatever comes next all working together. Clearly there are pros and cons of various combinations, so it's probably worth each subsequent draft noting what those may be and making relevant recommendations. >>> 1. Introduction >>> This document proposes a file format based upon IPFIX, designed to >>> facilitiate interoperability and reusability among a wide variety of >>> flow storage, processing, and analysis tools. It begins with an >>> overview of the IPFIX File format, and a quick summary of how IPFIX >>> Files work in Section 3. It then explores the motivation for >>> proposing a standardized flow file format and using IPFIX as the >>> basis for this new file format in Section 4. >> >> This seems back to front. Surely the motivation should come first? > > We went back and forth on this for a while; Section 3 is the "executive > summary", basically, that answers the "okay so what's a file, because I > don't want to read a fifty page RFC to find out?" question. The > motivation then starts the document proper. Yeah, but we're all engineers here. Executive summaries are for your management reports if your manager is too stupid or lazy to understand them. >>> 6.2. Storage of NetFlow V9-collected Flow Data >>> Although the IPFIX protocol is based on the Cisco Netflow Services, >>> Version 9 (NetFlow V9) protocol [RFC3954], the two have diverged >>> since work began on IPFIX. However, since the NetFlow V9 information >>> model is a compatible subset of the IPFIX information model, it is >>> possible to use IPFIX files to store collected NetFlow V9 flow data. >>> This approach may be particularly useful in multi-vendor, multi- >>> protocol collection infrastructures using both NetFlow V9 and IPFIX >>> to export flow data. >>> The applicability of IPFIX Files to this use case is outlined in >>> Appendix B. >> >> Is it important or even necessary to differentiate IPFIX and v9 data >> in the file? Though you have collectorProtocolVersion, is the original >> transport protocol so important? > > The only use case I can think of right now would be storing data for > testing and replay of a V9/IPFIX mixed collection environment. Right. Actually, I like that this is backwards compatible with existing v1/5/7/8/9 netflow, as well as potentially forwards compatible with whatever may come after IPFIX. >>> 7.2. File Writer Specification >>> >>> File Writers SHOULD use Template Withdrawals to withdraw Templates if >>> template IDs need to be reused. In this case, the new Templates >>> reusing those IDs SHOULD appear directly in the file after the >>> Template Withdrawals making the IDs available for reuse. Template >>> Withdrawals SHOULD NOT be used unless necessary to reuse template >>> IDs. >> >> You're saying that the writer should store up the TWM until a new >> template definition is received - and only then should it write the >> TWM immediately followed by the new template? > > Actually, IIRC this language came from a previous version of 5153, and > should indeed be fixed up a bit. The first SHOULD should be a MAY, and > the reuse timing requirement should be relaxed, which is to say, > removed; will fix. Thanks. I hope 5153 doesn't need fixed too? >> Surely the writer should faithfully record the TWM as soon as it's >> seen? I think it's especially important wrt ipfix-export-per-sctp-stream. > > Indeed; this caveat is missing in section 7.3.1, and should be added. Thanks. >>> Each IPFIX File is generally synonymous with a single Transport >>> Session. File Writers SHOULD store the Templates and Options >>> required to d decode the data within the File in the File itself, and >>> File Readers SHOULD NOT use Templates or Options defined in one file >>> to decode or interpret Data Sets in another. >>> File Writers SHOULD write IPFIX Messages within an IPFIX File in >>> ascending Export Time order. BTW that could be hard if messages are received out of order. Especially, it could lead to a simple DoS attack against a file writer. And it could prevent faithful data replay. >>> File Writers MAY write Data Records to an IPFIX File in any order. >> >> Obviously a different order would prevent the original data stream >> from being replayed. > > yes... are you suggesting pointing this out explicitly? Well, you explicitly point out that DR can be stored in any order. I don't see any particular advantage to time-ordering the data. >>> 7.3.2. Collocating a File Writer with a Metering Process >>> Note that File Writers may also be collocated directly with IPFIX >>> Metering Processes, for writing measured information directly to disk >>> without intermediate IPFIX Exporting or Collecting Processes. This >>> arrangement may be particularly useful when providing data to an >>> analysis environment with an IPFIX File based workflow, or when >>> testing Metering Processes during development. >>> When collocating a File Writer with a Metering Process, note that >>> Information Elements associated with Exporting or Collecting >>> Processes are meaningless, and SHOULD NOT appear in the Export >>> Session Details Options Template described in Section 8.1.3 or the >>> Message Details Options Template described in Section 8.1.4. >>> When collocating a File Writer with an Exporting Process, the Export >>> Time of each Message SHOULD be the time at which the first Data >>> Record in the Message was received from the Exporting Process. >> >> Ugh, you switched from discussing the MP to the EP? > > > >>> 8.1.3. Export Session Details Options Template >>> >>> | collectorProtocolVersion | The version of the IPFIX Protocol | >>> | | used to transport Messages within | >>> | | this Transport Session. | >> >> The version of the IPFIX Protocol is always "10". >> Surely you mean "The version of the Export Protocol ..." ? :-) > > IPFIX could go to 11 in the future, but yes, we should be explicit that > this is for V9/IPFIX interop. We should also make this explicitly optional. Agreed. >>> 8.2.4. maxFlowEndSeconds >>> Description: The latest absolute timestamp of the last packet >>> within any Flow within the scope containing this Information >>> Element, rounded up to the second. This Information Element >>> SHOULD be bound to its containing IPFIX Transport Session (i.e., >>> File) via an IPFIX Options and the sessionScope Information >> >> "record" -------------------------^ > > Yep. Thanks. > > Cheers, > > Brian Thanks. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ecode the data within the File in the File itself, and >>> File Readers SHOULD NOT use Templates or Options defined in one file >>> to decode or interpret Data Sets in another. >>> File Writers SHOULD write IPFIX Messages within an IPFIX File in >>> ascending Export Time order. BTW that could be hard if messages are received out of order. Especially, it could lead to a simple DoS attack against a file writer. And it could prevent faithful data replay. >>> File Writers MAY write Data Records to an IPFIX File in any order. >> >> Obviously a different order would prevent the original data stream >> from being replayed. > > yes... are you suggesting pointing this out explicitly? Well, you explicitly point out that DR can be stored in any order. I don't see any particular advantage to time-ordering the data. >>> 7.3.2. Collocating a File Writer with a Metering Process >>> Note that File Writers may also be collocated directly with IPFIX >>> Metering Processes, for writing measured information directly to disk >>> without intermediate IPFIX Exporting or Collecting Processes. This >>> arrangement may be particularly useful when providing data to an >>> analysis environment with an IPFIX File based workflow, or when >>> testing Metering Processes during development. >>> When collocating a File Writer with a Metering Process, note that >>> Information Elements associated with Exporting or Collecting >>> Processes are meaningless, and SHOULD NOT appear in the Export >>> Session Details Options Template described in Section 8.1.3 or the >>> Message Details Options Template described in Section 8.1.4. >>> When collocating a File Writer with an Exporting Process, the Export >>> Time of each Message SHOULD be the time at which the first Data >>> Record in the Message was received from the Exporting Process. >> >> Ugh, you switched from discussing the MP to the EP? > > > >>> 8.1.3. Export Session Details Options Template >>> >>> | collectorProtocolVersion | The version of the IPFIX Protocol | >>> | | used to transport Messages within | >>> | | this Transport Session. | >> >> The version of the IPFIX Protocol is always "10". >> Surely you mean "The version of the Export Protocol ..." ? :-) > > IPFIX could go to 11 in the future, but yes, we should be explicit that > this is for V9/IPFIX interop. We should also make this explicitly optional. Agreed. >>> 8.2.4. maxFlowEndSeconds >>> Description: The latest absolute timestamp of the last packet >>> within any Flow within the scope containing this Information >>> Element, rounded up to the second. This Information Element >>> SHOULD be bound to its containing IPFIX Transport Session (i.e., >>> File) via an IPFIX Options and the sessionScope Information >> >> "record" -------------------------^ > > Yep. Thanks. > > Cheers, > > Brian Thanks. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jul 31 00:10:24 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A1D3A6C34; Thu, 31 Jul 2008 00:10:23 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3793A6C35 for ; Thu, 31 Jul 2008 00:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtSb4Ujohv7m for ; Thu, 31 Jul 2008 00:10:22 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2DBD63A69AF for ; Thu, 31 Jul 2008 00:10:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3DE512C00035A for ; Thu, 31 Jul 2008 09:10:18 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZSiSkj66Emy for ; Thu, 31 Jul 2008 09:10:18 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 20DDA2C000304 for ; Thu, 31 Jul 2008 09:10:13 +0200 (CEST) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Jul 2008 07:10:13 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 31 Jul 2008 09:00:14 +0200 From: Juergen Quittek To: IETF IPFIX Working Group Message-ID: Thread-Topic: Summary of our session on Monday Thread-Index: Acjy2xTAsvkAMd9RfUqwPL6NbyMd5Q== Mime-version: 1.0 Subject: [IPFIX] Summary of our session on Monday X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, Here is a short summary of our session on Monday. The IPFIX WG has completed all documents of the old charters except for the IPFIX MIB module which will enter WG last call after the IETF meeting. There are six new WG I-Ds based on the current charter. One of them, the type export I-D, was considered complete at the session and publication as RFC will be requested immediately after he IETF meeting. For two other I-Ds, the file format and the single SCTP stream I-D, WG last call will start after the IETF meeting. The I-D on IPFIX mediation has been split into two documents, a pure problem statement I-D and a mediator framework I-D. The first one has undergone significant changes and needs one more revision before entering WG last call. The latter one is not yet listed as WG milestone in the charter. New milestones for it will be requested after the IETF meeting. The I-D on IPFIX configuration is intended to be aligned with the YANG framework that the NETMOD WG is developing. However, a stable version of YANG is not expected in the near future. Therefore, the WG discussed to split the configuration I-D into a standards trFrom ipfix-bounces@ietf.org Thu Jul 31 00:10:24 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A1D3A6C34; Thu, 31 Jul 2008 00:10:23 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3793A6C35 for ; Thu, 31 Jul 2008 00:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtSb4Ujohv7m for ; Thu, 31 Jul 2008 00:10:22 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2DBD63A69AF for ; Thu, 31 Jul 2008 00:10:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3DE512C00035A for ; Thu, 31 Jul 2008 09:10:18 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZSiSkj66Emy for ; Thu, 31 Jul 2008 09:10:18 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 20DDA2C000304 for ; Thu, 31 Jul 2008 09:10:13 +0200 (CEST) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Jul 2008 07:10:13 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 31 Jul 2008 09:00:14 +0200 From: Juergen Quittek To: IETF IPFIX Working Group Message-ID: Thread-Topic: Summary of our session on Monday Thread-Index: Acjy2xTAsvkAMd9RfUqwPL6NbyMd5Q== Mime-version: 1.0 Subject: [IPFIX] Summary of our session on Monday X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, Here is a short summary of our session on Monday. The IPFIX WG has completed all documents of the old charters except for the IPFIX MIB module which will enter WG last call after the IETF meeting. There are six new WG I-Ds based on the current charter. One of them, the type export I-D, was considered complete at the session and publication as RFC will be requested immediately after he IETF meeting. For two other I-Ds, the file format and the single SCTP stream I-D, WG last call will start after the IETF meeting. The I-D on IPFIX mediation has been split into two documents, a pure problem statement I-D and a mediator framework I-D. The first one has undergone significant changes and needs one more revision before entering WG last call. The latter one is not yet listed as WG milestone in the charter. New milestones for it will be requested after the IETF meeting. The I-D on IPFIX configuration is intended to be aligned with the YANG framework that the NETMOD WG is developing. However, a stable version of YANG is not expected in the near future. Therefore, the WG discussed to split the configuration I-D into a standards track information model and an experimental data model for IPFIX configuration. The idea is to update the experimental data model whenever the work on YANG is concluded. At the session on Monday there was consensus on going this way, but if anyone disagrees, please speak up on the list. Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ack information model and an experimental data model for IPFIX configuration. The idea is to update the experimental data model whenever the work on YANG is concluded. At the session on Monday there was consensus on going this way, but if anyone disagrees, please speak up on the list. Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jul 31 08:21:58 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E523A6806; Thu, 31 Jul 2008 08:21:58 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795F53A67EC for ; Thu, 31 Jul 2008 08:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs4DfDB8Zohd for ; Thu, 31 Jul 2008 08:21:56 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A29193A6806 for ; Thu, 31 Jul 2008 08:21:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 5AFBE2C00035A for ; Thu, 31 Jul 2008 17:20:55 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rujMuDj5G8eP for ; Thu, 31 Jul 2008 17:20:55 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 3E4122C000303 for ; Thu, 31 Jul 2008 17:20:50 +0200 (CEST) Received: from 10.1.2.227 ([10.1.2.227]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Jul 2008 15:20:50 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 31 Jul 2008 17:20:43 +0200 From: Juergen Quittek To: IETF IPFIX Working Group Message-ID: Thread-Topic: WG last call on draft-ietf-ipfix-mib-04 Thread-Index: AcjzIP9uHxeUOVmoh0SQTwWGsiUI0A== Mime-version: 1.0 Subject: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, At our session on Monday we concluded that the IPFIX MIB module draft-ietf-ipfix-mib-04 is ready for WG last call. The call starts today and will last until Friday August 29. The period is longer than the usual two weeks, because during August many people take vacation. Please read the draft! Please send your comments to this mailing list! Please also send a message if you are fine with the draft as it is! Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jul 31 08:21:58 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E523A6806; Thu, 31 Jul 2008 08:21:58 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795F53A67EC for ; Thu, 31 Jul 2008 08:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs4DfDB8Zohd for ; Thu, 31 Jul 2008 08:21:56 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A29193A6806 for ; Thu, 31 Jul 2008 08:21:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 5AFBE2C00035A for ; Thu, 31 Jul 2008 17:20:55 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rujMuDj5G8eP for ; Thu, 31 Jul 2008 17:20:55 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 3E4122C000303 for ; Thu, 31 Jul 2008 17:20:50 +0200 (CEST) Received: from 10.1.2.227 ([10.1.2.227]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Jul 2008 15:20:50 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 31 Jul 2008 17:20:43 +0200 From: Juergen Quittek To: IETF IPFIX Working Group Message-ID: Thread-Topic: WG last call on draft-ietf-ipfix-mib-04 Thread-Index: AcjzIP9uHxeUOVmoh0SQTwWGsiUI0A== Mime-version: 1.0 Subject: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, At our session on Monday we concluded that the IPFIX MIB module draft-ietf-ipfix-mib-04 is ready for WG last call. The call starts today and will last until Friday August 29. The period is longer than the usual two weeks, because during August many people take vacation. Please read the draft! Please send your comments to this mailing list! Please also send a message if you are fine with the draft as it is! Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jul 31 08:24:19 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE753A6CD7; Thu, 31 Jul 2008 08:24:19 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7F23A6CD2 for ; Thu, 31 Jul 2008 08:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdHq+9JKDeTR for ; Thu, 31 Jul 2008 08:24:17 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 311BD3A6CD7 for ; Thu, 31 Jul 2008 08:24:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C46CC2C00035D for ; Thu, 31 Jul 2008 17:24:09 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLS6IZI4PT7Q for ; Thu, 31 Jul 2008 17:24:09 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id A8B7A2C00035B for ; Thu, 31 Jul 2008 17:24:04 +0200 (CEST) Received: from 10.1.2.227 ([10.1.2.227]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Jul 2008 15:24:04 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 31 Jul 2008 17:24:00 +0200 From: Juergen Quittek To: IETF IPFIX Working Group Message-ID: Thread-Topic: WG last call on draft-ietf-ipfix-file-02 Thread-Index: AcjzIXTabtOyrWYJ/EOsMe/m6CitEQ== Mime-version: 1.0 Subject: [IPFIX] WG last call on draft-ietf-ipfix-file-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, At our session on Monday we concluded that the IPFIX file format draft-ietf-ipfix-file-02 is ready for WG last call. The call starts today and will last until Friday August 29. The period is longer than the usual two weeks, because during August many people take vacation. Please read the draft! Please send your comments to this mailing list! Please also send a message if you are fine with the draft as it is! Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jul 31 08:24:19 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE753A6CD7; Thu, 31 Jul 2008 08:24:19 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7F23A6CD2 for ; Thu, 31 Jul 2008 08:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdHq+9JKDeTR for ; Thu, 31 Jul 2008 08:24:17 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 311BD3A6CD7 for ; Thu, 31 Jul 2008 08:24:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C46CC2C00035D for ; Thu, 31 Jul 2008 17:24:09 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLS6IZI4PT7Q for ; Thu, 31 Jul 2008 17:24:09 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id A8B7A2C00035B for ; Thu, 31 Jul 2008 17:24:04 +0200 (CEST) Received: from 10.1.2.227 ([10.1.2.227]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Jul 2008 15:24:04 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 31 Jul 2008 17:24:00 +0200 From: Juergen Quittek To: IETF IPFIX Working Group Message-ID: Thread-Topic: WG last call on draft-ietf-ipfix-file-02 Thread-Index: AcjzIXTabtOyrWYJ/EOsMe/m6CitEQ== Mime-version: 1.0 Subject: [IPFIX] WG last call on draft-ietf-ipfix-file-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, At our session on Monday we concluded that the IPFIX file format draft-ietf-ipfix-file-02 is ready for WG last call. The call starts today and will last until Friday August 29. The period is longer than the usual two weeks, because during August many people take vacation. Please read the draft! Please send your comments to this mailing list! Please also send a message if you are fine with the draft as it is! Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jul 31 08:25:50 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64A83A6CDE; Thu, 31 Jul 2008 08:25:50 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAEC03A6CE2 for ; Thu, 31 Jul 2008 08:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg10ySV0PrFy for ; Thu, 31 Jul 2008 08:25:48 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 6B0F53A6AB4 for ; Thu, 31 Jul 2008 08:25:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1F5442C00035B for ; Thu, 31 Jul 2008 17:25:09 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVBOjzRiqjMT for ; Thu, 31 Jul 2008 17:25:09 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id F204B2C00035A for ; Thu, 31 Jul 2008 17:25:03 +0200 (CEST) Received: from 10.1.2.227 ([10.1.2.227]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Jul 2008 15:25:04 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 31 Jul 2008 17:25:00 +0200 From: Juergen Quittek To: IETF IPFIX Working Group Message-ID: Thread-Topic: WG last call on draft-ietf-ipfix-export-per-sctp-stream-00 Thread-Index: AcjzIZidYjkLbXnNNEaCH+w2LRsgTw== Mime-version: 1.0 Subject: [IPFIX] WG last call on draft-ietf-ipfix-export-per-sctp-stream-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, At our session on Monday we concluded that the IPFIX export per SCTP stream draft-ietf-ipfix-export-per-sctp-stream-00 is ready for WG last call. The call starts today and will last until Friday August 29. The period is longer than the usual two weeks, because during August many people take vacation. Please read the draft! Please send your comments to this mailing list! Please also send a message if you are fine with the draft as it is! Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Jul 31 08:25:50 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64A83A6CDE; Thu, 31 Jul 2008 08:25:50 -0700 (PDT) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAEC03A6CE2 for ; Thu, 31 Jul 2008 08:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg10ySV0PrFy for ; Thu, 31 Jul 2008 08:25:48 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 6B0F53A6AB4 for ; Thu, 31 Jul 2008 08:25:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1F5442C00035B for ; Thu, 31 Jul 2008 17:25:09 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVBOjzRiqjMT for ; Thu, 31 Jul 2008 17:25:09 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id F204B2C00035A for ; Thu, 31 Jul 2008 17:25:03 +0200 (CEST) Received: from 10.1.2.227 ([10.1.2.227]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Jul 2008 15:25:04 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 31 Jul 2008 17:25:00 +0200 From: Juergen Quittek To: IETF IPFIX Working Group Message-ID: Thread-Topic: WG last call on draft-ietf-ipfix-export-per-sctp-stream-00 Thread-Index: AcjzIZidYjkLbXnNNEaCH+w2LRsgTw== Mime-version: 1.0 Subject: [IPFIX] WG last call on draft-ietf-ipfix-export-per-sctp-stream-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, At our session on Monday we concluded that the IPFIX export per SCTP stream draft-ietf-ipfix-export-per-sctp-stream-00 is ready for WG last call. The call starts today and will last until Friday August 29. The period is longer than the usual two weeks, because during August many people take vacation. Please read the draft! Please send your comments to this mailing list! Please also send a message if you are fine with the draft as it is! Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix