From nobody Sat Jan 3 19:19:06 2015 Return-Path: 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 E07D81A1B06 for ; Sat, 3 Jan 2015 19:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Yjn1vkUYZzt0 for ; Sat, 3 Jan 2015 19:18:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815DE1A1B03 for ; Sat, 3 Jan 2015 19:18:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQV32491; Sun, 04 Jan 2015 03:18:54 +0000 (GMT) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 4 Jan 2015 03:18:51 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.153]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Sun, 4 Jan 2015 11:18:45 +0800 From: "Hedanping (Ana)" To: Paul Aitken , "ipfix@ietf.org" , "ipfix-chairs@tools.ietf.org" , "stbryant@cisco.com" , Benoit Claise , Andrew Feren Thread-Topic: Comments needed for draft-fu-ipfix-network-security-00 Thread-Index: AdAgDDK1FVa1OpepS8CUXrZ5IZppbADPbpNgASAqbqA= Date: Sun, 4 Jan 2015 03:18:45 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D90E3F1@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D90DB24@szxeml557-mbs.china.huawei.com> <23B7BE54EACBED43957AB709C564F7B701857F3D09@EMEA-EXCH01.corp.brocade.com> In-Reply-To: <23B7BE54EACBED43957AB709C564F7B701857F3D09@EMEA-EXCH01.corp.brocade.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.95.23] Content-Type: multipart/alternative; boundary="_000_77FA386512F0D748BC7C02C36EB1106D90E3F1szxeml557mbschina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/L3ERHfxqGlxWoXq1Xg1cqWc0U0g Cc: "draft-fu-ipfix-network-security@tools.ietf.org" Subject: Re: [IPFIX] Comments needed for draft-fu-ipfix-network-security-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 03:19:05 -0000 --_000_77FA386512F0D748BC7C02C36EB1106D90E3F1szxeml557mbschina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, Thank you very much for the comments, please see my reply inline. The main purpose of this draft is to request some new IPFIX Information Ele= ments, which can be done through IANA without necessarily requiring a draft= or RFC to be written. Eg, use this form: http://www.iana.org/cgi-bin/assig= nments.pl [A] If we only register those IEs to IANA without requiring a RFC, people w= on't understand why those new IEs are needed and how they can be used. As a= result, the better way is to standardize the proposed IEs. A draft is valuable if it's necessary to clarify how the new Information El= ements should be used together or with existing Information Elements, or to= define templates or timeouts which should be used. Section 3 of this docum= ent addressed some of this. However in the current case I think that the el= ements could be requested from IANA even without this information. [A] That's a very good point! The existing IEs are useful in flow analysis,= but still they lack necessary information to distinguish abnormal cases fr= om the normal operation. The current version of draft is for group discussi= on purpose, the new IEs should be used in combination of existing IEs such = as the five-tuple, start time, end time. Another important point is that we proposed to modify existing sampling met= hod to session based sampling at the forwarding plane. This sampling mecha= nism ensures that all the packets of the same session can be sampled, rathe= r than randomly selecting packets of a flow that contains different session= s. Section 3.2, upstream/downstream counters: * How will the proposed counters help to distinguish between an att= ack and access to a recently published web content? [A] The proposed counters can be used to efficiently detect DDOS attack. Wh= ere the upstream counter is far greater than the downstream counter value, = a DDOS attack is likely to happen. One example is the SNMP attack, the norm= al ratio between up and down should be around 1:1, when an attack happens, = the ratio will rise to more than 20:1. Through such observation, the securi= ty issue can be discovered effectively, and proper countermeasures will be = taken in time Section 3.6, FlowEndReason: * Since the new flowEndReason value is not mentioned in section 5 (= IANA), it may easily be overlooked. [A] Yes. The new values will be added to section 5 in the next version ^_^ Section 5, IANA: * For pktUpstreamCount, pktDownstreamCount, octetUpstreamCount, and= octetDownstreamCount, it's necessary to define what "upstream" and "downst= ream" mean. The semantics for these fields may be totalCounter or deltaCoun= ter. [A] Good point, upstream is from client to server, downstream is from serv= er to client, We propose to use session based sampling, thus totalCounter is sufficient t= o be their semantics. * How can a generic applicationErrorCode be standardized? It would = be necessary to pair it with information identifying the exact application = which generated the error code. However sections 2 and 3.5 suggests this is= actually the RFC 2616 HTTP status code - so please name it more appropriat= ely, and in the description clarify that it's the RFC 2616 code. [A] The applicationErrorCode is not only the HTTP status code. It can be th= e error code of application layer protocols, e. g. the FTP, HTTP, DNS and s= o on. * Why are fragmentIncomplete, fragmentFirstTooShort, fragmentOffest= Error and fragmentFlagError unsigned32? Perhaps these should be Boolean. Ho= wever, what value should they take when fragmentation does not apply to the= flows? [A] A fragmentation attack cannot be determined through only one packet fra= gmentation error, instead it should be observed based upon a historic/integ= rated view of packets of that session, which is the reason why they are cou= nters of unsigned32. For example, 1000 packets were transmitted in a session, among which 500 pa= ckets have fragmentation error, it is likely that a fragment attack happens= . If there is no fragmentation, their values should be 0. * icmpEchoCount and icmpEchoReplyCount semantics may be totalCounte= r or deltaCounter. [A] In this case, totalCounter is sufficient for session based sampling. Cheers, Ana From: Paul Aitken [mailto:paitken@Brocade.com] Sent: Monday, December 29, 2014 6:43 PM To: Hedanping (Ana); ipfix@ietf.org; ipfix-chairs@tools.ietf.org; stbryant@= cisco.com; Benoit Claise; Andrew Feren Cc: draft-fu-ipfix-network-security@tools.ietf.org Subject: RE: Comments needed for draft-fu-ipfix-network-security-00 Ana, The main purpose of this draft is to request some new IPFIX Information Ele= ments, which can be done through IANA without necessarily requiring a draft= or RFC to be written. Eg, use this form: http://www.iana.org/cgi-bin/assig= nments.pl A draft is valuable if it's necessary to clarify how the new Information El= ements should be used together or with existing Information Elements, or to= define templates or timeouts which should be used. Section 3 of this docum= ent addressed some of this. However in the current case I think that the el= ements could be requested from IANA even without this information. Section 3.2, upstream/downstream counters: * How will the proposed counters help to distinguish between an att= ack and access to a recently published web content? Section 3.6, FlowEndReason: * Since the new flowEndReason value is not mentioned in section 5 (= IANA), it may easily be overlooked. Section 5, IANA: * For pktUpstreamCount, pktDownstreamCount, octetUpstreamCount, and= octetDownstreamCount, it's necessary to define what "upstream" and "downst= ream" mean. The semantics for these fields may be totalCounter or deltaCoun= ter. * How can a generic applicationErrorCode be standardized? It would = be necessary to pair it with information identifying the exact application = which generated the error code. However sections 2 and 3.5 suggests this is= actually the RFC 2616 HTTP status code - so please name it more appropriat= ely, and in the description clarify that it's the RFC 2616 code. * Why are fragmentIncomplete, fragmentFirstTooShort, fragmentOffest= Error and fragmentFlagError unsigned32? Perhaps these should be Boolean. Ho= wever, what value should they take when fragmentation does not apply to the= flows? * icmpEchoCount and icmpEchoReplyCount semantics may be totalCounte= r or deltaCounter. P. From: Hedanping (Ana) [mailto:ana.hedanping@huawei.com] Sent: 25 December 2014 06:30 To: ipfix@ietf.org; ipfix-chairs@tools.ietf.org; stbryant@cisco.com; Paul Aitken; Benoit Claise; Andrew Feren Cc: draft-fu-ipfix-network-security@tools.ietf.org Subject: Comments needed for draft-fu-ipfix-network-security-00 All, We wrote a draft to extend standard Information Elements for inspecting net= work security (e.g. the fragment attack in ICMP, TCP and UDP; and DDOS atta= ck). Compared with packet/Byte based sampling, session based sampling is pr= oposed and will be more useful for efficient and effective security inspect= ion. The link of the draft is as follow, where the proposed IEs are described: https://tools.ietf.org/html/draft-fu-ipfix-network-security-00 Your comments are welcome! Merry holidays and happy new year! Danping --_000_77FA386512F0D748BC7C02C36EB1106D90E3F1szxeml557mbschina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul,

Thank you very much for the comments, please see my reply inline.=

 

The main purpose of this draft is to request some new IPFIX Infor= mation Elements, which can be done through IANA without necessarily requiri= ng a draft or RFC to be written. Eg, use this form: http://w= ww.iana.org/cgi-bin/assignments.pl

 

[A] If we only register those IEs to IANA without requiring a = RFC, people won’t understand why those new IEs are needed and how the= y can be used. As a result, the better way is to standardize the proposed IEs.

&n= bsp;

A draft is valuable if it’s necessary to clarify how the ne= w Information Elements should be used together or with existing Information= Elements, or to define templates or timeouts which should be used. Section 3 of this document addressed some of this. H= owever in the current case I think that the elements could be requested fro= m IANA even without this information.

 

[A] That’s a very good point! The existing IEs are usefu= l in flow analysis, but still they lack necessary information to distinguis= h abnormal cases from the normal operation. The current version of draft is for group discussion purpose, the new IEs = should be used in combination of existing IEs such as the five-tuple, start= time, end time.

Another important point is that we proposed to modify existing= sampling method to session based sampling at the forwarding plane.  T= his sampling mechanism ensures that all the packets of the same session can be sampled, rather than randomly selecting= packets of a flow that contains different sessions.<= /p>

 

Section 3.2, upstream/downstream counters:

 

·= ;   &= nbsp;     How will the proposed counters help to distinguish betwee= n an attack and access to a recently published web content?

[A] The proposed counters can be used to efficiently detect DD= OS attack. Where the upstream counter is far greater than the downstream co= unter value, a DDOS attack is likely to happen. One example is the SNMP attack, the normal ratio between up and do= wn should be around 1:1, when an attack happens, the ratio will rise to mor= e than 20:1. Through such observation, the security issue can be discovered= effectively, and proper countermeasures will be taken in time

&n= bsp;

Section 3.6, FlowEndReason:

 

·= ;   &= nbsp;     Since the new flowEndReason value is not mentioned in sec= tion 5 (IANA), it may easily be overlooked.

[A] Yes. The new values will be added to section 5 in the= next version ^_^

 

Section 5, IANA:

 

·= ;   &= nbsp;     For pktUpstreamCount, pktDownstreamCount, octetUpstreamCo= unt, and octetDownstreamCount, it’s necessary to define what “u= pstream” and “downstream” mean. The semantics for these fields may be totalCounter or deltaCounter.

[A] Good point, upstream is from client to server,  downs= tream is from server to client,

We propose to use session based sampling, thus totalCounter is= sufficient to be their semantics.

 

·= ;   &= nbsp;     How can a generic applicationErrorCode be standardized? I= t would be necessary to pair it with information identifying the exact appl= ication which generated the error code. However sections 2 and 3.5 suggests this is actually the RFC 2616 HTTP sta= tus code – so please name it more appropriately, and in the descripti= on clarify that it’s the RFC 2616 code.

[A] The applicationErrorCode is not only the HTTP status code.= It can be the error code of application layer protocols, e. g. the FTP, HT= TP, DNS and so on.

·= ;   &= nbsp;     Why are fragmentIncomplete, fragmentFirstTooShort, fragme= ntOffestError and fragmentFlagError unsigned32? Perhaps these should be Boo= lean. However, what value should they take when fragmentation does not apply to the flows?

[A] A fragmentation attack cannot be determined through only o= ne packet fragmentation error, instead it should be observed based upon a h= istoric/integrated view of packets of that session, which is the reason why they are counters of unsigned32.

For example, 1000 packets were transmitted in a session, among= which 500 packets have fragmentation error, it is likely that a fragment a= ttack happens.

If there is no fragmentation, their values should be 0.

 

·= ;   &= nbsp;     icmpEchoCount and icmpEchoReplyCount semantics may be tot= alCounter or deltaCounter.

[A] In this case, totalCounter is sufficient for session based= sampling.

 

Cheers,

Ana

&n= bsp;

From: Paul Aitken = [mailto:paitken@Brocade.com]
Sent: Monday, December 29, 2014 6:43 PM
To: Hedanping (Ana); ipfix@ietf.org; ipfix-chairs@tools.ietf.org; st= bryant@cisco.com; Benoit Claise; Andrew Feren
Cc: draft-fu-ipfix-network-security@tools.ietf.org
Subject: RE: Comments needed for draft-fu-ipfix-network-security-00<= o:p>

 

Ana,

 

The main purpose of this draft is to request some new IPFIX Infor= mation Elements, which can be done through IANA without necessarily requiri= ng a draft or RFC to be written. Eg, use this form: http://w= ww.iana.org/cgi-bin/assignments.pl

 

A draft is valuable if it’s necessary to clarify how the ne= w Information Elements should be used together or with existing Information= Elements, or to define templates or timeouts which should be used. Section 3 of this document addressed some of this. H= owever in the current case I think that the elements could be requested fro= m IANA even without this information.

 

 

Section 3.2, upstream/downstream counters:

 

·= ;   &= nbsp;     How will the proposed counters help to distinguish betwee= n an attack and access to a recently published web content?

 

 

Section 3.6, FlowEndReason:

 

·= ;   &= nbsp;     Since the new flowEndReason value is not mentioned in sec= tion 5 (IANA), it may easily be overlooked.

 

 

Section 5, IANA:

 

·= ;   &= nbsp;     For pktUpstreamCount, pktDownstreamCount, octetUpstreamCo= unt, and octetDownstreamCount, it’s necessary to define what “u= pstream” and “downstream” mean. The semantics for these fields may be totalCounter or deltaCounter.

·= ;   &= nbsp;     How can a generic applicationErrorCode be standardized? I= t would be necessary to pair it with information identifying the exact appl= ication which generated the error code. However sections 2 and 3.5 suggests this is actually the RFC 2616 HTTP sta= tus code – so please name it more appropriately, and in the descripti= on clarify that it’s the RFC 2616 code.

·= ;   &= nbsp;     Why are fragmentIncomplete, fragmentFirstTooShort, fragme= ntOffestError and fragmentFlagError unsigned32? Perhaps these should be Boo= lean. However, what value should they take when fragmentation does not apply to the flows?

·= ;   &= nbsp;     icmpEchoCount and icmpEchoReplyCount semantics may be tot= alCounter or deltaCounter.

 

 

