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

[Paul Aitken <[e-mail]>]

Ana, please find some replies inline.

Thanks,
P.


From: Hedanping (Ana) [mailto:[e-mail]]
Sent: 04 January 2015 03:19
To: Paul Aitken; [e-mail]; [e-mail]; [e-mail]; Benoit Claise; Andrew Feren
Cc: [e-mail]
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:[e-mail]]
Sent: Monday, December 29, 2014 6:43 PM
To: Hedanping (Ana); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Benoit Claise; Andrew Feren
Cc: [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: 25 December 2014 06:30
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Paul Aitken; Benoit Claise; Andrew Feren
Cc: [e-mail]<mailto:[e-mail]>
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