Re: [IPFIX] Comments needed for draft-fu-ipfix-network-security-00

Paul Aitken <> Mon, 29 December 2014 10:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 03BFC1A00C5 for <>; Mon, 29 Dec 2014 02:43:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IUwxnVqtaZ54 for <>; Mon, 29 Dec 2014 02:43:01 -0800 (PST)
Received: from ( [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46EDC1A00B8 for <>; Mon, 29 Dec 2014 02:43:01 -0800 (PST)
Received: from pps.filterd (m0048192 []) by (8.14.5/8.14.5) with SMTP id sBTASj6r010323; Mon, 29 Dec 2014 02:42:51 -0800
Received: from ([]) by with ESMTP id 1rk2568dhf-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Dec 2014 02:42:51 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 29 Dec 2014 02:42:50 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 29 Dec 2014 03:42:50 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 29 Dec 2014 03:42:49 -0700
Received: from ([fe80::18c9:7b21:74fd:7e48]) by ([fe80::548c:8759:5d5e:1c0b%12]) with mapi; Mon, 29 Dec 2014 11:42:47 +0100
From: Paul Aitken <>
To: "Hedanping (Ana)" <>, "" <>, "" <>, "" <>, Benoit Claise <>, Andrew Feren <>
Date: Mon, 29 Dec 2014 11:42:46 +0100
Thread-Topic: Comments needed for draft-fu-ipfix-network-security-00
Thread-Index: AdAgDDK1FVa1OpepS8CUXrZ5IZppbADPbpNg
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_23B7BE54EACBED43957AB709C564F7B701857F3D09EMEAEXCH01cor_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-29_01:2014-12-24,2014-12-28,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-1412290109
Cc: "" <>
Subject: Re: [IPFIX] Comments needed for draft-fu-ipfix-network-security-00
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, 29 Dec 2014 10:43:05 -0000


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:

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.


From: Hedanping (Ana) []
Sent: 25 December 2014 06:30
To:;;; Paul Aitken; Benoit Claise; Andrew Feren
Subject: Comments needed for draft-fu-ipfix-network-security-00


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:

Your comments are welcome!

Merry holidays and happy new year!