P.

 

 

From: Hedanping (A= na) [mailto:ana.hedanping@huawe= i.com]
Sent: 25 December 2014 06:30
To: ipfix@ietf.org; ipfix-chairs@tools.ietf.org; stbr= yant@cisco.com; Paul Aitken; Benoit Claise; Andrew Feren
Cc: draft-fu-ipfix-network-security@tools.ietf.org
Subject: Comments needed for draft-fu-ipfix-network-security-00=

 

All,

We wrote a draft to extend s= tandard Information Elements for inspecting network security (e.g. the frag= ment attack in ICMP, TCP and UDP; and DDOS attack). Compared with packet/By= te based sampling, session based sampling is proposed and will be more useful for efficient and effective security i= nspection.

 

The link of the draft is as = follow, where the proposed IEs are described:

https://tools.ietf.org/html/= draft-fu-ipfix-network-security-00

 

Your comments are welcome!

 

Merry holidays and happy new= year!

Danping

 

--_000_77FA386512F0D748BC7C02C36EB1106D90E3F1szxeml557mbschina_-- From nobody Sun Jan 4 04:02:22 2015 Return-Path: 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 981311A1A3A; Sun, 4 Jan 2015 04:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 PVFZhTQ9AO5L; Sun, 4 Jan 2015 04:02:18 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id C031D1A87E3; Sun, 4 Jan 2015 04:02:18 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 276E1183137; Sun, 4 Jan 2015 04:02:02 -0800 (PST) To: paitken@brocade.com, bclaise@cisco.com, trammell@tik.ee.ethz.ch, paitken@cisco.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150104120202.276E1183137@rfc-editor.org> Date: Sun, 4 Jan 2015 04:02:02 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/90yhjcy0nq66FimbpZxS0-lXBsk Cc: iesg@ietf.org, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Errata Held for Document Update] RFC7011 (4216) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 12:02:20 -0000 The following errata report has been held for document update for RFC7011, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7011&eid=4216 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Paul Aitken Date Reported: 2014-12-31 Held by: Benoit Claise (IESG) Section: 3.4.2.2 Original Text ------------- Scope Field Count Number of scope fields in this Options Template Record. The Scope Fields are normal Fields, except that they are interpreted as scope at the Collector. A scope field count of N specifies that the first N Field Specifiers in the Template Record are Scope Fields. The Scope Field Count MUST NOT be zero. Corrected Text -------------- Scope Field Scope Fields are normal Fields, except that they are interpreted as scope at the Collector. Scope Field Count Number of scope fields in this Options Template Record. A scope field count of N specifies that the first N Field Specifiers in the Template Record are Scope Fields. The Scope Field Count MUST NOT be zero. Notes ----- Separate out the "Scope Field" definition from "Scope Field Count", since "Scope Field" is used as a defined term throughout the document without a formal definition. -------------------------------------- RFC7011 (draft-ietf-ipfix-protocol-rfc5101bis-10) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information Publication Date : September 2013 Author(s) : B. Claise, Ed., B. Trammell, Ed., P. Aitken Category : INTERNET STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Sun Jan 4 04:04:47 2015 Return-Path: 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 866E01A8824; Sun, 4 Jan 2015 04:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 OLkGq_7Z3-75; Sun, 4 Jan 2015 04:04:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4141A87E3; Sun, 4 Jan 2015 04:04:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150104120443.1603.91856.idtracker@ietfa.amsl.com> Date: Sun, 04 Jan 2015 04:04:43 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/0YkzrXwbQ3JpmubHVuVbT9vqHZY Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-08.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 12:04:45 -0000 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 MIB Variables using the IPFIX Protocol Authors : Paul Aitken Benoit Claise Colin McDowall Juergen Schoenwaelder Filename : draft-ietf-ipfix-mib-variable-export-08.txt Pages : 76 Date : 2014-12-31 Abstract: This document specifies a way to complement IPFIX Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified. An IPFIX Options Template and method are specified, which are used to export the extra information required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-mib-variable-export/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mib-variable-export-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 5 01:57:29 2015 Return-Path: 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 5A89F1A1F04 for ; Mon, 5 Jan 2015 01:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 myHovuwIULEN for ; Mon, 5 Jan 2015 01:57:25 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2410B1A1BB8 for ; Mon, 5 Jan 2015 01:57:25 -0800 (PST) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id t059SGT6015682 for ; Mon, 5 Jan 2015 01:57:24 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1rnk7myw51-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 05 Jan 2015 01:57:23 -0800 Received: from BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 5 Jan 2015 01:57:22 -0800 Received: from brm-excashub-1.corp.brocade.com (172.16.186.49) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 5 Jan 2015 02:57:22 -0700 Received: from EMEAWP-CASH02.corp.brocade.com (172.29.19.10) by brm-excashub-1.corp.brocade.com (172.16.186.74) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 5 Jan 2015 02:57:21 -0700 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH02.corp.brocade.com ([fe80::548c:8759:5d5e:1c0b%12]) with mapi; Mon, 5 Jan 2015 10:57:20 +0100 From: Paul Aitken To: "ipfix@ietf.org" Date: Mon, 5 Jan 2015 10:57:17 +0100 Thread-Topic: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-08.txt Thread-Index: AdAoFqYE9OvfK6XoTBKt9jGZfKX+wgAtOc3A Message-ID: <23B7BE54EACBED43957AB709C564F7B701857F40BC@EMEA-EXCH01.corp.brocade.com> References: <20150104120443.1603.91856.idtracker@ietfa.amsl.com> In-Reply-To: <20150104120443.1603.91856.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-05_01:2015-01-02,2015-01-04,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501050104 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/xPIf-GU_ApW3P_q70cingkpbZgY Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-08.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 09:57:27 -0000 Dear IPFIX experts, The -08 version of this draft addresses Juergen Schoenwaelder's feedback in http://www.ietf.org/mail-archive/web/ipfix/current/msg07271.html Please review the updated draft, or at least the diff ;-) It'd be super if someone could independently verify the figures, to prevent me from opening further errata in future! With this update, I have no further actions for this draft. A summary of the changes is: * use of "Scope Field" as a defined term per errata 4216. (This was used, though not defined, in RFC 7011.) * changed mibObjectValueBits to octetArray with the following additional text: The flags or bits are encoded as per the standard IPFIX Abstract Data Type of octetArray, with sufficient length to accomodate the required number of bits. If the number of bits is not an integer multiple of octets then the most significant bits at end of the octetArray MUST be set to zero. * corrected Length in many of the figures. * renamed SNMPtotalCounter to snmpCounter * renamed SNMPgauge to snmpGuage * changed my affiliation. * many small editorial corrections and improvements to the text. Thanks, P. > -----Original Message----- > From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 04 January 2015 12:05 > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org > Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-08.txt > > > 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 MIB Variables using the IPFIX Protocol > Authors : Paul Aitken > Benoit Claise > Colin McDowall > Juergen Schoenwaelder > Filename : draft-ietf-ipfix-mib-variable-export-08.txt > Pages : 76 > Date : 2014-12-31 > > Abstract: > This document specifies a way to complement IPFIX Data Records with > Management Information Base (MIB) objects, avoiding the need to > define new IPFIX Information Elements for existing Management > Information Base objects that are already fully specified. > > An IPFIX Options Template and method are specified, which are used to > export the extra information required to fully describe Simple > Network Management Protocol (SNMP) MIB objects in IPFIX. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-mib-variable-export/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mib-variable-export-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From nobody Mon Jan 5 02:09:26 2015 Return-Path: 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 E36CB1A1BB8 for ; Mon, 5 Jan 2015 02:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 gk0GO1oxQ-rT for ; Mon, 5 Jan 2015 02:09:21 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4AC1A047A for ; Mon, 5 Jan 2015 02:09:21 -0800 (PST) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id t059RuGf015093; Mon, 5 Jan 2015 02:09:20 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1rnk7mywqw-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 05 Jan 2015 02:09:20 -0800 Received: from BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 5 Jan 2015 02:09:19 -0800 Received: from EMEAWP-CASH01.corp.brocade.com (172.29.18.10) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 5 Jan 2015 03:09:19 -0700 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH01.corp.brocade.com ([::1]) with mapi; Mon, 5 Jan 2015 11:09:17 +0100 From: Paul Aitken To: Juergen Schoenwaelder , "ipfix@ietf.org" Date: Mon, 5 Jan 2015 11:09:14 +0100 Thread-Topic: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 Thread-Index: AdAaBF4AnY0Vd+m1SO6RBJ1L54xa8gK7EqBA Message-ID: <23B7BE54EACBED43957AB709C564F7B701857F40D7@EMEA-EXCH01.corp.brocade.com> References: <20141217141829.GA67945@elstar.local> In-Reply-To: <20141217141829.GA67945@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-05_01:2015-01-02,2015-01-04,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501050104 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/RgVfkLGVmaWc40nhyrb9T7cM7MQ Subject: Re: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 10:09:24 -0000 Juergen, thanks for your careful review and all your feedback. I've addressed all your points except one: - p46: Why is the Field Length of mibObjectValueOctetString set to 16? The interface names in general have variable length. Fixed length is used to simplify the example data record in figure 31. Although interfaces generally do have variable length names, I believe the example is clearer with fixed length fields. Changing to variable length would be straightforward if the consensus is that it's more realistic example. P. > -----Original Message----- > From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: 17 December 2014 14:19 > To: ipfix@ietf.org > Subject: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 > > Hi, > > here is my review of draft-ietf-ipfix-mib-variable-export-07. Most of the > comments are editorial or bug fixes. There is only one real technical concern > related to the encoding of BITS. The current I-D uses a 64-bit unsigned integer, > which limits things to 64 bit positions. The SMIv2 does not have this limit - it only > warns about bit positions in excess of 128. > > - RFC4293 is listed as a normative reference but as far as I can tell > it is only used in an example. I suggest to make this an informative > reference. > > - p3: 2nd paragraph Introduction: I am not sure the statement "there > are no dependencies between the SMIv2 and the SNMP protocol" is > correct. Perhaps the simplest fix is to simply delete the whole > paragraph. > > - p4: 1st paragraph Motivation: The 2nd sentence is hard to follow. > > - p5: s/does not specify SNMP notifications/does not specify how to > carry SNMP notifications in IPFIX/ > > - p9: s/in a certain MIB/in a certain MIB module/ > > - p10: s/may be also be/may also be/ > > - p10: s/described by the MIB./described by the MIB module./ > > - p14: s/when when/when/ > > - p14: s/references sections/referenced sections/ > > The fact that every listed item refers to two sections may be a bit > confusing, perhaps change to > > o mibIndexIndicator (defined in Section 5.8.5, example in Section 11.2.2.3) > > - p20: It took me a while to spot the difference between Fig. 7 and > Fig.8 (I did not immediately spot that the fields are > swapped). Perhaps mention this more explicitly in the last paragraph > on p19? > > Figure 7 shows an IPFIX Options Template Set using Scope Existing > IFPIX IE and a Non Scope mibObjectValueInteger IE, while Figure 8 > shows an IPFIX Options Template Set using a Scope > mibObjectValueInteger IE and a Non Scope Existing IFPIX IE. > > - p12: s/name of the MIB/name of the MIB module/ > > - p26: s/present the same order/present in the same order/ > > - p32: s/not defined as possible/not possible/ > > - p37: s/CISCO-PROCESS_MIB/CISCO-PROCESS-MIB/ > > - p45: s/ifMTU/ifMtu/ (this shows up several time, do a global replace) > > - p46: Why is the Field Length of mibObjectValueOctetString set to 16? > The interface names in general have variable length. > > - p47: why 'ifName = ""'? > > - p52: s/index by IEs:/indexed by IEs:/ > > - p58: The VLEN and the OID value seem to be wrong. I think this should > be VLEN=10 and the OID value 06082B060102010E0A01. > > - p61: I would have named SNMPtotalCounter simply snmpCounter and I > would have named SNMPgauge snmpGauge. If this change is > adopted, then these names needs to be changed in several > places. > > - p64: The encoding of mibObjectValueBits may need to specify how the > bit positions are counted. That said, there is an issue here > with using unsigned64. RFC 2578 does not restrict the bit > positions, it only warns that using bit positions in excess of > 128 may cause interoperability problems. The IPFIX I-D > essentially limits this to 64 bits. The obvious solution is to > follow the SNMP encoding rules that encode bits into an octet > string (an octetArray in IPFIX speak). > > - p67: s/as defined in a MIB// > > - p68: OLD > > Description: A non-negative sub-identifier. One Sub number from > an Object Identifier (OID). > > NEW > > Description: A non-negative sub-identifier of an Object > Identifier (OID). > > - p69: s/was retrieved from SNMP/was retrieved from the MIB/ > > - p70: s/could be sampled by SNMP/has been sampled/ > > - p70: s/SNMP sampling time/sampling time/ > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From nobody Mon Jan 5 02:43:00 2015 Return-Path: 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 EA2751A1B63 for ; Mon, 5 Jan 2015 02:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 nj8pG3_5X_xc for ; Mon, 5 Jan 2015 02:42:51 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5761A3BA0 for ; Mon, 5 Jan 2015 02:42:51 -0800 (PST) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id t05AQTZl003458; Mon, 5 Jan 2015 02:42:06 -0800 Received: from brmwp-exchub01.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 1rqruk00pv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 05 Jan 2015 02:42:05 -0800 Received: from brm-excashub-1.corp.brocade.com (172.16.186.74) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 5 Jan 2015 03:42:04 -0700 Received: from EMEAWP-CASH01.corp.brocade.com (172.29.18.10) by brm-excashub-1.corp.brocade.com (172.16.186.74) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 5 Jan 2015 03:42:03 -0700 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH01.corp.brocade.com ([::1]) with mapi; Mon, 5 Jan 2015 11:42:02 +0100 From: Paul Aitken To: "Hedanping (Ana)" , "ipfix@ietf.org" , "ipfix-chairs@tools.ietf.org" , "stbryant@cisco.com" , Benoit Claise , Andrew Feren Date: Mon, 5 Jan 2015 11:42:00 +0100 Thread-Topic: Comments needed for draft-fu-ipfix-network-security-00 Thread-Index: AdAgDDK1FVa1OpepS8CUXrZ5IZppbADPbpNgASAqbqAAQUjPQA== Message-ID: <23B7BE54EACBED43957AB709C564F7B701857F4115@EMEA-EXCH01.corp.brocade.com> References: <77FA386512F0D748BC7C02C36EB1106D90DB24@szxeml557-mbs.china.huawei.com> <23B7BE54EACBED43957AB709C564F7B701857F3D09@EMEA-EXCH01.corp.brocade.com> <77FA386512F0D748BC7C02C36EB1106D90E3F1@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D90E3F1@szxeml557-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_23B7BE54EACBED43957AB709C564F7B701857F4115EMEAEXCH01cor_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-05_01:2015-01-05,2015-01-04,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501050109 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/HgPF0lZQ7R4pm7cA0t2izQKbt74 Cc: "draft-fu-ipfix-network-security@tools.ietf.org" Subject: Re: [IPFIX] Comments needed for draft-fu-ipfix-network-security-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 10:42:59 -0000 --_000_23B7BE54EACBED43957AB709C564F7B701857F4115EMEAEXCH01cor_ Content-Type: text/plain; charset="us-ascii" Ana, please find some replies inline. Thanks, P. From: Hedanping (Ana) [mailto:ana.hedanping@huawei.com] Sent: 04 January 2015 03:19 To: Paul Aitken; ipfix@ietf.org; ipfix-chairs@tools.ietf.org; stbryant@cisco.com; Benoit Claise; Andrew Feren Cc: draft-fu-ipfix-network-security@tools.ietf.org Subject: RE: Comments needed for draft-fu-ipfix-network-security-00 Hi Paul, Thank you very much for the comments, please see my reply inline. The main purpose of this draft is to request some new IPFIX Information Elements, which can be done through IANA without necessarily requiring a draft or RFC to be written. Eg, use this form: http://www.iana.org/cgi-bin/assignments.pl [A] If we only register those IEs to IANA without requiring a RFC, people won't understand why those new IEs are needed and how they can be used. As a result, the better way is to standardize the proposed IEs. [P] Exactly - so the value of this draft lies not so much in defining the new Information Elements (Section 5), as in explaining how to use them (Section 3). Since there's already a proposal to close the IPFIX WG, section 3 has to be very strong to justify this draft since it would have to be AD-sponsored if the WG closes. A draft is valuable if it's necessary to clarify how the new Information Elements should be used together or with existing Information Elements, or to define templates or timeouts which should be used. Section 3 of this document addressed some of this. However in the current case I think that the elements could be requested from IANA even without this information. [A] That's a very good point! The existing IEs are useful in flow analysis, but still they lack necessary information to distinguish abnormal cases from the normal operation. The current version of draft is for group discussion purpose, the new IEs should be used in combination of existing IEs such as the five-tuple, start time, end time. Another important point is that we proposed to modify existing sampling method to session based sampling at the forwarding plane. This sampling mechanism ensures that all the packets of the same session can be sampled, rather than randomly selecting packets of a flow that contains different sessions. [P] Note that it's possible for the new Information Elements to be used in other ways which you don't expect, for example in a flow which *does* contain different sessions. Section 3.2, upstream/downstream counters: * How will the proposed counters help to distinguish between an attack and access to a recently published web content? [A] The proposed counters can be used to efficiently detect DDOS attack. Where the upstream counter is far greater than the downstream counter value, a DDOS attack is likely to happen. One example is the SNMP attack, the normal ratio between up and down should be around 1:1, when an attack happens, the ratio will rise to more than 20:1. Through such observation, the security issue can be discovered effectively, and proper countermeasures will be taken in time [P] Right, I understand that. How will the counters distinguish the two cases? Section 3.6, FlowEndReason: * Since the new flowEndReason value is not mentioned in section 5 (IANA), it may easily be overlooked. [A] Yes. The new values will be added to section 5 in the next version ^_^ Section 5, IANA: * For pktUpstreamCount, pktDownstreamCount, octetUpstreamCount, and octetDownstreamCount, it's necessary to define what "upstream" and "downstream" mean. The semantics for these fields may be totalCounter or deltaCounter. [A] Good point, upstream is from client to server, downstream is from server to client, [P] How will a Metering Process know which direction the traffic is flowing in order to determine upstream or downstream? Especially in the situation when it doesn't observe the first packet(s) in the flow? We propose to use session based sampling, thus totalCounter is sufficient to be their semantics. [P] While that helps with your use case, note that other implementations may use these elements in different ways, for example without session based sampling. * How can a generic applicationErrorCode be standardized? It would be necessary to pair it with information identifying the exact application which generated the error code. However sections 2 and 3.5 suggests this is actually the RFC 2616 HTTP status code - so please name it more appropriately, and in the description clarify that it's the RFC 2616 code. [A] The applicationErrorCode is not only the HTTP status code. It can be the error code of application layer protocols, e. g. the FTP, HTTP, DNS and so on. [P] Do all those applications share a common set of codes? If not, then how do you propose to determine which application the code came from, ie to give the applicationErrorCode context? * Why are fragmentIncomplete, fragmentFirstTooShort, fragmentOffestError and fragmentFlagError unsigned32? Perhaps these should be Boolean. However, what value should they take when fragmentation does not apply to the flows? [A] A fragmentation attack cannot be determined through only one packet fragmentation error, instead it should be observed based upon a historic/integrated view of packets of that session, which is the reason why they are counters of unsigned32. For example, 1000 packets were transmitted in a session, among which 500 packets have fragmentation error, it is likely that a fragment attack happens. If there is no fragmentation, their values should be 0. [P] Please clarify that these are counters, by adding "count" to the names and semantics. * icmpEchoCount and icmpEchoReplyCount semantics may be totalCounter or deltaCounter. [A] In this case, totalCounter is sufficient for session based sampling. [P] Maybe, if there are less than 2^32 per session. However these elements may be used in other ways, for example across multiple sessions. Therefore it may be advisable to choose deltaCounter semantics. P. Cheers, Ana From: Paul Aitken [mailto:paitken@Brocade.com] Sent: Monday, December 29, 2014 6:43 PM To: Hedanping (Ana); ipfix@ietf.org; ipfix-chairs@tools.ietf.org; stbryant@cisco.com; Benoit Claise; Andrew Feren Cc: draft-fu-ipfix-network-security@tools.ietf.org Subject: RE: Comments needed for draft-fu-ipfix-network-security-00 Ana, The main purpose of this draft is to request some new IPFIX Information Elements, which can be done through IANA without necessarily requiring a draft or RFC to be written. Eg, use this form: http://www.iana.org/cgi-bin/assignments.pl A draft is valuable if it's necessary to clarify how the new Information Elements should be used together or with existing Information Elements, or to define templates or timeouts which should be used. Section 3 of this document addressed some of this. However in the current case I think that the elements could be requested from IANA even without this information. Section 3.2, upstream/downstream counters: * How will the proposed counters help to distinguish between an attack and access to a recently published web content? Section 3.6, FlowEndReason: * Since the new flowEndReason value is not mentioned in section 5 (IANA), it may easily be overlooked. Section 5, IANA: * For pktUpstreamCount, pktDownstreamCount, octetUpstreamCount, and octetDownstreamCount, it's necessary to define what "upstream" and "downstream" mean. The semantics for these fields may be totalCounter or deltaCounter. * How can a generic applicationErrorCode be standardized? It would be necessary to pair it with information identifying the exact application which generated the error code. However sections 2 and 3.5 suggests this is actually the RFC 2616 HTTP status code - so please name it more appropriately, and in the description clarify that it's the RFC 2616 code. * Why are fragmentIncomplete, fragmentFirstTooShort, fragmentOffestError and fragmentFlagError unsigned32? Perhaps these should be Boolean. However, what value should they take when fragmentation does not apply to the flows? * icmpEchoCount and icmpEchoReplyCount semantics may be totalCounter or deltaCounter. P. From: Hedanping (Ana) [mailto:ana.hedanping@huawei.com] Sent: 25 December 2014 06:30 To: ipfix@ietf.org; ipfix-chairs@tools.ietf.org; stbryant@cisco.com; Paul Aitken; Benoit Claise; Andrew Feren Cc: draft-fu-ipfix-network-security@tools.ietf.org Subject: Comments needed for draft-fu-ipfix-network-security-00 All, We wrote a draft to extend standard Information Elements for inspecting network security (e.g. the fragment attack in ICMP, TCP and UDP; and DDOS attack). Compared with packet/Byte based sampling, session based sampling is proposed and will be more useful for efficient and effective security inspection. The link of the draft is as follow, where the proposed IEs are described: https://tools.ietf.org/html/draft-fu-ipfix-network-security-00 Your comments are welcome! Merry holidays and happy new year! Danping --_000_23B7BE54EACBED43957AB709C564F7B701857F4115EMEAEXCH01cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ana,= please find some replies inline.

 

