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

"Hedanping (Ana)" <ana.hedanping@huawei.com> Sun, 04 January 2015 03:19 UTC

Return-Path: <ana.hedanping@huawei.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07D81A1B06 for <ipfix@ietfa.amsl.com>; 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 <ipfix@ietfa.amsl.com>; 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 <ipfix@ietf.org>; 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)" <ana.hedanping@huawei.com>
To: Paul Aitken <paitken@Brocade.com>, "ipfix@ietf.org" <ipfix@ietf.org>, "ipfix-chairs@tools.ietf.org" <ipfix-chairs@tools.ietf.org>, "stbryant@cisco.com" <stbryant@cisco.com>, Benoit Claise <bclaise@cisco.com>, Andrew Feren <andrewf@plixer.com>
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" <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 <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Jan 2015 03:19:05 -0000

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.

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.

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

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,
We propose to use session based sampling, thus totalCounter is sufficient to 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 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.

*         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.



*         icmpEchoCount and icmpEchoReplyCount semantics may be totalCounter 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 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<mailto:ipfix@ietf.org>; ipfix-chairs@tools.ietf.org<mailto:ipfix-chairs@tools.ietf.org>; stbryant@cisco.com<mailto:stbryant@cisco.com>; Paul Aitken; Benoit Claise; Andrew Feren
Cc: draft-fu-ipfix-network-security@tools.ietf.org<mailto: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