Re: [IPFIX] NetFlow v9 to IPFIX conversion

Petr Velan <petr.velan@cesnet.cz> Thu, 16 April 2015 08:09 UTC

Return-Path: <thorgrin@gmail.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D077B1B2BB8 for <ipfix@ietfa.amsl.com>; Thu, 16 Apr 2015 01:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.423
X-Spam-Level: *
X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRgbagozgLqH for <ipfix@ietfa.amsl.com>; Thu, 16 Apr 2015 01:09:29 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA691B2BCC for <ipfix@ietf.org>; Thu, 16 Apr 2015 01:09:28 -0700 (PDT)
Received: by lbbuc2 with SMTP id uc2so52626480lbb.2 for <ipfix@ietf.org>; Thu, 16 Apr 2015 01:09:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VlQ26xeIhQDn2HAS/9OHeaSL0MJoAqjKqKiR0vRD2fI=; b=xtlk71eb29CBiQIq3RZEHF+pVpOkTkboIBytokJJnNuVcAnWTSwVm1a/F3zNSxgnRO 3+e+SqOEalztet82PLz44y6o+wg1lVQZmS20kVsdXiijOVTVDnlEbK6F7f0uqHgn1pHC P/6FhQUhH/iwD/ImOwndKDT6UlCs4JAA5Y1Kf/e73MQ1yrJak96Z4Tjis1dFAVodUiXD fL88SIUn3UFo0aqgFrpaTMekWwR7sDObiVomPgVN5F3GREQXtOycCfLKw+03QNtQfm/8 Da80L19Enlyes1FH7xNF6+H6fArzDQ11loNudjhETw9ygObbOdblVgDl1adTEYWN/U9w aFzg==
MIME-Version: 1.0
X-Received: by 10.152.5.134 with SMTP id s6mr27237890las.6.1429171767075; Thu, 16 Apr 2015 01:09:27 -0700 (PDT)
Sender: thorgrin@gmail.com
Received: by 10.25.16.65 with HTTP; Thu, 16 Apr 2015 01:09:27 -0700 (PDT)
In-Reply-To: <551DA857.2050104@net.in.tum.de>
References: <CALbOe5O0e3tw--vCrj9FkFWVvoMAb9iZaXyRYqfNFSSqQUT94w@mail.gmail.com> <54AC4097.1050602@plixer.com> <CALbOe5M8VtTLANGZDUG=bQH-z6eKLK7ckTPTUY0AueX_ioUs1Q@mail.gmail.com> <551DA857.2050104@net.in.tum.de>
Date: Thu, 16 Apr 2015 10:09:27 +0200
X-Google-Sender-Auth: 63xRJ_ncgVfefQVGe5LL349V9Kk
Message-ID: <CALbOe5OokEaC-d2_mX8qupHMJ3X+udv4a7rOkKU=0GHfwSXxJw@mail.gmail.com>
From: Petr Velan <petr.velan@cesnet.cz>
To: Gerhard Muenz <muenz@net.in.tum.de>
Content-Type: multipart/alternative; boundary="089e013d10107fe9cb0513d2fb37"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipfix/zKtPMiqpEEnglOe6nHNOuynFarE>
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] NetFlow v9 to IPFIX conversion
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 16 Apr 2015 08:09:32 -0000

Hi Gerhard,

the problem we are facing here is that the NetFlow v9 ID space is not
centrally managed, therefore we cannot hope to cover all possible IDs and
vendors, since they can change. Moreover, as you say, the owner of a PEN
maintains his ID registry, therefore we should not use someones PEN just
because he defined the nf9 elements.

What I propose is similar to RFC 5612. We should define an NetFlow to IPFIX
conversion PEN which could be used by anyone for mapping nf9 elements with
ID > 2^15. The ID of that element would not be changed, only the PEN would
be added, which, as an added benefit, would be fairly easy to implement in
IPFIX mediators. No central management is necessary, just as you need to
know the nf9 elements that you use, you would have to know the semantics
from the appropriate vendor. The collisions cannot be avoided, however,
they are not managed in nf9 either.

As you say, there is currently no PEN for general experimental use that
could be used as a fallback. I think that creating a specific PEN for this
task is the right solution.