Thanks= ,

P.

 

 

From: Hedanping (Ana) [mailto:ana.hedanping@huawei.com]
S= ent: 04 January 2015 03:19
To: Paul Aitken; ipfix@ietf.org; i= pfix-chairs@tools.ietf.org; stbryant@cisco.com; Benoit Claise; Andrew Feren=
Cc: draft-fu-ipfix-network-security@tools.ietf.org
Subject= : RE: Comments needed for draft-fu-ipfix-network-security-00=

 

Hi Paul,

Thank you very much for the comments, please see m= y reply inline.

 <= /span>

The main purpose of this draft is to request = some new IPFIX Information Elements, which can be done through IANA without= necessarily requiring a draft or RFC to be written. Eg, use this form: http://www.iana.org/cgi= -bin/assignments.pl

&nbs= p;

[A] If we only register those= IEs to IANA without requiring a RFC, people won’t understand why tho= se new IEs are needed and how they can be used. As a result, the better way= is to standardize the proposed IEs.

&nbs= p;

[P] Exactly – so the value of = this draft lies not so much in defining the new Information Elements (Secti= on 5), as in explaining how to use them (Section 3). Since there’s al= ready a proposal to close the IPFIX WG, section 3 has to be very strong to = justify this draft since it would have to be AD-sponsored if the WG closes.=

 

 

A draft is v= aluable if it’s necessary to clarify how the new Information Elements= should be used together or with existing Information Elements, or to defin= e templates or timeouts which should be used. Section 3 of this document ad= dressed some of this. However in the current case I think that the elements= could be requested from IANA even without this information.

 

[A] That’s a very good point! The existing IEs are useful in flow = analysis, but still they lack necessary information to distinguish abnormal= cases from the normal operation. The current version of draft is for group= discussion purpose, the new IEs should be used in combination of existing = IEs such as the five-tuple, start time, end time.

Another important point is that we proposed to modi= fy existing sampling method to session based sampling at the forwarding pla= ne.  This sampling mechanism ensures that all the packets of the same = session can be sampled, rather than randomly selecting packets of a flow th= at contains different sessions.

 

[P] Note that it’s = possible for the new Information Elements to be used in other ways which yo= u don’t expect, for example in a flow which *does* contain dif= ferent sessions.

 =

 

Section 3.2, upstream/downstream counters:

 

·        How will the proposed counters help to distinguish bet= ween an attack and access to a recently published web content? <= /span>

[A] The proposed counters can be used to e= fficiently detect DDOS attack. Where the upstream counter is far greater th= an the downstream counter value, a DDOS attack is likely to happen. One exa= mple is the SNMP attack, the normal ratio between up and down should be aro= und 1:1, when an attack happens, the ratio will rise to more than 20:1. Thr= ough such observation, the security issue can be discovered effectively, an= d proper countermeasures will be taken in time

=  

[P] Right, I understand tha= t. How will the counters distinguish the two cases?

 

&nbs= p;

Section 3.6, FlowEndReason:

 

·     &nb= sp;  Since the new flowEndReason value i= s not mentioned in section 5 (IANA), it may easily be overlooked.

[A] Yes. The new values will be added to= section 5 in the next version ^_^

 

Section 5, IANA= :

 

&= middot;    = ;    For pktUpstreamCount, pkt= DownstreamCount, octetUpstreamCount, and octetDownstreamCount, it’s n= ecessary to define what “upstream” and “downstream”= mean. The semantics for these fields may be totalCounter or deltaCounter.<= o:p>

[A] Good point, upstream is fro= m client to server,  downstream is from server to client,

 

[P] How will a Metering Process know which direction the traff= ic is flowing in order to determine upstream or downstream? Especially in t= he situation when it doesn’t observe the first packet(s) in the flow?=

 

 

We propose to use session based sampling, thus totalCounter is suffici= ent to be their semantics.

=  

[P] While that helps wi= th your use case, note that other implementations may use these elements in= different ways, for example without session based sampling.

 

&n= bsp;

·        How can a generic applicationErrorCode be standardized? It would be nec= essary to pair it with information identifying the exact application which = generated the error code. However sections 2 and 3.5 suggests this is actua= lly the RFC 2616 HTTP status code – so please name it more appropriat= ely, and in the description clarify that it’s the RFC 2616 code.=

[A] The applicationErrorCode is not= only the HTTP status code. It can be the error code of application layer p= rotocols, e. g. the FTP, HTTP, DNS and so on. <= /p>

 

[P] = Do all those applications share a common set of codes? If not, then how do = you propose to determine which application the code came from, ie to give t= he applicationErrorCode context?

 

 

· =        Why are = fragmentIncomplete, fragmentFirstTooShort, fragmentOffestError and fragment= FlagError unsigned32? Perhaps these should be Boolean. However, what value = should they take when fragmentation does not apply to the flows?=

[A] A fragmentation attack cannot be dete= rmined through only one packet fragmentation error, instead it should be ob= served based upon a historic/integrated view of packets of that session, wh= ich is the reason why they are counters of unsigned32.

For example, 1000 packets were transmitted in a= session, among which 500 packets have fragmentation error, it is likely th= at a fragment attack happens.

If there is no fragmentation, their values should be 0.

 

[P] Please clarify that these are= counters, by adding “count” to the names and semantics.

&n= bsp;

= <= o:p> 

·        icmpEchoCount and icmpEchoReplyCount semantics may be totalCounter or= deltaCounter.

[A] In this case= , totalCounter is sufficient for session based sampling.<= /i>

 

= [P] Maybe, if there are less than 2^32 per session. However these elements = may be used in other ways, for example across multiple sessions. Therefore = it may be advisable to choose deltaCounter semantics.

=

 

P.=

 

 

Cheers,

Ana

 

From: Paul Aitken [mailto:paitken@Broc= ade.com]
Sent: Monday, December 29, 2014 6:43 PM
To: Hedanping (Ana); ipfix@ietf.org; <= a href=3D"mailto:ipfix-chairs@tools.ietf.org">ipfix-chairs@tools.ietf.org; stbryant@cisco.com; Benoit Cl= aise; Andrew Feren
Cc: draft-fu-ipfix-network-security@tools.ietf.org<= br>Subject: RE: Comments needed for draft-fu-ipfix-network-security-= 00

 =

