Re: [IPFIX] [Fwd: I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt]

Gerhard Muenz <muenz@net.in.tum.de> Mon, 23 March 2009 12:57 UTC

Return-Path: <muenz@net.in.tum.de>
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 428793A69D7 for <ipfix@core3.amsl.com>; Mon, 23 Mar 2009 05:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.117
X-Spam-Level:
X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.132, 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 j73QymjFeqCC for <ipfix@core3.amsl.com>; Mon, 23 Mar 2009 05:57:10 -0700 (PDT)
Received: from mail-out2.informatik.tu-muenchen.de (maildmz2.informatik.tu-muenchen.de [131.159.0.15]) by core3.amsl.com (Postfix) with ESMTP id EFDD83A6B03 for <ipfix@ietf.org>; Mon, 23 Mar 2009 05:57:08 -0700 (PDT)
Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 9B2F847DFE; Mon, 23 Mar 2009 13:57:57 +0100 (CET)
Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 8BCCF2766; Mon, 23 Mar 2009 13:57:57 +0100 (CET)
Message-ID: <49C78756.3030204@net.in.tum.de>
Date: Mon, 23 Mar 2009 13:57:58 +0100
From: Gerhard Muenz <muenz@net.in.tum.de>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
References: <49AE3881.3050909@cisco.com>
In-Reply-To: <49AE3881.3050909@cisco.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="------------ms090201070506000706070606"
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: "ipfix@ietf.org" <ipfix@ietf.org>
Subject: Re: [IPFIX] [Fwd: I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt]
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2009 12:57:11 -0000

Hi Benoit, Gowri, Stan, Paul,

I like your approach of structured data types. Such types, especially
the list type, are urgently needed in the context of PSAMP!
Interestingly, you do not mention these applications in the draft. So,
I'll briefly sketch them:

1) PSAMP Selection Sequence Report Interpretation
-------------------------------------------------

Here, RFC5476 explicitly mentions the need for list types:

   Scope:     selectionSequenceId
   Non-Scope: one Information Element mapping the Observation Point
              selectorId (one or more)

   An Information Element representing the Observation Point would
   typically be taken from the ingressInterface, egressInterface,
   lineCardId, exporterIPv4Address, or exporterIPv6Address Information
   Elements (specified in [RFC5102]), but is not limited to those: any
   Information Element specified in [RFC5102] or [RFC5477] can
   potentially be used.  In case of more complex Observation Points
   (such as a list of interfaces, a bus, etc.), a new Information
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Element describing the new type of Observation Point must be
   specified, along with an Options Template Record describing it in
   more detail (if necessary).

In fact, this is the business case that you pretend not to see for
Options Templates in 5.2 of your draft ;)


2) PSAMP Property Match Filtering
---------------------------------

From RFC75476:

   When multiple different Information Elements are defined, the filter
   acts as a logical AND.  Note that the logical OR is not covered by
   these PSAMP specifications.

In practice, a logical OR is urgently needed. See my recent discussion
with Andrew on the ML:
http://www.ietf.org/mail-archive/web/ipfix/current/msg04802.html

In draft-sommer-ipfix-mediator-ext-01, we proposed ADTs orderedList,
orderedPair, and portRanges which allow the definition new IEs for port
ranges etc. Your proposal is more generic as it does not require the
specification of a new IE for every purpose where a list is needed.

The OR-semantic of a filter could be solved with a new Information
Element anyList which is derived from the ADT basicList. In contrast to
IE basicList, anyList introduces the semantic that exactly one of the
reported values was observed. As a consequence, we can export an anyList
of port numbers in Property Match Filtering in order to describe a
filter that selects packets given a list of port numbers.


I would appreciate if the above issues were addressed in a future
version of your draft!


Further comments:

>      3.1. IPFIX Limitations 
> ...
>       To export this information in IPFIX, the data would need to be 
>       flattened (thus losing the hierarchical relationships) and a new 
>       IPFIX Template created for each alert, according to the number of 
>       applicationID elements in each target, the number of targets and 
>       attackers in each participant and the number of participants in 
>       each alert.  Clearly each Template will be unique to each alert, 
>       and a large amount of CPU, memory and export bandwith will be 

bandwidth

>       wasted creating, exporting, maintaining, and withdrawing the 
>       Templates.  

>      4.4.1. basicList 
> ...
>        BasicList Content
>        
>           A Collection Process decodes list elements from the BasicList 
>           Content until no further data remains.  A record count is not 
>           included but can be derived when the Information Element is 
>           decoded. 

Replace record count by field count?

>      5.2. Structured Data Information Elements Applicability in Options 
>         Template Sets 
> 
>       All the examples in this document uses the Structured Data 

use

>       Information Elements, abstract data types, and data type semantic 
>       in Template Sets.  However, they could also be used in and Options 

remove "and"

>       Template Sets. 


>     8.1. Encoding BasicList 
> 
>       Consider encoding an user_record containing the following data: 

a user_record


Regards,
Gerhard


Benoit Claise wrote:
> Dear all,
> 
> Here is a new IPFIX draft.
> I think that the abstract is quite clear about its goal.
> 
> Regards, Benoit.
> 
> -------- Original Message --------
> Subject: 	I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt
> Date: 	Tue, 3 Mar 2009 15:15:01 -0800 (PST)
> From: 	Internet-Drafts@ietf.org
> Reply-To: 	internet-drafts@ietf.org
> To: 	i-d-announce@ietf.org
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Export of Structured Data in IPFIX
> 	Author(s)	: B. Claise, G. Dhandapani, S. Yates, P. Aitken
> 	Filename	: draft-claise-structured-data-in-ipfix-00.txt
> 	Pages		: 36
> 	Date		: 2009-3-3
> 	
>         This document specifies an extension to IP Flow Information 
>         eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX 
>         information model specified in [RFC5102] to support hierarchical 
>         structured data and lists (sequences) of Information Elements in 
>         data records.  This extension allows definition of complex data 
>         structures such as variable-length lists and specification of 
>         hierarchical containment relationships between Templates. 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-claise-structured-data-in-ipfix-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.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: muenz@net.in.tum.de    WWW: http://www.net.in.tum.de/~muenz