Internet DRAFT - draft-fu-dots-ipfix-extension
draft-fu-dots-ipfix-extension
DOTS T. Fu
Internet Draft Huawei
Intended status: Standard Track D. Zhang
Expires: April 2016 Alibaba
L. Xia
M. Li
Huawei
October 19, 2015
IPFIX IE Extensions for DDoS Attack Detection
draft-fu-dots-ipfix-extension-00.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 April 19, 2016 [Page 1]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
This Internet-Draft will expire on April 19, 200916.
Copyright Notice
Copyright (c) 2015 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
Although most of the existing IP Flow Information Export (IPFIX)
Information Elements (IEs) are useful for network security
inspection, there are still some gaps existing to identify a number
of categories of the attacks. To fill in the gaps, this document
defines some new IPFIX IEs and describes their formats for
inspecting network security.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document ........................... 3
2.1. Terminology ............................................ 3
3. Connection Sampling and new IEs ............................. 4
3.1. Packet Sampling vs Connection Sampling ................. 4
3.2. Use Cases for New IEs .................................. 5
3.2.1. Upstream/Downstream Counters ...................... 5
3.2.2. Fragment statistic ................................ 5
3.2.3. Extended Value of FlowEndReason ................... 6
3.3. Definition of New IEs .................................. 6
4. Application of the New IEs for Attack Detection ............ 12
4.1. Use of Upstream/Downstream Counters to Detect ICMP Attack12
4.2. Fragment Attack ....................................... 14
5. Security Considerations .................................... 15
6. IANA Considerations ........................................ 15
7. References ................................................. 20
7.1. Normative References .................................. 20
7.2. Informative References ................................ 20
8. Acknowledgments ............................................ 20
Fu, et al. Expires April 19, 2016 [Page 2]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
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.
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 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 a number of
categories of the attacks. The scanty information will result in an
inaccurate analysis and slowing down the effective response towards
network attacks. More detailed gap analysis is given in the
following section.
This document presents the IPFIX IEs which are available for the
network attacks detection, some of them are the new defined IPFIX
IEs and their formats are specified. The wise utilization of these
IEs will improve the network security and will support the offline
analysis of data from different operators in the future with minimal
resource consumption.
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,
Fu, et al. Expires April 19, 2016 [Page 3]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
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.
3. Connection Sampling and new IEs
3.1. Packet Sampling vs Connection Sampling
Packet sampling is a widely used method to select packets from
network traffic for reporting. Its selection operations include
random selection, deterministic selection, hash-based selection and
so on. Although it is easy and efficient, it still has a number of
limitations:
o Several research projects [N. DUFFIELD, 2003], [D. BRAUCKHOFF
2006] show that packet sampling impacts larger on small flows
(with only few packets) due to the smaller sampling probability
compared to larger flows, unfortunately attacks such as SYN-Flood,
ACK-Flood all have small flow characteristics, which means that
packet sampling may impair the detection performance for small
flow based DDoS attacks;
o Although the communication is 2-way between source and
destination, current packet sampling is applied independently in
each direction, which leads to difficulties correlating the
statistic of both sides, despite that those metrics are essential
indicators in detecting attacks such as SNMP/DNS Reflected
Amplification (i.e. where there are not much or even no traffic
in the opposite direction of the attacking flow);
o Today's packet sampling cannot provide detailed information of
traffic between communication peers, which makes it impossible to
distinguish some of the attacks, such as IP fragment attack and
Slowloris HTTP attack, from ordinary traffic.
As a consequence from the above analysis, a layer 4 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 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. Furthermore, several new IPFIX
IEs are proposed in this document to represent the telemetry
information that can obtain via this method.
Fu, et al. Expires April 19, 2016 [Page 4]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
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 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 attack happens, a sudden burst of messages
from different sources to a destination endpoint can be detected. In
turn, the ratio between echo and echo reply 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.
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 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.
Similar new IE definitions of pktUpstreamCount, pktDownstreamCount,
octetUpstreamCount, and octetDownstreamCount are applied to the TCP,
UDP, SNMP and DNS attacks.
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
Fu, et al. Expires April 19, 2016 [Page 5]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
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 fragmentIncompleteCount: The completeness of fragmented packets
of the same connection should be checked, and this metric is
proposed to count the incomplete events;
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;
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;
o fragmentFlagErrorCount: This metric is proposed to detect early
whether the fragment flags are incorrectly set on purpose.
3.2.3. 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
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 IEs that a device would need
to export for attack statistic analysis. The formats of the IEs and
Fu, et al. Expires April 19, 2016 [Page 6]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
the IPFIX IDs are listed below, as well as their descriptions. Some
of the IEs are already defined in [IPFIX-IANA]. While a number of
new IE's IDs are not assigned yet, their explanations are presented
in the previous sections. The recommended registrations to IANA are
described in the IANA considerations section.
Fu, et al. Expires April 19, 2016 [Page 7]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
+---------------------------+------------+------+-----------------+
| Field Name | Size (bits)| IANA | Description |
| | | IPFIX| |
| | | ID | |
+---------------------------+------------+------+-----------------+
| sourceIPv4Address | 32 | 8 | Source IPv4 |
| | | | Address |
| destinationIPv4Address | 32 | 12 | Destination |
| | | | IPv4 Address |
| sourceTransportPort | 16 | 7 | Source Port |
| destinationTransportPort | 16 | 11 | Destination |
| | | | port |
| protocolIdentifier | 8 | 4 | Transport |
| | | | protocol |
| packetDeltaCount | 64 | 2 | The number of |
| | | | incoming |
| | | | packets since |
| | | | the previous |
| | | | report (if |
| | | | any) for this |
| | | | Flow at the |
| | | | Observation |
| | | | Point |
| pktUpstreamCount | 64 | TBD | Upstream |
| | | | packet counter |
| pktDownstreamCount | 64 | TBD | Downstream |
| | | | packet counter |
| octetUpstreamCount | 64 | TBD | Upstream octet |
| | | | counter |
| octetDownstreamCount | 64 | TBD | Downstream |
| | | | octet counter |
| tcpSynTotalCount | 64 | 218 | The total |
| | | | number of |
| | | | packets of |
| | | | this Flow with |
| | | | TCP |
| | | | "Synchronize |
| | | | sequence |
| | | | numbers" (SYN) |
| | | | flag set |
| tcpFinTotalCount | 64 | 219 | The total |
| | | | number of |
| | | | packets of |
| | | | this Flow with |
| | | | TCP "No more |
| | | | data from |
| | | | sender" (FIN) |
Fu, et al. Expires April 19, 2016 [Page 8]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
| | | | flag set |
| tcpRstTotalCount | 64 | 220 | The total |
| | | | number of |
| | | | packets of |
| | | | this Flow with |
| | | | TCP "Reset the |
| | | | connection" |
| | | | (RST) flag |
| | | | set. |
| tcpPshTotalCount | 64 | 221 | The total |
| | | | number of |
| | | | packets of |
| | | | this Flow with |
| | | | TCP "Push |
| | | | Function" |
| | | | (PSH) flag |
| | | | set. |
| tcpAckTotalCount | 64 | 222 | The total |
| | | | number of |
| | | | packets of |
| | | | this Flow with |
| | | | TCP "Acknowled |
| | | | gment field |
| | | | significant" |
| | | | (ACK) flag |
| | | | set. |
| tcpUrgTotalCount | 64 | 223 | The total |
| | | | number of |
| | | | packets of |
| | | | this Flow with |
| | | | TCP "Urgent |
| | | | Pointer field |
| | | | significant" |
| | | | (URG) flag |
| | | | set. |
| tcpControlBits | 8 | 6 | TCP control |
| | | | bits observed |
| | | | for packets of |
| | | | this Flow |
| flowEndReason | 8 | 136 | The reason for |
| | | | Flow |
| | | | termination |
| minimumIpTotalLength | 64 | 25 | Length of the |
| | | | smallest |
| | | | packet |
| | | | observed for |
| | | | this Flow |
Fu, et al. Expires April 19, 2016 [Page 9]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
| maximumIpTotalLength | 64 | 26 | Length of the |
| | | | largest packet |
| | | | observed for |
| | | | this Flow |
| flowStartSeconds | dateTimeSec| 150 | The absolute |
| | nds | | timestamp of |
| | | | the first |
| | | | packet of this |
| | | | Flow |
| flowEndSeconds | dateTimeSec| 151 | The absolute |
| | nds | | timestamp of |
| | | | the last |
| | | | packet of this |
| | | | Flow |
| flowStartMilliseconds | dateTimeMil| 152 | The absolute |
| | iseconds | | timestamp of |
| | | | the first |
| | | | packet of this |
| | | | Flow |
| flowEndMilliseconds | dateTimeMil| 153 | The absolute |
| | iseconds | | timestamp of |
| | | | the last |
| | | | packet of this |
| | | | Flow |
| flowStartMicroseconds | dateTimeMic| 154 | The absolute |
| | oseconds | | timestamp of |
| | | | the first |
| | | | packet of this |
| | | | Flow |
| flowEndMicroseconds | dateTimeMic| 155 | The absolute |
| | oseconds | | timestamp of |
| | | | the last |
| | | | packet of this |
| | | | Flow |
| fragmentFlags | 8 | 197 | Fragmentation |
| | | | properties |
| | | | indicated by |
| | | | flags in the |
| | | | IPv4 packet |
| | | | header or the |
| | | | IPv6 Fragment |
| | | | header, |
| | | | respectively |
| fragmentPacketDeltaCount | 32 | TBD | Counter of |
| | | | session |
| | | | fragments |
| fragmentFirstTooShort | 32 | TBD | Number of |
Fu, et al. Expires April 19, 2016 [Page 10]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
| DeltaCount | | | packets with |
| | | | first fragment |
| | | | too short |
| fragmentFlagError | 32 | TBD | Number of |
| DeltaCount | | | fragments with |
| | | | flag error |
| icmpTypeIPv4 | 8 | 176 | Type of the |
| | | | IPv4 ICMP |
| | | | message |
| icmpCodeIPv4 | 8 | 177 | Code of the |
| | | | IPv4 ICMP |
| | | | message |
| icmpTypeIPv6 | 8 | 178 | Type of the |
| | | | IPv6 ICMP |
| | | | message |
| icmpCodeIPv6 | 8 | 179 | Code of the |
| | | | IPv6 ICMP |
| | | | message |
| icmpEchoDeltaCount | 32 | TBD | The number fo |
| | | | ICMP echo. |
| icmpEchoReplyDeltaCount | 32 | TBD | The number of |
| | | | ICMP echo |
| | | | reply. |
| selectorAlgorithm | 16 | 304 | This |
| | | | Information |
| | | | Element |
| | | | identifies the |
| | | | packet |
| | | | selection |
| | | | methods (e.g., |
| | | | Filtering, |
| | | | Sampling) that |
| | | | are applied by |
| | | | the Selection |
| | | | Process. |
| samplingPacketInterval | 32 | 305 | The number of |
| | | | packets that |
| | | | are |
| | | | consecutively |
| | | | sampled |
| samplingPacketSpace | 32 | 306 | The number of |
| | | | packets |
| | | | between two "s |
| | | | amplingPacketI |
| | | | nterval"s. |
|octetVariance | 64 | TBD |IP packet byte |
| | | |variance |
Fu, et al. Expires April 19, 2016 [Page 11]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
| | | |statistic |
|tcpControlStateBits | 16 | TBD |tcp states |
|flowSessionEndMilliseconds | 64 | TBD |the absolute |
| | | |timestamp of the |
| | | |first FIN or RST |
| | | |packet of this |
| | | |Flow |
|tcpPayloadOctetTotalCount | 64 | TBD |tcp payload |
| | | |statistics, it |
| | | |is equal to |
| | | |the ACK's window |
| | | |value subtract |
| | | |INIT's window |
| | | |value |
|tcpOutoforderTotalCount | 64 | TBD |out of order |
| | | |packets statistic|
|flowTimeIntervalVariance | 64 | TBD |the interval time|
| | | |variance between |
| | | |upstream and |
| | | |downstream |
| | | |traffic of a flow|
|flowTimeInterval | 64 | TBD |the interval time|
| | | |between |
| | | |upstream and |
| | | |downstream |
| | | |traffic of a flow|
|serverResponseTime | 64 | TBD |the response time|
| | | |of a server |
|clientResponseTime | 64 | TBD |the response time|
| | | |of a client |
|sessionResponseTime | 64 | TBD |the response time|
| | | |of a session |
+---------------------------+------------+------+-----------------+
Table 1: Information Element Table
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. Use of Upstream/Downstream Counters to Detect ICMP Attack
According to previous analysis, the template for detecting ICMP
attack should at least contain IEs shown in Table 2.
Fu, et al. Expires April 19, 2016 [Page 12]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 24 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| protocolIdentifier | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetDeltaCount | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| pktUpstreamCount | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| pktDownstreamCount | 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 = 2880, icmpEchoRelayCount = 120, flowStartSeconds
= 100, flowEndSeconds = 200}
protocolIdentifier = 1 represents the ICMP proptocol. There are 30
ICMP messages transmited per second. Tthe ICMP Echo to ICMP Echo
Reply packet ratio is 24:1, which indicates a high possibility of
ICMP attack.
Fu, et al. Expires April 19, 2016 [Page 13]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
4.2. 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 = 24 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID TBD | Field Count = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| fragmentIncompleteCount | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| fragmentFirstTooShortCount| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| fragmentOffestErrorCount | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| fragmentFlagErrorCount | 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 = 1,fragmentIncompleteCount = 0,
fragmentFirstTooShortCount = 0, fragmentOffestErrorCount = 3000,
fragmentFlagErrorCount = 0, flowStartSeconds = 100,
flowEndSeconds = 200}
In this case, fragment offset errors are used to exhaust resource at
the receiver.
Fu, et al. Expires April 19, 2016 [Page 14]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
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 : pktUpstreamCount
Description: The number of the upstream packets for this Flow at
the Observation Point since the Metering Process (re-
)initialization for this Observation Point.
Abstract Data Type: unsigned64
Data Type Semantics: TBD
Name: pktDownstreamCount
Description: The number of the downstream packets for this Flow
at the Observation Point since the Metering Process (re-
)initialization for this Observation Point.
Abstract Data Type: unsigned64
Data Type Semantics: TBD
Name: octetUpstreamCount
Description: The total number of octets in upstream packets for
this Flow at the Observation Point since the Metering Process
(re-)initialization for this Observation Point. The number of
octets includes IP header(s) and IP payload.
Abstract Data Type: unsigned64
Data Type Semantics: TBD
Fu, et al. Expires April 19, 2016 [Page 15]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
Name : octetDownstreamCount
Description: The total number of octets in downstream packets for
this Flow at the Observation Point since the Metering Process
(re-)initialization for this Observation Point. The number of
octets includes IP header(s) and IP payload.
Abstract Data Type: unsigned64
Data Type Semantics: TBD
Name: fragmentPacketDeltaCount
Description: This Information Element is the counter of session
fragments.
Abstract Data Type: unsigned32
Data Type Semantics: TBD
Name: fragmentFirstTooShortDeltaCount
Description: This Information Element indicates the number of
packets with first fragment too short.
Abstract Data Type: unsigned32
Data Type Semantics: TBD
Name: fragmentFlagErrorDeltaCount
Description: This Information Element specifies number of
fragments with offset 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
Fu, et al. Expires April 19, 2016 [Page 16]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
Name: octetVariance
Description: IP packet byte variance statistic.
Abstract Data Type: unsigned64
Data Type Semantics: quantity
Name: tcpControlStateBits
Description: tcp states.
Abstract Data Type: unsigned16
Data Type Semantics: flags
Name: icmpEchoDeltaCount
Description: icmp Echo packets.
Abstract Data Type: unsigned32
Data Type Semantics: deltaCounter
Name: icmpEchoReplyDeltaCount
Description: icmp Echo Reply packets.
Abstract Data Type: unsigned32
Data Type Semantics: deltaCounter
Name: flowSessionEndMilliseconds
Description: the absolute timestamp of the first FIN or RST
packet of this flow.
Abstract Data Type: dateTimeMilliseconds
Fu, et al. Expires April 19, 2016 [Page 17]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
Data Type Semantics: default
Name: tcpPayloadOctetTotalCount
Description: tcp payload statistics, it is equal to the ACK's
window value subtract INIT's window value.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
Name: tcpOutoforderTotalCount
Description: out of order packets statistic.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
Name: flowTimeIntervalVariance
Description: the interval time variance between upstream and
downstream.
Abstract Data Type: unsigned64
Data Type Semantics: quantity
Name: flowTimeInterval
Description: the interval time between upstream and downstream.
Abstract Data Type: unsigned32
Data Type Semantics: quantity
Name: flowTimeInterval
Fu, et al. Expires April 19, 2016 [Page 18]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
Description: the interval time between upstream and downstream.
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
A new values is added to FlowEndReason:
0x06: protocol exception timeout
The flow was terminated due to protocol state machine anomaly and
unexpected timeout.
Fu, et al. Expires April 19, 2016 [Page 19]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
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.
7.2. Informative References
[IPFIX-IANA]
IANA, "IPFIX Information Elements registry",
<http://www.iana.org/assignments/ipfix>.
[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.
This document was prepared using 2-Word-v2.0.template.dot.
Fu, et al. Expires April 19, 2016 [Page 20]
Internet-Draft IPFIX IE Extensions for DDoS Detection October 2015
Authors' Addresses
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
Min Li
Huawei
Huawei Technologies Duesseldorf GmbH, European Research Center,
Riesstr. 25, 80992 Muchen, Germany
Email: l.min@huawei.com
Fu, et al. Expires April 19, 2016 [Page 21]