Ana,

 

The main purpose of= this draft is to request some new IPFIX Information Elements, which can be= done through IANA without necessarily requiring a draft or RFC to be writt= en. Eg, use this form: http://www.iana.org/cgi-bin/assignments.pl

 

A draft is = valuable if it’s necessary to clarify how the new Information Element= s should be used together or with existing Information Elements, or to defi= ne templates or timeouts which should be used. Section 3 of this document a= ddressed some of this. However in the current case I think that the element= s could be requested from IANA even without this information.

 

 

Section 3.2, upstream/down= stream counters:

 =

· &n= bsp;      How will t= he proposed counters help to distinguish between an attack and access to a = recently published web content?

<= span style=3D'font-size:11.0pt;color:#1F497D;mso-fareast-language:ZH-CN'> 

 

<= p class=3DMsoNormal>Section 3.6, FlowEndReason:

 

·        Since the new flowEndReason value is not mentioned in = section 5 (IANA), it may easily be overlooked.

 

 <= /o:p>

Section 5, IANA:

<= p class=3DMsoNormal> 

= ·        For pktUpstreamCount, pktDownstreamCount, octetUp= streamCount, and octetDownstreamCount, it’s necessary to define what = “upstream” and “downstream” mean. The semantics for= these fields may be totalCounter or deltaCounter.

= ·   &nbs= p;    How can a generic applic= ationErrorCode be standardized? It would be necessary to pair it with infor= mation identifying the exact application which generated the error code. Ho= wever sections 2 and 3.5 suggests this is actually the RFC 2616 HTTP status= code – so please name it more appropriately, and in the description = clarify that it’s the RFC 2616 code.

·=      =    Why are fragmentIncomplete, frag= mentFirstTooShort, fragmentOffestError and fragmentFlagError unsigned32? Pe= rhaps these should be Boolean. However, what value should they take when fr= agmentation does not apply to the flows?

·     &n= bsp;  icmpEchoCount and icmpEchoReplyCou= nt semantics may be totalCounter or deltaCounter.

 

 =

P.

 

 

From: Heda= nping (Ana) [mailto:ana.hedanpi= ng@huawei.com]
Sent: 25 December 2014 06:30
To: ipfix@ietf.org; ipfix-chairs@tools.ietf.org; stbryant@cisco.com; Paul Aitken; Benoit Claise; And= rew Feren
Cc: draft-fu-ipfix-network-security@tools.ietf.org
Sub= ject: Comments needed for draft-fu-ipfix-network-security-00=

 =

All,=

We wrote a draft to extend standard Information Elements for = inspecting network security (e.g. the fragment attack in ICMP, TCP and UDP;= and DDOS attack). Compared with packet/Byte based sampling, session based = sampling is proposed and will be more useful for efficient and effective se= curity inspection.

 

The link of the draft i= s as follow, where the proposed IEs are described:

https://too= ls.ietf.org/html/draft-fu-ipfix-network-security-00

&= nbsp;

Your comments are welcome!

 

M= erry holidays and happy new year!

Danping

 = ;

= --_000_23B7BE54EACBED43957AB709C564F7B701857F4115EMEAEXCH01cor_-- From nobody Mon Jan 5 07:19:54 2015 Return-Path: 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 775AA1A009E for ; Mon, 5 Jan 2015 07:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 UcTIu1c2sDMu for ; Mon, 5 Jan 2015 07:19:49 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D181A00A7 for ; Mon, 5 Jan 2015 07:19:49 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 01BEB740; Mon, 5 Jan 2015 16:19:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Mr5UkSKPGGfm; Mon, 5 Jan 2015 16:19:43 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 5 Jan 2015 16:19:46 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6805A2002F; Mon, 5 Jan 2015 16:19:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0PKoJBVvnDoW; Mon, 5 Jan 2015 16:19:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 348E820017; Mon, 5 Jan 2015 16:19:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BF638304FB3A; Mon, 5 Jan 2015 16:19:43 +0100 (CET) Date: Mon, 5 Jan 2015 16:19:41 +0100 From: Juergen Schoenwaelder To: Paul Aitken Message-ID: <20150105151940.GA8035@elstar.local> Mail-Followup-To: Paul Aitken , "ipfix@ietf.org" References: <20141217141829.GA67945@elstar.local> <23B7BE54EACBED43957AB709C564F7B701857F40D7@EMEA-EXCH01.corp.brocade.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23B7BE54EACBED43957AB709C564F7B701857F40D7@EMEA-EXCH01.corp.brocade.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/V1vsdcFNsjh5AagiCOVlCNiI8cA Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 15:19:52 -0000 Paul, I think the example should either be a real-world example or there needs to be a clear warning somewhere that this example is not a real-world example in order to prevent people from coding along the example and then coming up with ideas such as white space padding interface names to make them fixed-length 16 octets long. There are programmers who code along examples instead of reading the underlying specifications and they sometimes end up being (too) creative. I guess my preference is to show a realistic example but if I am the only one, then of course I will go along with what we have (but I would appreciate that there is a warning somewhere that this example makes simplifying assumptions). /js On Mon, Jan 05, 2015 at 11:09:14AM +0100, Paul Aitken wrote: > Juergen, thanks for your careful review and all your feedback. I've addressed all your points except one: > > - p46: Why is the Field Length of mibObjectValueOctetString set to 16? > The interface names in general have variable length. > > Fixed length is used to simplify the example data record in figure 31. > > Although interfaces generally do have variable length names, I believe the example is clearer with fixed length fields. > > Changing to variable length would be straightforward if the consensus is that it's more realistic example. > > P. > > > > -----Original Message----- > > From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > > Sent: 17 December 2014 14:19 > > To: ipfix@ietf.org > > Subject: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 > > > > Hi, > > > > here is my review of draft-ietf-ipfix-mib-variable-export-07. Most of the > > comments are editorial or bug fixes. There is only one real technical concern > > related to the encoding of BITS. The current I-D uses a 64-bit unsigned integer, > > which limits things to 64 bit positions. The SMIv2 does not have this limit - it only > > warns about bit positions in excess of 128. > > > > - RFC4293 is listed as a normative reference but as far as I can tell > > it is only used in an example. I suggest to make this an informative > > reference. > > > > - p3: 2nd paragraph Introduction: I am not sure the statement "there > > are no dependencies between the SMIv2 and the SNMP protocol" is > > correct. Perhaps the simplest fix is to simply delete the whole > > paragraph. > > > > - p4: 1st paragraph Motivation: The 2nd sentence is hard to follow. > > > > - p5: s/does not specify SNMP notifications/does not specify how to > > carry SNMP notifications in IPFIX/ > > > > - p9: s/in a certain MIB/in a certain MIB module/ > > > > - p10: s/may be also be/may also be/ > > > > - p10: s/described by the MIB./described by the MIB module./ > > > > - p14: s/when when/when/ > > > > - p14: s/references sections/referenced sections/ > > > > The fact that every listed item refers to two sections may be a bit > > confusing, perhaps change to > > > > o mibIndexIndicator (defined in Section 5.8.5, example in Section 11.2.2.3) > > > > - p20: It took me a while to spot the difference between Fig. 7 and > > Fig.8 (I did not immediately spot that the fields are > > swapped). Perhaps mention this more explicitly in the last paragraph > > on p19? > > > > Figure 7 shows an IPFIX Options Template Set using Scope Existing > > IFPIX IE and a Non Scope mibObjectValueInteger IE, while Figure 8 > > shows an IPFIX Options Template Set using a Scope > > mibObjectValueInteger IE and a Non Scope Existing IFPIX IE. > > > > - p12: s/name of the MIB/name of the MIB module/ > > > > - p26: s/present the same order/present in the same order/ > > > > - p32: s/not defined as possible/not possible/ > > > > - p37: s/CISCO-PROCESS_MIB/CISCO-PROCESS-MIB/ > > > > - p45: s/ifMTU/ifMtu/ (this shows up several time, do a global replace) > > > > - p46: Why is the Field Length of mibObjectValueOctetString set to 16? > > The interface names in general have variable length. > > > > - p47: why 'ifName = ""'? > > > > - p52: s/index by IEs:/indexed by IEs:/ > > > > - p58: The VLEN and the OID value seem to be wrong. I think this should > > be VLEN=10 and the OID value 06082B060102010E0A01. > > > > - p61: I would have named SNMPtotalCounter simply snmpCounter and I > > would have named SNMPgauge snmpGauge. If this change is > > adopted, then these names needs to be changed in several > > places. > > > > - p64: The encoding of mibObjectValueBits may need to specify how the > > bit positions are counted. That said, there is an issue here > > with using unsigned64. RFC 2578 does not restrict the bit > > positions, it only warns that using bit positions in excess of > > 128 may cause interoperability problems. The IPFIX I-D > > essentially limits this to 64 bits. The obvious solution is to > > follow the SNMP encoding rules that encode bits into an octet > > string (an octetArray in IPFIX speak). > > > > - p67: s/as defined in a MIB// > > > > - p68: OLD > > > > Description: A non-negative sub-identifier. One Sub number from > > an Object Identifier (OID). > > > > NEW > > > > Description: A non-negative sub-identifier of an Object > > Identifier (OID). > > > > - p69: s/was retrieved from SNMP/was retrieved from the MIB/ > > > > - p70: s/could be sampled by SNMP/has been sampled/ > > > > - p70: s/SNMP sampling time/sampling time/ > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jan 6 02:40:10 2015 Return-Path: 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 E82391A9148 for ; Tue, 6 Jan 2015 02:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 1xT2_zwCaoT7 for ; Tue, 6 Jan 2015 02:40:05 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF8A1A912C for ; Tue, 6 Jan 2015 02:40:05 -0800 (PST) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id t06A0jDX005130; Tue, 6 Jan 2015 02:39:55 -0800 Received: from brmwp-exchub02.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 1rqruk3gdr-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 06 Jan 2015 02:39:54 -0800 Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Jan 2015 03:39:42 -0700 Received: from EMEAWP-CASH01.corp.brocade.com (172.29.18.10) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 6 Jan 2015 03:39:41 -0700 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH01.corp.brocade.com ([::1]) with mapi; Tue, 6 Jan 2015 11:39:39 +0100 From: Paul Aitken To: Juergen Schoenwaelder Date: Tue, 6 Jan 2015 11:39:38 +0100 Thread-Topic: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 Thread-Index: AdAo+w6yauHZXIbtTFSrXi64X3RftwAnuPWg Message-ID: <23B7BE54EACBED43957AB709C564F7B70185A1FB01@EMEA-EXCH01.corp.brocade.com> References: <20141217141829.GA67945@elstar.local> <23B7BE54EACBED43957AB709C564F7B701857F40D7@EMEA-EXCH01.corp.brocade.com> <20150105151940.GA8035@elstar.local> In-Reply-To: <20150105151940.GA8035@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-06_04:2015-01-06,2015-01-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501060102 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/rGD5ibiK4E1y8DLVRy8E0i3lT2E Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 10:40:08 -0000 Juergen, I don't usually follow examples since I'm usually wondering what happens if I *don't* do what it says... However I'll change the example for the sake of those who do. Thanks, P. > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: 05 January 2015 15:20 > To: Paul Aitken > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 > > Paul, > > I think the example should either be a real-world example or there needs to be a > clear warning somewhere that this example is not a real-world example in order > to prevent people from coding along the example and then coming up with ideas > such as white space padding interface names to make them fixed-length 16 > octets long. There are programmers who code along examples instead of > reading the underlying specifications and they sometimes end up being (too) > creative. > > I guess my preference is to show a realistic example but if I am the only one, > then of course I will go along with what we have (but I would appreciate that > there is a warning somewhere that this example makes simplifying assumptions). > > /js > > On Mon, Jan 05, 2015 at 11:09:14AM +0100, Paul Aitken wrote: > > Juergen, thanks for your careful review and all your feedback. I've addressed > all your points except one: > > > > - p46: Why is the Field Length of mibObjectValueOctetString set to 16? > > The interface names in general have variable length. > > > > Fixed length is used to simplify the example data record in figure 31. > > > > Although interfaces generally do have variable length names, I believe the > example is clearer with fixed length fields. > > > > Changing to variable length would be straightforward if the consensus is that > it's more realistic example. > > > > P. > > > > > > > -----Original Message----- > > > From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: 17 December 2014 14:19 > > > To: ipfix@ietf.org > > > Subject: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07 > > > > > > Hi, > > > > > > here is my review of draft-ietf-ipfix-mib-variable-export-07. Most > > > of the comments are editorial or bug fixes. There is only one real > > > technical concern related to the encoding of BITS. The current I-D > > > uses a 64-bit unsigned integer, which limits things to 64 bit > > > positions. The SMIv2 does not have this limit - it only warns about bit > positions in excess of 128. > > > > > > - RFC4293 is listed as a normative reference but as far as I can tell > > > it is only used in an example. I suggest to make this an informative > > > reference. > > > > > > - p3: 2nd paragraph Introduction: I am not sure the statement "there > > > are no dependencies between the SMIv2 and the SNMP protocol" is > > > correct. Perhaps the simplest fix is to simply delete the whole > > > paragraph. > > > > > > - p4: 1st paragraph Motivation: The 2nd sentence is hard to follow. > > > > > > - p5: s/does not specify SNMP notifications/does not specify how to > > > carry SNMP notifications in IPFIX/ > > > > > > - p9: s/in a certain MIB/in a certain MIB module/ > > > > > > - p10: s/may be also be/may also be/ > > > > > > - p10: s/described by the MIB./described by the MIB module./ > > > > > > - p14: s/when when/when/ > > > > > > - p14: s/references sections/referenced sections/ > > > > > > The fact that every listed item refers to two sections may be a bit > > > confusing, perhaps change to > > > > > > o mibIndexIndicator (defined in Section 5.8.5, example in Section > > > 11.2.2.3) > > > > > > - p20: It took me a while to spot the difference between Fig. 7 and > > > Fig.8 (I did not immediately spot that the fields are > > > swapped). Perhaps mention this more explicitly in the last paragraph > > > on p19? > > > > > > Figure 7 shows an IPFIX Options Template Set using Scope Existing > > > IFPIX IE and a Non Scope mibObjectValueInteger IE, while Figure 8 > > > shows an IPFIX Options Template Set using a Scope > > > mibObjectValueInteger IE and a Non Scope Existing IFPIX IE. > > > > > > - p12: s/name of the MIB/name of the MIB module/ > > > > > > - p26: s/present the same order/present in the same order/ > > > > > > - p32: s/not defined as possible/not possible/ > > > > > > - p37: s/CISCO-PROCESS_MIB/CISCO-PROCESS-MIB/ > > > > > > - p45: s/ifMTU/ifMtu/ (this shows up several time, do a global > > > replace) > > > > > > - p46: Why is the Field Length of mibObjectValueOctetString set to 16? > > > The interface names in general have variable length. > > > > > > - p47: why 'ifName = ""'? > > > > > > - p52: s/index by IEs:/indexed by IEs:/ > > > > > > - p58: The VLEN and the OID value seem to be wrong. I think this should > > > be VLEN=10 and the OID value 06082B060102010E0A01. > > > > > > - p61: I would have named SNMPtotalCounter simply snmpCounter and I > > > would have named SNMPgauge snmpGauge. If this change is > > > adopted, then these names needs to be changed in several > > > places. > > > > > > - p64: The encoding of mibObjectValueBits may need to specify how the > > > bit positions are counted. That said, there is an issue here > > > with using unsigned64. RFC 2578 does not restrict the bit > > > positions, it only warns that using bit positions in excess of > > > 128 may cause interoperability problems. The IPFIX I-D > > > essentially limits this to 64 bits. The obvious solution is to > > > follow the SNMP encoding rules that encode bits into an octet > > > string (an octetArray in IPFIX speak). > > > > > > - p67: s/as defined in a MIB// > > > > > > - p68: OLD > > > > > > Description: A non-negative sub-identifier. One Sub number from > > > an Object Identifier (OID). > > > > > > NEW > > > > > > Description: A non-negative sub-identifier of an Object > > > Identifier (OID). > > > > > > - p69: s/was retrieved from SNMP/was retrieved from the MIB/ > > > > > > - p70: s/could be sampled by SNMP/has been sampled/ > > > > > > - p70: s/SNMP sampling time/sampling time/ > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > > IPFIX mailing list > > > IPFIX@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipfix > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From thorgrin@gmail.com Tue Jan 6 04:03:37 2015 Return-Path: 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 BDA821AC40E for ; Tue, 6 Jan 2015 04:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 A7NIzIlNxHv8 for ; Tue, 6 Jan 2015 04:03:36 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AD21AC40B for ; Tue, 6 Jan 2015 04:03:31 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id l4so18952788lbv.25 for ; Tue, 06 Jan 2015 04:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=4KECCnhGZ/xaNadJ+utTismGTDopXfKZiZL1ZH57+64=; b=aNRhHOA32fPz3DIKZedjVzTgjwwgg9e9z+ctSsHpO3n3pKcUOywvxniC+ZLzTUiS7X x0suivJxMA+AVtsFci1r2WWiQ1KEWzz4bJHIsuOAKOEgoZu/IMnUgtqiBylhRezUwhMZ GxZ+jQtnXhNxuJw296UaDp2cVsUfKbYMyqIhXmU8wic88LNqgMMeiJ/3fwFVieM3AgSz L0Fzr8cLp9bdxSrHS36Ez0Ae9XbWrt+1JSCKb+EI1AV+Ncu7YYbmhx1ODXdpbSlj6SSh 1i9sz/UJ6N9EEkff91WZR2oHczvWzQ/esTI6M0BQyWXc66WREEq2HPES+X8ZOtw+8Vwx u7kQ== MIME-Version: 1.0 X-Received: by 10.112.89.232 with SMTP id br8mr60211211lbb.69.1420545809934; Tue, 06 Jan 2015 04:03:29 -0800 (PST) Sender: thorgrin@gmail.com Received: by 10.25.13.214 with HTTP; Tue, 6 Jan 2015 04:03:29 -0800 (PST) Date: Tue, 6 Jan 2015 13:03:29 +0100 X-Google-Sender-Auth: F04W6HxRBNBdwul-RiCf5p9svDw Message-ID: From: Petr Velan To: ipfix@ietf.org Content-Type: multipart/alternative; boundary=001a11c36f44637073050bfa98b0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/cyV1HElKuy8jsoMapUs-qi20mD0 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 12:15:02 -0000 --001a11c36f44637073050bfa98b0 Content-Type: text/plain; charset=UTF-8 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 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 --001a11c36f44637073050bfa98b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