Best regards,
Petr

On Thu, Apr 2, 2015 at 10:36 PM, Gerhard Muenz <muenz@net.in.tum.de> wrote:

>
> Hi Petr,
>
> I do not understand the use case of the new PEN that you suggest.
>
> It does not make sense to register a PEN for an ID space that is not
> centrally managed in a kind of registry because uniqueness of ID usage must
> be ensured. Usually, the owner of a PEN maintains such a registry.
>
> Is there a registry that lists all vendor specific Netflow 9 Field Types?
> If not, how can you be sure that there are no collisions in the ID space?
>
> I think that you need to find and use the PENs of the vendors that have
> defined the additional Netflow 9 Field Types IEs, regardless of whether the
> IDs are below or above 2^15. Unfortunately, there is no PEN for general
> experimental use (at least I have not found any) that you could use as a
> fallback if you do not find an appropriate vendor PEN.
>
> If you want to use your own non-standard IEs, then you should use the PEN
> of your organization:
>
> 8057
>   CESNET
>     CESNET masters team
>       masters&cesnet.cz
>
> Maybe, you can also use this PEN to map Field Types for which you do not
> find a vendor.
>
> Regards,
> Gerhard
>
>
>
> On 26.03.2015 08:14, Petr Velan wrote:
>
>  Hi Andrew, all,
>
>  thank you for your explanation regarding nprobe.
>
> However, we also need a fallback for unknown exporters with IEs > 2^15.
> The generic requests for PENs need organization name, contact name and
> email address. I can try to request the PEN for NetFlow v9 compatibility
> myself, but I'd like it to be more public. Therefore, I suggest to complete
> the request with something like:
> *Organization Name*: NetFlow v9 to IPFIX
> *Contact Name*: IPFIX WG
> *Contact E-Mail: *ipfix@ietf.org
>
>  This is just a first proposal to get things moving, please add your
> thoughts. Once the PEN is granted, we can move forward and explain its
> purpose in a short RFC.
>
>  Petr
>
> On Tue, Jan 6, 2015 at 9:07 PM, Andrew Feren <andrewf@plixer.com> wrote:
>
>>  Hi Petr,
>>
>> On 01/06/2015 07:03 AM, Petr Velan wrote:
>>
>>     Hello all,
>>
>>  I'm not sure whether this is the right place to ask, but we encountered
>> following problem when converting NetFlow v9 messages to IPFIX.
>>
>>  Some vendors (I've heard of ntop) are using elements IDs large than
>> 32767 in NetFlow v9. When converting messages with these elements to IPFIX,
>> they are considered to be Enterprise Numbers. To generate proper IPFIX
>> message, we need to do one of the following:
>>  a) Generate a list of the elements and map them to PEN of the correct
>> vendor. However, this would result in an attempt to cover all possible
>> elements that anybody used in NetFlow v9. Moreover, we would still have to
>> somehow handle the cases where the element is unknown
>>
>>  This should help with ntop/nprobe
>>
>> Recent versions of nprobe (since version 5.5.5 I think) all use the
>> following mapping.
>>
>> PEN = 35632 and IPFIXID = (v9ID - 57472)
>>
>> For example, one v9 IE that nprobe exports is MYSQL_SERVER_VERSION
>> 57667.  The IPFIX equivalent would be
>> MYSQL_SERVER_VERSION(35632/195).
>>
>> The nprobe docs have a complete list.
>>
>> Older versions of nprobe (pre ~2010) use IEs not in RFC 3954, but later
>> allocated in IANA.  There is no good way to convert those v9 exports to
>> IPFIX.
>>
>> -Andrew
>>
>>
>>    b) Request a PEN for NetFlow compatibility and just add this PEN for
>> every element that has ID larger than 32767.
>>
>>  Personally, I believe that the b) is more general and error-prone. Do
>> you think, that it would be possible to dedicate whole PEN to this cause?
>>
>>  Thank you for any opinions,
>>
>> Petr Velan
>>
>>
>>
>>  _______________________________________________
>> IPFIX mailing listIPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>
>>
>>
>
>
> _______________________________________________
> IPFIX mailing listIPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>
>
>