DOTS T. Fu
Internet Draft Huawei
Intended status: Standard Track D. Zhang
Expires: Nov 2016 Alibaba
L. Xia
M. Li
Huawei
June 14, 2016
IPFIX IE Extensions for DDoS Attack Detection
draft-fu-dots-ipfix-extension-01.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Fu, et al. Expires December 14, 2016 [Page 1]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
This Internet-Draft will expire on December 14, 201616.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
DDoS Open Threat Signaling (DOTS) Working Group is for developing
the standard signaling mechanisms, together with the DDoS related
telemetry and threat handling requests and data transmitted by them
used in DDoS problem space. Although IP Flow Information Export
(IPFIX), Packet Sampling (PSAMP), and Packet Selection methods are
useful for network security inspection, there are still some gaps
existing to identify some categories of DDoS attacks. To fill in
the gaps, this document describes the connection sampling mechanism
and explains why it is needed for detecting DDoS attacks. It also
defines several new IPFIX Information Elements (IEs). Then, it
presents some examples to show how to use these new IPFIX IEs
together with the existing IPFIX IEs to detect specific DDoS attacks.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document............................ 4
2.1. Terminology ............................................ 4
3. Connection Sampling and new IEs.............................. 5
3.1. Packet Sampling vs Connection Sampling ..................5
3.2. Use Cases for New IEs................................... 6
3.2.1. Upstream/Downstream Counters .......................6
3.2.2. Fragment statistic................................. 7
3.2.3. Response Time Calculation ..........................8
3.2.4. Symptoms of Exceptions............................. 8
3.2.5. Extended Value of FlowEndReason ....................9
3.3. Definition of New IEs.................................. 10
4. Application of the New IEs for Attack Detection .............12
4.1. Detect ICMP Reflection Attack.......................... 12
4.2. Detect Fragment Attack................................. 13
Fu, et al. Expires Nov 14, 2016 [Page 2]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
4.3. Detect Slowloris Attack................................ 14
4.4. Detect Out-of-order Packets Attack .....................15
5. Security Considerations..................................... 15
6. IANA Considerations ........................................ 15
7. References ................................................. 19
7.1. Normative References................................... 19
7.2. Informative References................................. 19
8. Acknowledgments ............................................ 20
1. Introduction
As network security issues arising dramatically nowadays, network
administrators are eager to detect and identify attacks as early as
possible, generate countermeasures with high agility. Due to the
enormous amount of network attack types, metrics useful for attack
detection are also enormous. Moreover, attacking methods are
evolved rapidly, which brings challenges to designing detection
mechanism.
Specifically, DOTS WG aims for developing the standard solution to
fight against the DDoS attacks. The following sentence is from the
DOTS WG charter:
"The aim of DDoS Open Threat Signaling (DOTS) is to develop a
standards based approach for the realtime signaling of DDoS related
telemetry and threat handling requests and data between elements
concerned with DDoS attack detection, classification, traceback, and
mitigation."
According to the above sentence, the signaling mechanisms and
contents are all the essential parts of the solution, in which the
contents refer to the realtime DDoS related telemetry information
and threat handling messages.
The IPFIX Protocol [RFC7011] defines a generic exchange mechanism
for flow information and events. It supports source-triggered
exporting of information via the push model approach. The IPFIX
Information Model [IPFIX-IANA] defines a list of standard
Information Elements (IEs) which can be carried by the IPFIX
protocol. The IPFIX requirement [RFC3917] points out that one of
the target applications of IPFIX is attack and intrusion detection.
Although the existing IPFIX/PSAMP protocol, packet selection methods,
as well as the related standard IEs provide a rich source of data
for security inspection by checking the status/events of the traffic,
there are still some gaps existing to identify some categories of
the DDoS attacks. More detailed gap analysis is given in the
following section.
Fu, et al. Expires Nov 14, 2016 [Page 3]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
This document focuses on the DDoS related telemetry information part
for DOTS, and proposes using the connection sampling method with a
set of IPFIX IEs for the goal of inspecting mainly some connection-
based and Zero-Day DDoS attacks, which normally are the kinds of the
low & slow DDoS attack and not easy to be inspected as flood attacks.
Some of these IPFIX IEs already exist; some are the new defined ones
with their formats specified. The wise utilization of these IEs will
improve the DDoS attack inspection and will support the offline
analysis of data from different operators in the future with minimal
resource consumption, which is very necessary for increasing the
operators' intelligence of identifying new and unknown DDoS attacks.
This document is structured as following: Section 3 discusses the
connection sampling mechanism and introduces the new IPFIX IEs
derived from relevant use cases. Section 4 describes how to use
these IEs to detect specific DDoS attacks.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
2.1. Terminology
IPFIX-specific terminology (Information Element, Template, Template
Record, Options Template Record, Template Set, Collector, Exporter,
Data Record, etc.) used in this document is defined in Section 2 of
[RFC7011]. As in [RFC7011], these IPFIX-specific terms have the
first letter of a word capitalized.
This document also makes use of the same terminology and definitions
as [I-D.draft-ietf-dots-requirements] and [I-D.draft-ietf-dots-use-
cases].
The following are the new terms in this document.
o Connection Sampling
Connection Sampling is a connection oriented sampling mechanism. If
one connection is selected for DDoS attack detection, then all the
packets (if possible) of this connection will be sampled during one
detection period.
o Victim
The target that suffers DDoS attack.
Fu, et al. Expires Nov 14, 2016 [Page 4]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
o Observer
Devices or software deployed at observation point defined in IPFIX.
3. Connection Sampling and new IEs
3.1. Packet Sampling vs Connection Sampling
Packet sampling selection is a widely used method to select packets
from network traffic for reporting. Its selection operations include
time-based selection, count-based selection, random selection,
probability-based selection and so on. Although it is easy and
efficient, it still has a number of limitations in inspecting some
types of DDoS attack:
o Several research projects [N. DUFFIELD, 2003], [D. BRAUCKHOFF
2006] show that packet sampling impacts greater on small
volumetric flows (with only few packets) due to the smaller
sampling probability compared with large volumetric flows, which
means that packet sampling may impair the detection performance
for small volumetric flow based DDoS attacks; Connection sampling
can pay more attention to small flows than packet sampling.
o The communication is 2-way between source and destination.
Current packet sampling is used to select a subset of packets
from all the observed packets. One of its purposes is to select
the appropriate packets to estimate the whole traffic. Although
packet sampling can produce flows by using property matching or
hash method, it does not consider semantics of the connection
(i.e. whether two flows are belonging to one connection or not).
In this scenario, packet sampling is applied independently in
each direction. If packets are sampled only in one direction,
then it will be difficult or inaccurate to detect specific DDoS
attacks such as SNMP/DNS Reflected Amplification because of the
loss of the information in the opposite direction. It cannot
distinguish whether there are too much requests from the victim
or not.
o Although packet sampling at full line rate, i.e. with probability
100%, is not excluded in principle, resource constraints may not
permit it in practice [RFC5474]. For certain DDoS attack such as
HTTP Slowloris, enough packets are needed to realize the
detection. In this scenario, connection sampling can provide more
meaningful packets than packet sampling because all the packets
it samples are belonging to the target connection.
Fu, et al. Expires Nov 14, 2016 [Page 5]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
o Connection sampling method uses some new connection related IEs
for attack analysis because of their meaning/value available for
judging the status of one connection, which current packet
sampling method is lack of. For example, tcpControlStateBits is
an IE to record the current state of TCP session. If a packet
with erroneous flag is identified in any stage of three
handshakes, it should be considered as a symptom of exception.
As a consequence from the above analysis, a connection oriented
sampling method is more suitable for the security application:
Rather than sampling a small part of packets in the traffic between
the communication peers, the connection sampling records all (if
possible) TCP/UDP connection packets (including packets during
connection setup and close phase if there is) between them once that
connection is selected to be sampled. In nature, the connection
sampling method is able to track the complete working status of the
connection state machine. So, it can identify the abnormal state of
the connection or the attack easily and accurately. Although the
IPFIX/PSAMP also supports the connection sampling mechanism (that is
the packet filtering technology for packet selection [RFC5475]), it
does not explicitly discuss how to use this method for the detection
of connection-based and Zero-Day DDoS attacks in a systematical way.
Furthermore, if the observer (e.g. device, middle box) supports the
export of the new IPFIX IEs proposed in this document, the traffic
volume between exporter and analyzer can be greatly reduced compared
with PSAMP, which should export the detailed packet information for
further attack analysis.
3.2. Use Cases for New IEs
In this section, several use cases are discussed to identify the
requirements where new IEs are desirable for the network attacks
detection.
3.2.1. Upstream/Downstream Counters
Take ICMP reflection attack as an example, ICMP flow model has
features such as the ICMP Echo/Echo Reply dominate the whole traffic
flow, ICMP packet interval is usually not too short (normally 1
pkt/s). Usually, the normal ratio between ICMP echo to ICMP echo
reply packets is around 1:1. When a DDOS reflection attack happens,
a sudden burst of messages to a destination endpoint can be detected.
In turn, the ratio between echo reply and echo packets will be
significantly biased from the normal ratio, i.e., exceed 20:1. So
the proper way to distinguish an attack from the normal
communication is to check this ratio.
Fu, et al. Expires Nov 14, 2016 [Page 6]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
However, the current IPFIX IEs for ICMP contain the ICMP type and
code for both IPv4 and IPv6 only for a single ICMP packet rather
than statistical property of the ICMP session. Further metrics like
the cumulated sum of various counters should be calculated based on
sampling method defined by the Packet SAMPling (PSAMP) protocol
[RFC5477]. Similar problems occur in TCP, UDP, SNMP and DNS attacks.
It would be useful to calculate the number of the upstream and
downstream packets for one connection separately over time in order
to detect the anomalies of the network. For ICMP reflection attack,
a more generic approach is to define two basic metrics icmpEchoCount
and icmpEchoReplyCount as new IPFIX IEs to represent the cumulated
upstream and downstream packets counter within a ICMP connection.
Note that in some case, the asymmetric routing mainly caused by the
wide application of multipath technologies (e.g., load balancing,
link aggregation) in network will make the bidirectional connection
sampling on some network devices over the multipath to be not
possible. This problem can be avoided by strategically deploying and
enabling the connection sampling function in the network devices
which are not located over the multipath.
3.2.2. Fragment statistic
Fragment attack employs unexpected formats of fragmentation, e.g.
without last fragment or incorrect fragment offset[RFC791], which
result in errors such as fragmentation buffer overrun and fragment
overlapped. Existing IPFIX fragmentation metrics includes
fragmentOffset, fragmentIdentification, fragmentFlags, which only
indicate the attributes of a single fragment, and are not suitable
for attack detection. Instead, the network attack should be observed
based upon a historic, integrated view of fragmented packets of a
connection. For instances, if more than 500 out of 1000 fragmented
packets have fragment errors, it is likely that a fragment attack
happens.
Therefore, a number of new IEs associated with fragment statistics
are proposed as follows:
o fragmentPacketCount: The number of the fragmented packets of the
same connection should be checked, and this metric is proposed;
o fragmentFirstTooShortCount: Attacker might intent to exclude
destination port from the first fragment so as to bypass
detection from firewall. This metric is proposed to indicate the
number of the invalid first fragments in the observed connection;
Fu, et al. Expires Nov 14, 2016 [Page 7]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
o fragmentFlagErrorCount: This metric is proposed to detect early
whether the fragment flags are incorrectly set on purpose.
o fragmentOffestErrorCount: This metric is proposed to count the
number of fragments with offset error, and the value can be used
to indicate attack occurs;
3.2.3. Response Time Calculation
For other DDoS attacks such as Http slowloris, there will be too many
connections that should be kept in the victim (server), which lead to
excessive resource consumption. As a result, the response time between
client and server will increase greatly. Challenge Collapasar(CC)
attack can also exhaust the resources of the server and generate the
similar results. Thus, the following IEs are proposed as a symptom of
these kinds of attacks:
serverResponseTime: For tcp, it denotes the time difference
between the time point that the observer views the SYN packet from
client to server and the time point that the observer views the
SYN-ACK packet from server to client.
clientResponseTime: For tcp, it denotes the time difference
between the time point that the observer views the SYN-ACK packet
from server to client and the time point that the observer views
the ACK packet from client to server.
sessionResponseTime: The sum of serverResponseTime and
clientResponseTime. It is the Round Trip Time (RTT) between client
and server.
3.2.4. Symptoms of Exceptions
In http slowloris attack the client may send packets to victim
periodically which can cause the performance lost on the server. The
characteristic of the attack is that there are too many connections
on the victim. However, the volume for these connections is small.
In order to detect this attack, the first step is to get the packets
that are belonging to the same connection. The second step is to
find the periodicity. Thus the two indices pktTimeInterval and
pktTimeIntervalVariance are needed. The index pktTimeInterval
denotes the average time difference between two successive packets
and the index pktTimeIntervalVariance denotes the variance of
multiple time difference. Large pktTimeInterval and small
pktTimeIntervalVariance can be a symptom of slow packet attack. On
the other hand, the payload size of the packets in http slowloris
Fu, et al. Expires Nov 14, 2016 [Page 8]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
attack is very small and the size difference is also small. So the
index octetVariance can be used to identify the characteristic.
To degrade the performance of the victim, the malicious clients may
send too many out-of-order packets, which will consume too much
memory on the server. Although out-of-order packets are permit in
the TCP protocol, it is possible to be leveraged to cause DDoS
attack. So the index tcpOutoforderTotalCount is helpful to detect
this kind of exception. For observer, it maintains one counter for
each tcp connection. The initial sequence number of the client is
saved in the counter. The counter increases by the sequence number
of the packets it sees from client to server. If the observer sees a
packet with lower sequence number than the current counter value,
then the packet will be considered as an out-of-order packet.
In IPFIX, the index tcpControlBits is used to record the
corresponding status bits in TCP header of the packets[IPFIX-IANA].
In order to detect the application attacks which can cause the
protocol exception such as the wrong use of the tcp status bits
before and after the tcp connection establishment, another index
called tcpControlStateBits is needed. For example, when the observer
sees the SYN packet from client to server, it sets 15th bit of
tcpControlStateBits to 1; when it sees the SYN-ACK packet from
server to client, it sets 14th bit to 1, and so on. If one endpoint
sends the packet with wrong bits during the establishment of the
connection, then the observer will identify the exception by the
value of tcpControlStateBits.
3.2.5. Extended Value of FlowEndReason
Refer to [IPFIX-IANA], there are 5 defined reasons for Flow
termination, with values ranging from 0x01 to 0x05:
0x01: idle timeout
0x02: active timeout
0x03: end of Flow detected
0x04: forced end
0x05: lack of resources
There is an additional reason caused by state machine anomaly. When
FIN/SYN is sent, but no ACK is replied after a waiting timeout, the
existing five reasons do not match this case. Therefore, a new value
Fu, et al. Expires Nov 14, 2016 [Page 9]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
is proposed to extend the FlowEndReason, which is 0x06: protocol
exception timeout.
3.3. Definition of New IEs
The following is the table of all the new IEs that a device would
need to export for attack statistic analysis. The recommended
registrations to IANA are described in the IANA considerations
section.
Fu, et al. Expires Nov 14, 2016 [Page 10]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
+---------------------------+------------+------+-----------------+
| Field Name | Size (bits)| IANA | Description |
| | | IPFIX| |
| | | ID | |
+---------------------------+------------+------+-----------------+
| fragmentPacketCount | 32 | TBD | Counter of |
| | | | session |
| | | | fragments |
| fragmentFirstTooShortCount| 32 | TBD | Number of |
| | | | packets with |
| | | | first fragment |
| | | | too short |
| fragmentFlagErrorCount | 32 | TBD | Number of |
| | | | fragments with |
| | | | erroneous flag |
| fragmentOffsetErrorCount | 32 | TBD | Number of |
| | | | fragments with |
| | | | erroneous offset|
| | | | |
| icmpEchoCount | 32 | TBD | The number of |
| | | | ICMP echo. |
| icmpEchoReplyCount | 32 | TBD | The number of |
| | | | ICMP echo |
| | | | reply |
| | | | |
| octetVariance | 64 | TBD |IP packet byte |
| | | |variance |
| | | |statistic |
|tcpControlStateBits | 16 | TBD |tcp states |
|tcpOutoforderTotalCount | 64 | TBD |out of order |
| | | |packets statistic|
| | | | |
|pktTimeInterval | 64 | TBD |the average time |
| | | |interval between |
| | | |two successive |
| | | |packets |
|pktTimeIntervalVariance | 64 | TBD |the variance of |
| | | |pktTimeInterval |
| | | | |
|serverResponseTime | 16 | TBD |the response time|
| | | |of a server |
|clientResponseTime | 16 | TBD |the response time|
| | | |of a client |
|sessionResponseTime | 16 | TBD |the response time|
| | | |of a session |
+---------------------------+------------+------+-----------------+
Table 1: Information Element Table
Fu, et al. Expires Nov 14, 2016 [Page 11]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
4. Application of the New IEs for Attack Detection
This section presents a number of examples to help for the easy
understanding of the application of these new IEs for attack
detection.
4.1. Detect ICMP Reflection Attack
According to previous analysis, the template for detecting ICMP
reflection attack should at least contain IEs shown in Table 2.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 40 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID TBD | Field Count = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetDeltaCount | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| icmpEchoCount | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| icmpEchoReplyCount | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowEndSeconds | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 2: Template example for detecting ICMP attack
An example of the actual ICMP event data record is shown below in
a readable form as below:
{sourceIPv4Address = 192.168.0.101, destinationIPv4Address =
192.168.0.201, protocolIdentifier = 1, packetDeltaCount = 3000,
icmpEchoCount = 120, icmpEchoReplyCount = 2880, flowStartSeconds
= 100, flowEndSeconds = 200}
protocolIdentifier = 1 represents the ICMP proptocol. There are 30
ICMP messages transmited per second. The ICMP Echo Reply to ICMP
Fu, et al. Expires Nov 14, 2016 [Page 12]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
Echo packet ratio is 24:1, which indicates a high possibility of
ICMP reflection attack.
4.2. Detect Fragment Attack
The template for detecting fragment attack should at least contain
IEs shown in Table 3. It requires the observation point to trace
complete fragmented packet and accumulate the errors.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 48 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID TBD | Field Count = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetDeltaCount | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| fragmentPacketCount | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|fragmentFirstTooShortCount | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|fragmentFlagErrorCount | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|fragmentOffsetErrorCount | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowEndSeconds | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 3: Template example for detecting fragment attack
An example of the actual fragment attack record is shown below in a
readable form as below:
{sourceIPv4Address = 192.168.0.101, destinationIPv4Address =
192.168.0.201, protocolIdentifier = 6, packetDeltaCount = 5000,
fragmentPacketCount = 4000, fragmentFirstTooShortCount = 0,
fragmentFlagErrorCount = 0, fragmentOffestErrorCount = 3000,
flowStartSeconds = 100, flowEndSeconds = 200}
In this case, fragment offset errors are used to exhaust resource at
the receiver.
Fu, et al. Expires Nov 14, 2016 [Page 13]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
4.3. Detect Slowloris Attack
The template for detecting resource exhausting application attack
such as http slowloris attack should contain a subnet of IEs shown
in Table 4.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 48 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID TBD | Field Count = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| serverResponseTime | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| clientResponseTime | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sessionResponseTime | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| pktTimeInterval | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| pktTimeIntervalVariance | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowEndSeconds | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 4: Template example for detecting slowloris attack
An example of the actual record is shown below in a readable form as
below:
{sourceIPv4Address = 192.168.0.101, destinationIPv4Address =
192.168.0.201, protocolIdentifier = 6, serverResponseTime = 200,
clientResponseTime = 10, sessionResponseTime = 210, pktTimeInterval
= 500, pktTimeIntervalVariance = 1000, flowStartSeconds = 100,
flowEndSeconds = 200}
Fu, et al. Expires Nov 14, 2016 [Page 14]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
4.4. Detect Out-of-order Packets Attack
The template for detecting out-of-order packets attack should
contain IEs shown in Table 5.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 32 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID TBD | Field Count = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetDeltaCount | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| tcpOutoforderTotalCount | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowEndSeconds | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 5: Template example for detecting out-of-order attack
An example of the actual record is shown below in a readable form as
below:
{sourceIPv4Address = 192.168.0.101, destinationIPv4Address =
192.168.0.201, protocolIdentifier = 6, packetDeltaCount =3000,
tcpOutoforderTotalCount = 2000, flowStartSeconds = 100,
flowEndSeconds = 200}
5. Security Considerations
No additional security considerations are introduced in this
document. The same security considerations as for the IPFIX protocol
[RFC7011] apply.
6. IANA Considerations
The following information elements are requested from IANA IPFIX
registry.
Name: fragmentPacketCount
Fu, et al. Expires Nov 14, 2016 [Page 15]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
Description: This Information Element is the counter of session
fragments.
Abstract Data Type: unsigned32
Data Type Semantics: TBD
Name: fragmentFirstTooShortCount
Description: This Information Element indicates the number of
packets with first fragment too short.
Abstract Data Type: unsigned32
Data Type Semantics: TBD
Name: fragmentFlagErrorCount
Description: This Information Element specifies number of
fragments with flag error. When the DF bit and MF bit of the
fragment flag are set in the same fragment, there is an error at
the fragment flag.
Abstract Data Type: unsigned32
Data Type Semantics: TBD
Name: fragmentOffsetErrorCount
Description: This Information Element specifies number of
fragments with offset error.
Abstract Data Type: unsigned32
Data Type Semantics: TBD
Name: icmpEchoCount
Description: icmp Echo packets.
Fu, et al. Expires Nov 14, 2016 [Page 16]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
Abstract Data Type: unsigned32
Data Type Semantics: deltaCounter
Name: icmpEchoReplyCount
Description: icmp Echo Reply packets.
Abstract Data Type: unsigned32
Data Type Semantics: deltaCounter
Name: octetVariance
Description: IP packet byte variance statistic.
Abstract Data Type: unsigned64
Data Type Semantics: quantity
Name: tcpControlStateBits
Description: the current tcp states of the connection.
Abstract Data Type: unsigned16
Data Type Semantics: flags
Name: tcpOutoforderTotalCount
Description: out of order packets statistic.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
Name: pktTimeInterval
Fu, et al. Expires Nov 14, 2016 [Page 17]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
Description: the average time interval between two successive
packets in a flow.
Abstract Data Type: unsigned32
Data Type Semantics: quantity
Name: pktTimeIntervalVariance
Description: the variance of the time intervals between two
successive packets in a flow.
Abstract Data Type: unsigned64
Data Type Semantics: quantity
Name: serverResponseTime
Description: the response time of a server.
Abstract Data Type: unsigned16
Data Type Semantics: quantity
Name: clientResponseTime
Description: the response time of a client.
Abstract Data Type: unsigned16
Data Type Semantics: quantity
Name: sessionResponseTime
Description: the response time of a session.
Abstract Data Type: unsigned16
Data Type Semantics: quantity
Fu, et al. Expires Nov 14, 2016 [Page 18]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
A new value is added to FlowEndReason:
0x06: protocol exception timeout
The flow was terminated due to protocol state machine anomaly and
unexpected timeout.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification
of the IP Flow Information Export (IPFIX) Protocol for the
Exchange of Flow Information", STD 77, RFC 7011, September
2013.
[RFC3917] Quittek, J., Zseby, T., Claise, B., Zander, S.,
"Requirements for IP Flow Information Export (IPFIX)", RFC
3917, October 2004.
[RFC5474] N. Duffield Ed., D. Chiou, B. Claise, A. Greenberg, M.
Grossglauser, J. Rexford, "A Framework for Packet
Selection and Reporting", RFC 5474, March 2009.
[RFC5475] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F.
Raspall, "Sampling and Filtering Techniques for IP Packet
Selection", RFC 5475, March 2009.
[RFC5476] B. Claise, Ed., A. Johnson, J. Quittek, "Packet Sampling
(PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5477] T. Dietz, B. Claise, P. Aitken, F. Dressler, G. Carle, "
Information Model for Packet Sampling Exports ", RFC 5477,
March 2009.
7.2. Informative References
[IPFIX-IANA]
IANA, "IPFIX Information Elements registry",
<http://www.iana.org/assignments/ipfix>.
Fu, et al. Expires Nov 14, 2016 [Page 19]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
[I-D.draft-ietf-dots-requirements]
Mortensen, A., Moskowitz, R., Reddy, T., "DDoS Open
Threat Signaling Requirements", work in progress,
October, 2015.
[I-D.draft-ietf-dots-use-cases]
Dobbins, R., Fouant, S., Migault, D., Moskowitz, R.,
Teague, N., Xia, L., " Use cases for DDoS Open Threat
Signaling", work in progress, October, 2015.
[D. BRAUCKHOFF 2006]
Daniela Brauckhoff, Bernhard Tellenbach, Arno Wagner,
Martin May, and Anukool Lakhina. 2006. Impact of packet
sampling on anomaly detection metrics. In Proceedings of
the 6th ACM SIGCOMM conference on Internet measurement
(IMC '06). ACM, New York, NY, USA, 159-164.
[N. DUFFIELD, 2003]
DUFFIELD, N., LUND, C., AND THORUP, M., Estimating Flow
Distributions from Sampled Flow Statistics. In ACM SIGCOMM
(Karlsruhe, August 2003).
8. Acknowledgments
The authors would thank Danping He and Yibo Zhang for their great
help during the initial period of this draft.
The authors would also thank Tienan Wang for his explain about the
implementation of DDoS attack solutions.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Fu, et al. Expires Nov 14, 2016 [Page 20]
Internet-Draft IPFIX IE Extensions for DDoS Detection June 2016
Tianfu Fu
Huawei
Q11, Huanbao Yuan, 156 Beiqing Road, Haidian District
Beijing 100095
China
Email: futianfu@huawei.com
DaCheng Zhang
Alibaba
Email: Dacheng.zdc@alibaba-inc.com
Liang Xia (Frank)
Huawei
101 Software Avenue, Yuhuatai District
Nanjing, Jiangsu 210012
China
Email: Frank.xialiang@huawei.com
Bo Zhang (Alex)
Huawei
101 Software Avenue, Yuhuatai District
Nanjing, Jiangsu 210012
China
Email: Alex.zhangbo@huawei.com
Min Li
Huawei
Huawei Technologies Duesseldorf GmbH, European Research Center,
Riesstr. 25, 80992 Muchen, Germany
Email: l.min@huawei.com
Fu, et al. Expires Nov 14, 2016 [Page 21]