I'm not sure whether this is the right place to ask, but we encountere= d 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 me= ssage, we need to do one of the following:
a) Generate a list of t= he 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 Ne= tFlow v9. Moreover, we would still have to somehow handle the cases where t= he element is unknown
b) Request a PEN for NetFlow compatibility a= nd 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
=

--001a11c36f44637073050bfa98b0-- From nobody Tue Jan 6 05:52:59 2015 Return-Path: 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 BBF9A1A6F2A for ; Tue, 6 Jan 2015 05:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 7HQsXavtGQkN for ; Tue, 6 Jan 2015 05:52:54 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54241A6EFC for ; Tue, 6 Jan 2015 05:52:53 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id t06DZkbb003554; Tue, 6 Jan 2015 05:52:47 -0800 Received: from brmwp-exchub01.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 1rrb51rv3x-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 06 Jan 2015 05:52:46 -0800 Received: from EMEAWP-CASH02.corp.brocade.com (172.29.19.10) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Jan 2015 06:52:45 -0700 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH02.corp.brocade.com ([fe80::548c:8759:5d5e:1c0b%12]) with mapi; Tue, 6 Jan 2015 14:52:43 +0100 From: Paul Aitken To: Petr Velan , "ipfix@ietf.org" Date: Tue, 6 Jan 2015 14:52:42 +0100 Thread-Topic: [IPFIX] NetFlow v9 to IPFIX conversion Thread-Index: AdApqmm5o2grLEpfTj2TdBbPqaqljgAAe/iA Message-ID: <23B7BE54EACBED43957AB709C564F7B70185A1FC39@EMEA-EXCH01.corp.brocade.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_23B7BE54EACBED43957AB709C564F7B70185A1FC39EMEAEXCH01cor_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-06_05:2015-01-06,2015-01-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501060136 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/zYdC6Km5Xjefj8Y4jQhquU7lXDg 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 13:52:58 -0000 --_000_23B7BE54EACBED43957AB709C564F7B70185A1FC39EMEAEXCH01cor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGV0ciwgcGxlYXNlIHNlZSByZXBsaWVzIGlubGluZToNCg0KDQpGcm9tOiBJUEZJWCBbbWFpbHRv OmlwZml4LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQZXRyIFZlbGFuDQpTZW50OiAw NiBKYW51YXJ5IDIwMTUgMTI6MDMNClRvOiBpcGZpeEBpZXRmLm9yZw0KU3ViamVjdDogW0lQRklY XSBOZXRGbG93IHY5IHRvIElQRklYIGNvbnZlcnNpb24NCg0KSGVsbG8gYWxsLA0KSSdtIG5vdCBz dXJlIHdoZXRoZXIgdGhpcyBpcyB0aGUgcmlnaHQgcGxhY2UgdG8gYXNrLCBidXQgd2UgZW5jb3Vu dGVyZWQgZm9sbG93aW5nIHByb2JsZW0gd2hlbiBjb252ZXJ0aW5nIE5ldEZsb3cgdjkgbWVzc2Fn ZXMgdG8gSVBGSVguDQpTb21lIHZlbmRvcnMgKEkndmUgaGVhcmQgb2YgbnRvcCkgYXJlIHVzaW5n IGVsZW1lbnRzIElEcyBsYXJnZSB0aGFuIDMyNzY3IGluIE5ldEZsb3cgdjkuDQoNCltQXSBUaGF0 4oCZcyBub3QgaW52YWxpZCBpbiBORnY5LiBSRkMgMzk1NCBhbGxvd3MgYSAxNi1iaXQg4oCcRmll bGQgVHlwZeKAnSBJRC4NCg0KDQpXaGVuIGNvbnZlcnRpbmcgbWVzc2FnZXMgd2l0aCB0aGVzZSBl bGVtZW50cyB0byBJUEZJWCwgdGhleSBhcmUgY29uc2lkZXJlZCB0byBiZSBFbnRlcnByaXNlIE51 bWJlcnMuIFRvIGdlbmVyYXRlIHByb3BlciBJUEZJWCBtZXNzYWdlLCB3ZSBuZWVkIHRvIGRvIG9u ZSBvZiB0aGUgZm9sbG93aW5nOg0KYSkgR2VuZXJhdGUgYSBsaXN0IG9mIHRoZSBlbGVtZW50cyBh bmQgbWFwIHRoZW0gdG8gUEVOIG9mIHRoZSBjb3JyZWN0IHZlbmRvci4gSG93ZXZlciwgdGhpcyB3 b3VsZCByZXN1bHQgaW4gYW4gYXR0ZW1wdCB0byBjb3ZlciBhbGwgcG9zc2libGUgZWxlbWVudHMg dGhhdCBhbnlib2R5IHVzZWQgaW4gTmV0RmxvdyB2OS4gTW9yZW92ZXIsIHdlIHdvdWxkIHN0aWxs IGhhdmUgdG8gc29tZWhvdyBoYW5kbGUgdGhlIGNhc2VzIHdoZXJlIHRoZSBlbGVtZW50IGlzIHVu a25vd24NCg0KW1BdIFdoZW4gSSB3YXMgbmV0Zmxvd+KAk3BvbGljZSBhdCBjaXNjbywgdGhlIGd1 eXMgYXQgUGxpeGVyIGhlbHBlZCB0byBpZGVudGlmeSBub24tY2lzY28gTkZ2OSBleHBvcnRlcnMs IGFuZCBJIGFsbG9jYXRlZCBibG9ja3Mgb2YgNTAwIG9yIDEwMDAgSURzIGZvciBlYWNoIHRoZW0g aW4gdGhlIDUwLDAwMCDigJMgNjAsMDAwIHJhbmdlIOKAkyBlZmZlY3RpdmVseSBibGFja2xpc3Rp bmcgdGhvc2UgSURzIHNvIHRoYXQgY2lzY28gd291bGRu4oCZdCBjcmVhdGUgZHVwbGljYXRlIElE cy4gIEF0IHRoYXQgdGltZSB0aGVyZSB3ZXJlIGp1c3QgNSBzdWNoIGJsb2NrcyByZWNvZ25pemVk IGJ5IENpc2NvLiBJZiB3ZSBjYW4gaWRlbnRpZnkgYSBQRU4gZm9yIGVhY2ggYmxvY2sgdGhlbiBp dOKAmWQgYmUgc2ltcGxlIHRvIHdyaXRlIGEgZGVjb2Rlci4gVW5mb3J0dW5hdGVseSB0aGlzIG1l dGhvZCBkb2VzbuKAmXQgZXh0ZW5kIHRvIHJlY29nbml6aW5nIGZ1dHVyZSBhbGxvY2F0aW9ucywg b3IgZXhwb3J0IElEcyB0aGF0IHdlcmVu4oCZdCBrbm93biB0byB1cyBhdCB0aGUgdGltZS4NCg0K QlRXLCB5b3XigJlyZSBhbHNvIHN1cHBvc2luZyB0aGF0IHRoZSBJRHMgPCAzMjc2OCBhcmUgaWRl bnRpY2FsIGFuZCB3aWxsIHJlbWFpbiBzbyBpbiBmdXR1cmUuDQoNCg0KYikgUmVxdWVzdCBhIFBF TiBmb3IgTmV0RmxvdyBjb21wYXRpYmlsaXR5IGFuZCBqdXN0IGFkZCB0aGlzIFBFTiBmb3IgZXZl cnkgZWxlbWVudCB0aGF0IGhhcyBJRCBsYXJnZXIgdGhhbiAzMjc2Ny4NCltQXSBJdOKAmWQgYmUg bW9yZSBhY2N1cmF0ZSB0byB1c2UgQ2lzY2/igJlzIFBFTiBmb3IgdGhpcyA7LSkgIEhvd2V2ZXIg aW4gcHJpbmNpcGFsIGl04oCZcyBhIE5GdjktaW4tSVBGSVggaW5kaWNhdG9yLg0KDQpQZXJzb25h bGx5LCBJIGJlbGlldmUgdGhhdCB0aGUgYikgaXMgbW9yZSBnZW5lcmFsIGFuZCBlcnJvci1wcm9u ZS4gRG8geW91IHRoaW5rLCB0aGF0IGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGRlZGljYXRlIHdo b2xlIFBFTiB0byB0aGlzIGNhdXNlPw0KW1BdIEkgYmVsaWV2ZSB5b3UgY291bGQgY29udmluY2Ug SUFOQSB0byBhbGxvY2F0ZSBhbiBJRC4gSG93ZXZlciBJ4oCZbSBub3QgeWV0IGNvbnZpbmNlZCB0 aGF0IGl04oCZcyBhIGdvb2QgaWRlYS4NClAuDQoNCg0KVGhhbmsgeW91IGZvciBhbnkgb3Bpbmlv bnMsDQoNClBldHIgVmVsYW4NCg0K --_000_23B7BE54EACBED43957AB709C564F7B70185A1FC39EMEAEXCH01cor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFy Z2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCglt YXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5r PWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlBldHIsIHBsZWFzZSBzZWUgcmVwbGllcyBpbmxp bmU6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1N c29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gSVBGSVggW21haWx0 bzppcGZpeC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlBldHIgVmVsYW48 YnI+PGI+U2VudDo8L2I+IDA2IEphbnVhcnkgMjAxNSAxMjowMzxicj48Yj5Ubzo8L2I+IGlwZml4 QGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBbSVBGSVhdIE5ldEZsb3cgdjkgdG8gSVBGSVgg Y29udmVyc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48ZGl2PjxkaXY+PGRpdj48ZGl2PjxkaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQn PkhlbGxvIGFsbCw8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1ib3R0b206MTIuMHB0Jz5JJ20gbm90IHN1cmUgd2hldGhlciB0aGlzIGlzIHRoZSBy aWdodCBwbGFjZSB0byBhc2ssIGJ1dCB3ZSBlbmNvdW50ZXJlZCBmb2xsb3dpbmcgcHJvYmxlbSB3 aGVuIGNvbnZlcnRpbmcgTmV0RmxvdyB2OSBtZXNzYWdlcyB0byBJUEZJWC48bzpwPjwvbzpwPjwv cD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U29tZSB2ZW5kb3JzIChJJ3ZlIGhlYXJkIG9mIG50 b3ApIGFyZSB1c2luZyBlbGVtZW50cyBJRHMgbGFyZ2UgdGhhbiAzMjc2NyBpbiBOZXRGbG93IHY5 LjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPltQXSBUaGF0 4oCZcyBub3QgaW52YWxpZCBpbiBORnY5LiBSRkMgMzk1NCBhbGxvd3MgYSAxNi1iaXQg4oCcRmll bGQgVHlwZeKAnSBJRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+V2hlbiBjb252ZXJ0aW5nIG1lc3NhZ2VzIHdpdGggdGhl c2UgZWxlbWVudHMgdG8gSVBGSVgsIHRoZXkgYXJlIGNvbnNpZGVyZWQgdG8gYmUgRW50ZXJwcmlz ZSBOdW1iZXJzLiBUbyBnZW5lcmF0ZSBwcm9wZXIgSVBGSVggbWVzc2FnZSwgd2UgbmVlZCB0byBk byBvbmUgb2YgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+YSkgR2VuZXJhdGUgYSBsaXN0IG9mIHRoZSBlbGVtZW50cyBhbmQgbWFwIHRoZW0gdG8g UEVOIG9mIHRoZSBjb3JyZWN0IHZlbmRvci4gSG93ZXZlciwgdGhpcyB3b3VsZCByZXN1bHQgaW4g YW4gYXR0ZW1wdCB0byBjb3ZlciBhbGwgcG9zc2libGUgZWxlbWVudHMgdGhhdCBhbnlib2R5IHVz ZWQgaW4gTmV0RmxvdyB2OS4gTW9yZW92ZXIsIHdlIHdvdWxkIHN0aWxsIGhhdmUgdG8gc29tZWhv dyBoYW5kbGUgdGhlIGNhc2VzIHdoZXJlIHRoZSBlbGVtZW50IGlzIHVua25vd248bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5bUF0gV2hlbiBJIHdhcyBuZXRmbG934oCTcG9saWNlIGF0IGNpc2NvLCB0aGUgZ3V5 cyBhdCBQbGl4ZXIgaGVscGVkIHRvIGlkZW50aWZ5IG5vbi1jaXNjbyBORnY5IGV4cG9ydGVycywg YW5kIEkgYWxsb2NhdGVkIGJsb2NrcyBvZiA1MDAgb3IgMTAwMCBJRHMgZm9yIGVhY2ggdGhlbSBp biB0aGUgNTAsMDAwIOKAkyA2MCwwMDAgcmFuZ2Ug4oCTIGVmZmVjdGl2ZWx5IGJsYWNrbGlzdGlu ZyB0aG9zZSBJRHMgc28gdGhhdCBjaXNjbyB3b3VsZG7igJl0IGNyZWF0ZSBkdXBsaWNhdGUgSURz LiDCoEF0IHRoYXQgdGltZSB0aGVyZSB3ZXJlIGp1c3QgNSBzdWNoIGJsb2NrcyByZWNvZ25pemVk IGJ5IENpc2NvLiBJZiB3ZSBjYW4gaWRlbnRpZnkgYSBQRU4gZm9yIGVhY2ggYmxvY2sgdGhlbiBp dOKAmWQgYmUgc2ltcGxlIHRvIHdyaXRlIGEgZGVjb2Rlci4gVW5mb3J0dW5hdGVseSB0aGlzIG1l dGhvZCBkb2VzbuKAmXQgZXh0ZW5kIHRvIHJlY29nbml6aW5nIGZ1dHVyZSBhbGxvY2F0aW9ucywg b3IgZXhwb3J0IElEcyB0aGF0IHdlcmVu4oCZdCBrbm93biB0byB1cyBhdCB0aGUgdGltZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPkJUVywgeW914oCZcmUgYWxzbyBzdXBwb3NpbmcgdGhhdCB0aGUgSURz ICZsdDsgMzI3NjggYXJlIGlkZW50aWNhbCBhbmQgd2lsbCByZW1haW4gc28gaW4gZnV0dXJlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPmIpIFJlcXVlc3QgYSBQ RU4gZm9yIE5ldEZsb3cgY29tcGF0aWJpbGl0eSBhbmQganVzdCBhZGQgdGhpcyBQRU4gZm9yIGV2 ZXJ5IGVsZW1lbnQgdGhhdCBoYXMgSUQgbGFyZ2VyIHRoYW4gMzI3NjcuPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5bUF0gSXTigJlkIGJlIG1vcmUgYWNjdXJhdGUgdG8gdXNlIENpc2Nv4oCZ cyBQRU4gZm9yIHRoaXMgOy0pwqAgSG93ZXZlciBpbiBwcmluY2lwYWwgaXTigJlzIGEgTkZ2OS1p bi1JUEZJWCBpbmRpY2F0b3IuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWJvdHRvbToxMi4wcHQnPlBlcnNvbmFsbHksIEkgYmVsaWV2ZSB0aGF0IHRoZSBiKSBp cyBtb3JlIGdlbmVyYWwgYW5kIGVycm9yLXByb25lLiBEbyB5b3UgdGhpbmssIHRoYXQgaXQgd291 bGQgYmUgcG9zc2libGUgdG8gZGVkaWNhdGUgd2hvbGUgUEVOIHRvIHRoaXMgY2F1c2U/PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bUF0gSSBiZWxpZXZlIHlvdSBjb3VsZCBjb252aW5jZSBJ QU5BIHRvIGFsbG9jYXRlIGFuIElELiBIb3dldmVyIEnigJltIG5vdCB5ZXQgY29udmluY2VkIHRo YXQgaXTigJlzIGEgZ29vZCBpZGVhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5UaGFuayB5b3Ug Zm9yIGFueSBvcGluaW9ucyw8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PGJyPlBldHIgVmVsYW48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9k eT48L2h0bWw+ --_000_23B7BE54EACBED43957AB709C564F7B70185A1FC39EMEAEXCH01cor_-- From nobody Tue Jan 6 06:26:50 2015 Return-Path: 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 BB4E81A700A for ; Tue, 6 Jan 2015 06:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 SAbft-SPDG5c for ; Tue, 6 Jan 2015 06:26:46 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id C419E1A6F3F for ; Tue, 6 Jan 2015 06:26:45 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::ce] (unknown [IPv6:2001:67c:10ec:2a49:8000::ce]) by trammell.ch (Postfix) with ESMTPSA id 567291A0183; Tue, 6 Jan 2015 15:26:14 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Brian Trammell In-Reply-To: <23B7BE54EACBED43957AB709C564F7B70185A1FC39@EMEA-EXCH01.corp.brocade.com> Date: Tue, 6 Jan 2015 15:26:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23B7BE54EACBED43957AB709C564F7B70185A1FC39@EMEA-EXCH01.corp.brocade.com> To: Paul Aitken X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/t6wvNVq0wSNtIwAVAsyTl76EBF8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 14:26:48 -0000 hi Paul, Petr, So unless I misunderstand here, what we're talking about is third party = vendors who have more or less NF9-compatible exporters that are = squatting on chunks of the NF9 IE number space (i.e., there are no = Cisco-defined IEs for NetFlow 9 which are > 2^15). So the first question is why aren't they using IPFIX in the first place? = But alas... It doesn't seem right to me to use Cisco's PEN for this, since even = though Cisco has reserved the squatted blocks they know about to prevent = interoperability problems, there is no guarantee they know about all the = blocks that exist, and it's kind of unfair to ask one company to burn = PEN space to correct the mistakes of others.=20 I'd be in favor of asking IANA for a new PEN for this, since it really = is a protocol-level incompatibility between NetFlow 9 and IPFIX, and it = would be a relatively quick AD-sponsored or opsawg draft to do. (I do = think it needs an RFC, so that the PEN registry can point at something = to say "what is this?"; see e.g. PEN 29305 for RFC 5103).=20 Yes, this has the problem that squatting blocks might collide with each = other. I'm perfectly okay with that. As a matter of policy, we should = not sanction the de facto creation of codepoints in public or semipublic = registries through squatting, and while building a registry of squatted = blocks to appropriate PENs is a more *elegant* solution, it seems like = way too much effort for the community to expend to come up with a nice = fix to a messy problem caused by the lazy.=20 Cheers, Brian > On 06 Jan 2015, at 14:52, Paul Aitken wrote: >=20 > Petr, please see replies inline: > =20 > =20 > From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of Petr Velan > Sent: 06 January 2015 12:03 > To: ipfix@ietf.org > Subject: [IPFIX] NetFlow v9 to IPFIX conversion > =20 > Hello all, >=20 > I'm not sure whether this is the right place to ask, but we = encountered following problem when converting NetFlow v9 messages to = IPFIX. >=20 > Some vendors (I've heard of ntop) are using elements IDs large than = 32767 in NetFlow v9. > =20 > [P] That=E2=80=99s not invalid in NFv9. RFC 3954 allows a 16-bit = =E2=80=9CField Type=E2=80=9D ID. > =20 > =20 > 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 > =20 > [P] When I was netflow=E2=80=93police at cisco, the guys at Plixer = helped to identify non-cisco NFv9 exporters, and I allocated blocks of = 500 or 1000 IDs for each them in the 50,000 =E2=80=93 60,000 range =E2=80=93= effectively blacklisting those IDs so that cisco wouldn=E2=80=99t = create duplicate IDs. At that time there were just 5 such blocks = recognized by Cisco. If we can identify a PEN for each block then it=E2=80= =99d be simple to write a decoder. Unfortunately this method doesn=E2=80=99= t extend to recognizing future allocations, or export IDs that weren=E2=80= =99t known to us at the time. > =20 > BTW, you=E2=80=99re also supposing that the IDs < 32768 are identical = and will remain so in future. > =20 > =20 > b) Request a PEN for NetFlow compatibility and just add this PEN for = every element that has ID larger than 32767. >=20 > [P] It=E2=80=99d be more accurate to use Cisco=E2=80=99s PEN for this = ;-) However in principal it=E2=80=99s a NFv9-in-IPFIX indicator. >=20 > =20 >=20 > 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? >=20 > [P] I believe you could convince IANA to allocate an ID. However I=E2=80= =99m not yet convinced that it=E2=80=99s a good idea. >=20 > P. > =20 > =20 > Thank you for any opinions, >=20 > Petr Velan > =20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From nobody Tue Jan 6 07:32:18 2015 Return-Path: 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 7EA1E1A8835 for ; Tue, 6 Jan 2015 07:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 54Hys9b7FSC8 for ; Tue, 6 Jan 2015 07:32:10 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C591A8888 for ; Tue, 6 Jan 2015 07:31:38 -0800 (PST) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id t06F0O7C016070; Tue, 6 Jan 2015 07:31:32 -0800 Received: from brmwp-exchub01.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 1rqruk4b1b-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 06 Jan 2015 07:31:32 -0800 Received: from EMEAWP-CASH02.corp.brocade.com (172.29.19.10) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Jan 2015 08:31:31 -0700 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH02.corp.brocade.com ([fe80::548c:8759:5d5e:1c0b%12]) with mapi; Tue, 6 Jan 2015 16:31:29 +0100 From: Paul Aitken To: Brian Trammell Date: Tue, 6 Jan 2015 16:31:28 +0100 Thread-Topic: [IPFIX] NetFlow v9 to IPFIX conversion Thread-Index: AdApvL0dTq7Cy6gvTj+bJm200CjLjQAAWXkA Message-ID: <23B7BE54EACBED43957AB709C564F7B70185A1FCCD@EMEA-EXCH01.corp.brocade.com> References: <23B7BE54EACBED43957AB709C564F7B70185A1FC39@EMEA-EXCH01.corp.brocade.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-06_05:2015-01-06,2015-01-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501060152 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/-b-gEisjBba4hPnuJGwnV_nLyuA 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:32:13 -0000 QnJpYW4sDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBU cmFtbWVsbCBbbWFpbHRvOmlldGZAdHJhbW1lbGwuY2hdDQo+IFNlbnQ6IDA2IEphbnVhcnkgMjAx NSAxNDoyNg0KPiBUbzogUGF1bCBBaXRrZW4NCj4gQ2M6IFBldHIgVmVsYW47IGlwZml4QGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbSVBGSVhdIE5ldEZsb3cgdjkgdG8gSVBGSVggY29udmVyc2lv bg0KPiANCj4gaGkgUGF1bCwgUGV0ciwNCj4gDQo+IFNvIHVubGVzcyBJIG1pc3VuZGVyc3RhbmQg aGVyZSwgd2hhdCB3ZSdyZSB0YWxraW5nIGFib3V0IGlzIHRoaXJkIHBhcnR5IHZlbmRvcnMNCj4g d2hvIGhhdmUgbW9yZSBvciBsZXNzIE5GOS1jb21wYXRpYmxlIGV4cG9ydGVycyB0aGF0IGFyZSBz cXVhdHRpbmcgb24gY2h1bmtzDQo+IG9mIHRoZSBORjkgSUUgbnVtYmVyIHNwYWNlDQoNCkNvcnJl Y3QgLSB0aG91Z2ggInNxdWF0dGluZyIgbWlnaHQgbm90IGJlIHF1aXRlIHRoZSByaWdodCB3b3Jk LiBUaGVzZSBJRHMgd2VyZSBhbGxvY2F0ZWQgd2l0aCBjaXNjbydzIGtub3dsZWRnZSBpbiBvcmRl ciB0byBwcmV2ZW50IE5GdjkgSUQgY2xhc2hlcy4NCg0KDQo+IChpLmUuLCB0aGVyZSBhcmUgbm8g Q2lzY28tZGVmaW5lZCBJRXMgZm9yIE5ldEZsb3cgOSB3aGljaCBhcmUgPiAyXjE1KS4NCg0KSSBi ZWxpZXZlIHRoZXJlIGFyZSBtYW55IENpc2NvIElFcyA+IDMyNzY4Lg0KDQoNCj4gU28gdGhlIGZp cnN0IHF1ZXN0aW9uIGlzIHdoeSBhcmVuJ3QgdGhleSB1c2luZyBJUEZJWCBpbiB0aGUgZmlyc3Qg cGxhY2U/IEJ1dCBhbGFzLi4uDQoNCkRvdWJ0bGVzcyBpdCB3YXMgZWFzaWVyIHRvIHVzZSBzb21l IE5GdjkgSURzIHRoYW4gdG8gdXBncmFkZSBleHBvcnRlcnMgYW5kIGNvbGxlY3RvcnMgdG8gSVBG SVguDQoNCg0KPiBJdCBkb2Vzbid0IHNlZW0gcmlnaHQgdG8gbWUgdG8gdXNlIENpc2NvJ3MgUEVO IGZvciB0aGlzLCBzaW5jZSBldmVuIHRob3VnaCBDaXNjbw0KPiBoYXMgcmVzZXJ2ZWQgdGhlIHNx dWF0dGVkIGJsb2NrcyB0aGV5IGtub3cgYWJvdXQgdG8gcHJldmVudCBpbnRlcm9wZXJhYmlsaXR5 DQo+IHByb2JsZW1zLCB0aGVyZSBpcyBubyBndWFyYW50ZWUgdGhleSBrbm93IGFib3V0IGFsbCB0 aGUgYmxvY2tzIHRoYXQgZXhpc3QsIGFuZA0KPiBpdCdzIGtpbmQgb2YgdW5mYWlyIHRvIGFzayBv bmUgY29tcGFueSB0byBidXJuIFBFTiBzcGFjZSB0byBjb3JyZWN0IHRoZSBtaXN0YWtlcw0KPiBv ZiBvdGhlcnMuDQoNCisxDQoNCg0KPiBJJ2QgYmUgaW4gZmF2b3Igb2YgYXNraW5nIElBTkEgZm9y IGEgbmV3IFBFTiBmb3IgdGhpcywgc2luY2UgaXQgcmVhbGx5IGlzIGEgcHJvdG9jb2wtDQo+IGxl dmVsIGluY29tcGF0aWJpbGl0eSBiZXR3ZWVuIE5ldEZsb3cgOSBhbmQgSVBGSVgsIGFuZCBpdCB3 b3VsZCBiZSBhIHJlbGF0aXZlbHkNCj4gcXVpY2sgQUQtc3BvbnNvcmVkIG9yIG9wc2F3ZyBkcmFm dCB0byBkby4gKEkgZG8gdGhpbmsgaXQgbmVlZHMgYW4gUkZDLCBzbyB0aGF0DQo+IHRoZSBQRU4g cmVnaXN0cnkgY2FuIHBvaW50IGF0IHNvbWV0aGluZyB0byBzYXkgIndoYXQgaXMgdGhpcz8iOyBz ZWUgZS5nLiBQRU4NCj4gMjkzMDUgZm9yIFJGQyA1MTAzKS4NCj4gDQo+IFllcywgdGhpcyBoYXMg dGhlIHByb2JsZW0gdGhhdCBzcXVhdHRpbmcgYmxvY2tzIG1pZ2h0IGNvbGxpZGUgd2l0aCBlYWNo IG90aGVyLiBJJ20NCj4gcGVyZmVjdGx5IG9rYXkgd2l0aCB0aGF0LiBBcyBhIG1hdHRlciBvZiBw b2xpY3ksIHdlIHNob3VsZCBub3Qgc2FuY3Rpb24gdGhlIGRlDQo+IGZhY3RvIGNyZWF0aW9uIG9m IGNvZGVwb2ludHMgaW4gcHVibGljIG9yIHNlbWlwdWJsaWMgcmVnaXN0cmllcyB0aHJvdWdoIHNx dWF0dGluZywNCj4gYW5kIHdoaWxlIGJ1aWxkaW5nIGEgcmVnaXN0cnkgb2Ygc3F1YXR0ZWQgYmxv Y2tzIHRvIGFwcHJvcHJpYXRlIFBFTnMgaXMgYSBtb3JlDQo+ICplbGVnYW50KiBzb2x1dGlvbiwg aXQgc2VlbXMgbGlrZSB3YXkgdG9vIG11Y2ggZWZmb3J0IGZvciB0aGUgY29tbXVuaXR5IHRvDQo+ IGV4cGVuZCB0byBjb21lIHVwIHdpdGggYSBuaWNlIGZpeCB0byBhIG1lc3N5IHByb2JsZW0gY2F1 c2VkIGJ5IHRoZSBsYXp5Lg0KDQpBcyBmYXIgYXMgSSBrbm93LCB0aGF0IHJlZ2lzdHJ5IGN1cnJl bnRseSBoYXMganVzdCA1IG5vbi1jaXNjbyBlbnRyaWVzLCBzbyBpdCB3b3VsZG4ndCBiZSBoYXJk IHRvIGNvZGUuDQoNCkhvd2V2ZXIgYXMgeW91IHNheSB0aGVyZSBjb3VsZCBiZSBvdGhlciBJRCBj b25mbGljdHMgd2hpY2ggYXJlbid0IGtub3duIGFib3V0IHRvZGF5LCBhbmQgYSBuZXcgUEVOIHdv dWxkIHJlbW92ZSB0aGUgZ3Vlc3N3b3JrLg0KDQpQLg0KDQoNCj4gPiBPbiAwNiBKYW4gMjAxNSwg YXQgMTQ6NTIsIFBhdWwgQWl0a2VuIDxwYWl0a2VuQEJyb2NhZGUuY29tPiB3cm90ZToNCj4gPg0K PiA+IFBldHIsIHBsZWFzZSBzZWUgcmVwbGllcyBpbmxpbmU6DQo+ID4NCj4gPg0KPiA+IEZyb206 IElQRklYIFttYWlsdG86aXBmaXgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBldHIg VmVsYW4NCj4gPiBTZW50OiAwNiBKYW51YXJ5IDIwMTUgMTI6MDMNCj4gPiBUbzogaXBmaXhAaWV0 Zi5vcmcNCj4gPiBTdWJqZWN0OiBbSVBGSVhdIE5ldEZsb3cgdjkgdG8gSVBGSVggY29udmVyc2lv bg0KPiA+DQo+ID4gSGVsbG8gYWxsLA0KPiA+DQo+ID4gSSdtIG5vdCBzdXJlIHdoZXRoZXIgdGhp cyBpcyB0aGUgcmlnaHQgcGxhY2UgdG8gYXNrLCBidXQgd2UgZW5jb3VudGVyZWQNCj4gZm9sbG93 aW5nIHByb2JsZW0gd2hlbiBjb252ZXJ0aW5nIE5ldEZsb3cgdjkgbWVzc2FnZXMgdG8gSVBGSVgu DQo+ID4NCj4gPiBTb21lIHZlbmRvcnMgKEkndmUgaGVhcmQgb2YgbnRvcCkgYXJlIHVzaW5nIGVs ZW1lbnRzIElEcyBsYXJnZSB0aGFuIDMyNzY3IGluDQo+IE5ldEZsb3cgdjkuDQo+ID4NCj4gPiBb UF0gVGhhdOKAmXMgbm90IGludmFsaWQgaW4gTkZ2OS4gUkZDIDM5NTQgYWxsb3dzIGEgMTYtYml0 IOKAnEZpZWxkIFR5cGXigJ0gSUQuDQo+ID4NCj4gPg0KPiA+IFdoZW4gY29udmVydGluZyBtZXNz YWdlcyB3aXRoIHRoZXNlIGVsZW1lbnRzIHRvIElQRklYLCB0aGV5IGFyZSBjb25zaWRlcmVkDQo+ IHRvIGJlIEVudGVycHJpc2UgTnVtYmVycy4gVG8gZ2VuZXJhdGUgcHJvcGVyIElQRklYIG1lc3Nh Z2UsIHdlIG5lZWQgdG8gZG8NCj4gb25lIG9mIHRoZSBmb2xsb3dpbmc6DQo+ID4gYSkgR2VuZXJh dGUgYSBsaXN0IG9mIHRoZSBlbGVtZW50cyBhbmQgbWFwIHRoZW0gdG8gUEVOIG9mIHRoZSBjb3Jy ZWN0IHZlbmRvci4NCj4gSG93ZXZlciwgdGhpcyB3b3VsZCByZXN1bHQgaW4gYW4gYXR0ZW1wdCB0 byBjb3ZlciBhbGwgcG9zc2libGUgZWxlbWVudHMgdGhhdA0KPiBhbnlib2R5IHVzZWQgaW4gTmV0 RmxvdyB2OS4gTW9yZW92ZXIsIHdlIHdvdWxkIHN0aWxsIGhhdmUgdG8gc29tZWhvdyBoYW5kbGUN Cj4gdGhlIGNhc2VzIHdoZXJlIHRoZSBlbGVtZW50IGlzIHVua25vd24NCj4gPg0KPiA+IFtQXSBX aGVuIEkgd2FzIG5ldGZsb3figJNwb2xpY2UgYXQgY2lzY28sIHRoZSBndXlzIGF0IFBsaXhlciBo ZWxwZWQgdG8gaWRlbnRpZnkNCj4gbm9uLWNpc2NvIE5GdjkgZXhwb3J0ZXJzLCBhbmQgSSBhbGxv Y2F0ZWQgYmxvY2tzIG9mIDUwMCBvciAxMDAwIElEcyBmb3IgZWFjaA0KPiB0aGVtIGluIHRoZSA1 MCwwMDAg4oCTIDYwLDAwMCByYW5nZSDigJMgZWZmZWN0aXZlbHkgYmxhY2tsaXN0aW5nIHRob3Nl IElEcyBzbyB0aGF0DQo+IGNpc2NvIHdvdWxkbuKAmXQgY3JlYXRlIGR1cGxpY2F0ZSBJRHMuICBB dCB0aGF0IHRpbWUgdGhlcmUgd2VyZSBqdXN0IDUgc3VjaCBibG9ja3MNCj4gcmVjb2duaXplZCBi eSBDaXNjby4gSWYgd2UgY2FuIGlkZW50aWZ5IGEgUEVOIGZvciBlYWNoIGJsb2NrIHRoZW4gaXTi gJlkIGJlIHNpbXBsZQ0KPiB0byB3cml0ZSBhIGRlY29kZXIuIFVuZm9ydHVuYXRlbHkgdGhpcyBt ZXRob2QgZG9lc27igJl0IGV4dGVuZCB0byByZWNvZ25pemluZw0KPiBmdXR1cmUgYWxsb2NhdGlv bnMsIG9yIGV4cG9ydCBJRHMgdGhhdCB3ZXJlbuKAmXQga25vd24gdG8gdXMgYXQgdGhlIHRpbWUu DQo+ID4NCj4gPiBCVFcsIHlvdeKAmXJlIGFsc28gc3VwcG9zaW5nIHRoYXQgdGhlIElEcyA8IDMy NzY4IGFyZSBpZGVudGljYWwgYW5kIHdpbGwgcmVtYWluDQo+IHNvIGluIGZ1dHVyZS4NCj4gPg0K PiA+DQo+ID4gYikgUmVxdWVzdCBhIFBFTiBmb3IgTmV0RmxvdyBjb21wYXRpYmlsaXR5IGFuZCBq dXN0IGFkZCB0aGlzIFBFTiBmb3IgZXZlcnkNCj4gZWxlbWVudCB0aGF0IGhhcyBJRCBsYXJnZXIg dGhhbiAzMjc2Ny4NCj4gPg0KPiA+IFtQXSBJdOKAmWQgYmUgbW9yZSBhY2N1cmF0ZSB0byB1c2Ug Q2lzY2/igJlzIFBFTiBmb3IgdGhpcyA7LSkgIEhvd2V2ZXIgaW4gcHJpbmNpcGFsDQo+IGl04oCZ cyBhIE5GdjktaW4tSVBGSVggaW5kaWNhdG9yLg0KPiA+DQo+ID4NCj4gPg0KPiA+IFBlcnNvbmFs bHksIEkgYmVsaWV2ZSB0aGF0IHRoZSBiKSBpcyBtb3JlIGdlbmVyYWwgYW5kIGVycm9yLXByb25l LiBEbyB5b3UgdGhpbmssDQo+IHRoYXQgaXQgd291bGQgYmUgcG9zc2libGUgdG8gZGVkaWNhdGUg d2hvbGUgUEVOIHRvIHRoaXMgY2F1c2U/DQo+ID4NCj4gPiBbUF0gSSBiZWxpZXZlIHlvdSBjb3Vs ZCBjb252aW5jZSBJQU5BIHRvIGFsbG9jYXRlIGFuIElELiBIb3dldmVyIEnigJltIG5vdCB5ZXQN Cj4gY29udmluY2VkIHRoYXQgaXTigJlzIGEgZ29vZCBpZGVhLg0KPiA+DQo+ID4gUC4NCj4gPg0K PiA+DQo+ID4gVGhhbmsgeW91IGZvciBhbnkgb3BpbmlvbnMsDQo+ID4NCj4gPiBQZXRyIFZlbGFu DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+IElQRklYIG1haWxpbmcgbGlzdA0KPiA+IElQRklYQGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcGZpeA0KDQo= From nobody Tue Jan 6 07:34:41 2015 Return-Path: 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 1F5A91A8873 for ; Tue, 6 Jan 2015 07:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 T3dGuUMQozmC for ; Tue, 6 Jan 2015 07:34:29 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id C70B91A1A67 for ; Tue, 6 Jan 2015 07:34:19 -0800 (PST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 130641A0920; Tue, 6 Jan 2015 16:33:47 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Brian Trammell In-Reply-To: <23B7BE54EACBED43957AB709C564F7B70185A1FCCD@EMEA-EXCH01.corp.brocade.com> Date: Tue, 6 Jan 2015 16:33:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2EEDA971-A002-436B-9BDF-4941E4883925@trammell.ch> References: <23B7BE54EACBED43957AB709C564F7B70185A1FC39@EMEA-EXCH01.corp.brocade.com> <23B7BE54EACBED43957AB709C564F7B70185A1FCCD@EMEA-EXCH01.corp.brocade.com> To: Paul Aitken X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/rWOpETfNVBkcyIESj3DUT6as7Ws 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:34:34 -0000 hi Paul, > On 06 Jan 2015, at 16:31, Paul Aitken wrote: >=20 > Brian, >=20 >=20 >> -----Original Message----- >> From: Brian Trammell [mailto:ietf@trammell.ch] >> Sent: 06 January 2015 14:26 >> To: Paul Aitken >> Cc: Petr Velan; ipfix@ietf.org >> Subject: Re: [IPFIX] NetFlow v9 to IPFIX conversion >>=20 >> hi Paul, Petr, >>=20 >> So unless I misunderstand here, what we're talking about is third = party vendors >> who have more or less NF9-compatible exporters that are squatting on = chunks >> of the NF9 IE number space >=20 > Correct - though "squatting" might not be quite the right word. These = IDs were allocated with cisco's knowledge in order to prevent NFv9 ID = clashes. >=20 >=20 >> (i.e., there are no Cisco-defined IEs for NetFlow 9 which are > = 2^15). >=20 > I believe there are many Cisco IEs > 32768. Ah, okay. Then, on review... well, while maybe I'd tone down the = cynicism a little bit, everything I say below about my opinion stands. = :) Cheers, Brian >> So the first question is why aren't they using IPFIX in the first = place? But alas... >=20 > Doubtless it was easier to use some NFv9 IDs than to upgrade exporters = and collectors to IPFIX. >=20 >=20 >> It doesn't seem right to me to use Cisco's PEN for this, since even = though Cisco >> has reserved the squatted blocks they know about to prevent = interoperability >> problems, there is no guarantee they know about all the blocks that = exist, and >> it's kind of unfair to ask one company to burn PEN space to correct = the mistakes >> of others. >=20 > +1 >=20 >=20 >> I'd be in favor of asking IANA for a new PEN for this, since it = really is a protocol- >> level incompatibility between NetFlow 9 and IPFIX, and it would be a = relatively >> quick AD-sponsored or opsawg draft to do. (I do think it needs an = RFC, so that >> the PEN registry can point at something to say "what is this?"; see = e.g. PEN >> 29305 for RFC 5103). >>=20 >> Yes, this has the problem that squatting blocks might collide with = each other. I'm >> perfectly okay with that. As a matter of policy, we should not = sanction the de >> facto creation of codepoints in public or semipublic registries = through squatting, >> and while building a registry of squatted blocks to appropriate PENs = is a more >> *elegant* solution, it seems like way too much effort for the = community to >> expend to come up with a nice fix to a messy problem caused by the = lazy. >=20 > As far as I know, that registry currently has just 5 non-cisco = entries, so it wouldn't be hard to code. >=20 > However as you say there could be other ID conflicts which aren't = known about today, and a new PEN would remove the guesswork. >=20 > P. >=20 >=20 >>> On 06 Jan 2015, at 14:52, Paul Aitken wrote: >>>=20 >>> Petr, please see replies inline: >>>=20 >>>=20 >>> From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of Petr Velan >>> Sent: 06 January 2015 12:03 >>> To: ipfix@ietf.org >>> Subject: [IPFIX] NetFlow v9 to IPFIX conversion >>>=20 >>> Hello all, >>>=20 >>> I'm not sure whether this is the right place to ask, but we = encountered >> following problem when converting NetFlow v9 messages to IPFIX. >>>=20 >>> Some vendors (I've heard of ntop) are using elements IDs large than = 32767 in >> NetFlow v9. >>>=20 >>> [P] That=E2=80=99s not invalid in NFv9. RFC 3954 allows a 16-bit = =E2=80=9CField Type=E2=80=9D ID. >>>=20 >>>=20 >>> 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 >>>=20 >>> [P] When I was netflow=E2=80=93police at cisco, the guys at Plixer = helped to identify >> non-cisco NFv9 exporters, and I allocated blocks of 500 or 1000 IDs = for each >> them in the 50,000 =E2=80=93 60,000 range =E2=80=93 effectively = blacklisting those IDs so that >> cisco wouldn=E2=80=99t create duplicate IDs. At that time there were = just 5 such blocks >> recognized by Cisco. If we can identify a PEN for each block then = it=E2=80=99d be simple >> to write a decoder. Unfortunately this method doesn=E2=80=99t extend = to recognizing >> future allocations, or export IDs that weren=E2=80=99t known to us at = the time. >>>=20 >>> BTW, you=E2=80=99re also supposing that the IDs < 32768 are = identical and will remain >> so in future. >>>=20 >>>=20 >>> b) Request a PEN for NetFlow compatibility and just add this PEN for = every >> element that has ID larger than 32767. >>>=20 >>> [P] It=E2=80=99d be more accurate to use Cisco=E2=80=99s PEN for = this ;-) However in principal >> it=E2=80=99s a NFv9-in-IPFIX indicator. >>>=20 >>>=20 >>>=20 >>> 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? >>>=20 >>> [P] I believe you could convince IANA to allocate an ID. However = I=E2=80=99m not yet >> convinced that it=E2=80=99s a good idea. >>>=20 >>> P. >>>=20 >>>=20 >>> Thank you for any opinions, >>>=20 >>> Petr Velan >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >=20 From nobody Tue Jan 6 11:17:59 2015 Return-Path: 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 A4A8D1A1B21 for ; Tue, 6 Jan 2015 11:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QGnVcjnr953D for ; Tue, 6 Jan 2015 11:17:31 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842641A01FA for ; Tue, 6 Jan 2015 11:17:31 -0800 (PST) Received: from [10.1.14.173] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.210.2; Tue, 6 Jan 2015 14:17:04 -0500 Message-ID: <54AC34C9.7040001@plixer.com> Date: Tue, 6 Jan 2015 14:17:29 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Brian Trammell , Paul Aitken References: <23B7BE54EACBED43957AB709C564F7B70185A1FC39@EMEA-EXCH01.corp.brocade.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/AKNYdEJEWBwd63uBpWXRoUH_94c 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 19:17:39 -0000 Hi Brian, On 01/06/2015 09:26 AM, Brian Trammell wrote: > hi Paul, Petr, > > So unless I misunderstand here, what we're talking about is third party vendors who have more or less NF9-compatible exporters that are squatting on chunks of the NF9 IE number space (i.e., there are no Cisco-defined IEs for NetFlow 9 which are > 2^15). Not exactly. There are Cisco defined IEs >2^15. They just don't happen to be in the range 50,000 - 60,000. > So the first question is why aren't they using IPFIX in the first place? But alas... Mostly this is a transitional tactic. > > It doesn't seem right to me to use Cisco's PEN for this, since even though Cisco has reserved the squatted blocks they know about to prevent interoperability problems, there is no guarantee they know about all the blocks that exist, and it's kind of unfair to ask one company to burn PEN space to correct the mistakes of others. I sort of agree. In the absence of squatters using Cisco's PEN is the right thing to do. From what I see in the wild using Cisco's PEN will, in practice, be right far more than wrong. Given that there are squatters it seems polite to not use Cisco's PEN space unless one is reasonably certain that it is a Cisco v9 export that is being mapped. > I'd be in favor of asking IANA for a new PEN for this, since it really is a protocol-level incompatibility between NetFlow 9 and IPFIX, and it would be a relatively quick AD-sponsored or opsawg draft to do. (I do think it needs an RFC, so that the PEN registry can point at something to say "what is this?"; see e.g. PEN 29305 for RFC 5103). I'm OK with a new PEN and RFC to explain it. At the very least it provides a path forward forward for mediators that doesn't result in collisions in Cisco's PEN space. Is this a problem for anything other than RFC 7119 mediators? > Yes, this has the problem that squatting blocks might collide with each other. I'm perfectly okay with that. As a matter of policy, we should not sanction the de facto creation of codepoints in public or semipublic registries through squatting, and while building a registry of squatted blocks to appropriate PENs is a more *elegant* solution, it seems like way too much effort for the community to expend to come up with a nice fix to a messy problem caused by the lazy. Instead of the community; each mediator can build their own list of elegant mappings and fall back to using the new PEN when a better mapping can't be determined. OK. -Andrew > Cheers, > > Brian > > >> On 06 Jan 2015, at 14:52, Paul Aitken wrote: >> >> Petr, please see replies inline: >> >> >> From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of Petr Velan >> Sent: 06 January 2015 12:03 >> To: ipfix@ietf.org >> Subject: [IPFIX] NetFlow v9 to IPFIX conversion >> >> 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. >> >> [P] That’s not invalid in NFv9. RFC 3954 allows a 16-bit “Field Type” ID. >> >> >> 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 >> >> [P] When I was netflow–police at cisco, the guys at Plixer helped to identify non-cisco NFv9 exporters, and I allocated blocks of 500 or 1000 IDs for each them in the 50,000 – 60,000 range – effectively blacklisting those IDs so that cisco wouldn’t create duplicate IDs. At that time there were just 5 such blocks recognized by Cisco. If we can identify a PEN for each block then it’d be simple to write a decoder. Unfortunately this method doesn’t extend to recognizing future allocations, or export IDs that weren’t known to us at the time. >> >> BTW, you’re also supposing that the IDs < 32768 are identical and will remain so in future. >> >> >> b) Request a PEN for NetFlow compatibility and just add this PEN for every element that has ID larger than 32767. >> >> [P] It’d be more accurate to use Cisco’s PEN for this ;-) However in principal it’s a NFv9-in-IPFIX indicator. >> >> >> >> 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? >> >> [P] I believe you could convince IANA to allocate an ID. However I’m not yet convinced that it’s a good idea. >> >> P. >> >> >> Thank you for any opinions, >> >> Petr Velan >> >> _______________________________________________ >> 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 nobody Tue Jan 6 12:08:01 2015 Return-Path: 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 606621A1B91 for ; Tue, 6 Jan 2015 12:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 NSlXMpqtll4j for ; Tue, 6 Jan 2015 12:07:53 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEAD1A1B89 for ; Tue, 6 Jan 2015 12:07:52 -0800 (PST) Received: from [10.1.14.173] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.210.2; Tue, 6 Jan 2015 15:07:25 -0500 Message-ID: <54AC4097.1050602@plixer.com> Date: Tue, 6 Jan 2015 15:07:51 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Petr Velan , References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030103040800000006050007" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/rlvx0B0pSMfOw4GqeF_6Zd6x1lU 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 20:07:59 -0000 --------------030103040800000006050007 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit 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 list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------030103040800000006050007 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit
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 list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------030103040800000006050007-- From nobody Wed Jan 7 12:04:18 2015 Return-Path: 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 9D0731A1ABF for ; Wed, 7 Jan 2015 12:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 bvueAsYol7oE for ; Wed, 7 Jan 2015 12:04:08 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EA41A0275 for ; Wed, 7 Jan 2015 12:04:07 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id dc16so4193490qab.8 for ; Wed, 07 Jan 2015 12:04:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sevone.com; s=google; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=TBHU0NnWBpz8l8wlHQpV306AnQsSR16aagOPtFBaEHQ=; b=XmhB2xhXFdho7mZdpb+L4lI5EfhJACY8kD+uEFarZdFneXwuoJzvDD/Dg9ek6S9AJL nFoSjvxWYFhEYhZif9NaiAebzIOHKraQKF6Xt3OI49ZyCv0V1ip9ianwNL4THDEXhvRh 2L9/5ZbSiwEp5VUt3/eLWl5eeN1VLABdQE/Z0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=TBHU0NnWBpz8l8wlHQpV306AnQsSR16aagOPtFBaEHQ=; b=ILk75EcJ6seYVXYu35JSbEnE4Ksewhp4PVP2sxPw+l0AUHKoyNGpqbs/PA7u/N/wMa O3g2Zf1bQuTWLasdX0BWJMZqKWRffLyass/7aYwAh7yBCEUeV/y8BpPj+pRAoJa2tT2H DDPnKVU++CfMsYluQiwbIUgVWNarwqpH15o5Zr9OMWuJ37pL+nc6a5fjKDy36deiHh4Z zxTwNzX7/QYuFqfWfoD4uGaqaC0ukgOXNKF7EV2Z9/pOoWj0pzsJ+/sntcwkH/+S8WAk i+iN0ab0avqbetI6/Ot9Wf5RInwBt+SA8fd7XUe+407/1okRRsb4K/ojarFCIdhPW0Wh 0oiw== X-Gm-Message-State: ALoCoQlLasBQGafKwr25NLTjsX53E4S33rr07RJc/veneHBFQDBMCHoWBAw+lDm1yvjMnGXHtdWJhMh4NS8GBfg+sP3NvRtkXjzJXuE4LE1Ofd+khbbB0tg= X-Received: by 10.224.95.7 with SMTP id b7mr7928197qan.70.1420661046966; Wed, 07 Jan 2015 12:04:06 -0800 (PST) Received: from mwang-pc.sevone.com (50-202-126-166-static.hfc.comcastbusiness.net. [50.202.126.166]) by mx.google.com with ESMTPSA id u49sm2069893qgd.26.2015.01.07.12.04.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Jan 2015 12:04:06 -0800 (PST) Message-ID: <54AD9135.8000508@sevone.com> Date: Wed, 07 Jan 2015 15:04:05 -0500 From: Min Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: multipart/alternative; boundary="------------080105090004030502000507" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/WTQLYCXSSNrhScBn0UuPj7ELGvc Subject: [IPFIX] How to interpret the scope/options in options template wisely X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 20:04:16 -0000 This is a multi-part message in MIME format. --------------080105090004030502000507 Content-Type: text/plain; charset=US-ASCII; format=flowed HI in RFC-7011, it said: 4 . Specific Reporting Requirements The Collecting Process MUST check the possible combinations of Information Elements within the Options Template Records to correctly interpret the following Options Templates. Is there any guidance on how to interpret the scope/option fields IE in those options templates. There are hundreds of IEs, in the real world, how can a reporting engine possibly know/interpret these combinations wisely without check those IEs manually first? thanks. min -- ------------------------------ SevOne, Inc. reserves the right to monitor the transmission of this message and to take corrective action against any misuse or abuse of its e-mail system or other components of its network. The information contained in this e-mail may be confidential and/or legally privileged. It is intended solely for the addressee. If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited and may be unlawful. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@sevone.com. --------------080105090004030502000507 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 
HI


in RFC-7011, it said:




4.  Specific Reporting Requiremen=
ts


The Collecting Process MUST check the possible combinations of
   Information Elements within the Options Template Records to correctly
   interpret the following Options Templates.


Is there any guidance on how to interpret the scope/option fields IE in tho=
se options templates.


There are hundreds of IEs, in the real world, how can a reporting engine po=
ssibly know/interpret these combinations wisely  without check those IEs ma=
nually first?




thanks.


min


  













SevOne, Inc. reserves the right t=
o monitor the transmission of this message and to take corrective action ag=
ainst any misuse or abuse of its e-mail system or other components of its n=
etwork.


The information contained in this e-m=
ail may be confidential and/or legally privileged. It is intended solely fo=
r the addressee.  If the reader of this message is not an intended rec=
ipient, you are hereby notified that any unauthorized review, use, disclosu=
re, dissemination, distribution, or copying of this communication, or any o=
f its contents, is strictly prohibited and may be unlawful. If you have rec=
eived this communication in error, please reply to the sender and destroy a=
ll copies of the message.  To contact us directly, send to postmaster@sevon=
e.com. 

--------------080105090004030502000507--