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

From: "Hedanping (Ana)" <[email-masked]>
Date: Thu, 25 Dec 2014 06:29:59 +0000

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

---

From: Paul Aitken <[email-masked]>
Date: Mon, 29 Dec 2014 11:42:46 +0100

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:[email-masked]]
Sent: 25 December 2014 06:30
To: [email-masked]; [email-masked]; [email-masked]; Paul Aitken; Benoit Claise; Andrew Feren
Cc: [email-masked]
Subject: Comments needed for draft-fu-ipfix-network-security-00

All,

Danping