idnits 2.17.1 draft-fu-dots-ipfix-extension-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 8 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 14, 2016) is 2873 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC791' is mentioned on line 304, but not defined == Unused Reference: 'RFC5476' is defined on line 804, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-ietf-dots-use-cases' is defined on line 825, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3917 ** Downref: Normative reference to an Informational RFC: RFC 5474 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DOTS T. Fu 2 Internet Draft Huawei 3 Intended status: Standard Track D. Zhang 4 Expires: Nov 2016 Alibaba 5 L. Xia 6 M. Li 7 Huawei 8 June 14, 2016 10 IPFIX IE Extensions for DDoS Attack Detection 11 draft-fu-dots-ipfix-extension-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 This document may contain material from IETF Documents or IETF 19 Contributions published or made publicly available before November 20 10, 2008. The person(s) controlling the copyright in some of this 21 material may not have granted the IETF Trust the right to allow 22 modifications of such material outside the IETF Standards Process. 23 Without obtaining an adequate license from the person(s) controlling 24 the copyright in such materials, this document may not be modified 25 outside the IETF Standards Process, and derivative works of it may 26 not be created outside the IETF Standards Process, except to format 27 it for publication as an RFC or to translate it into languages other 28 than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as 38 reference material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on December 14, 201616. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. 59 Abstract 61 DDoS Open Threat Signaling (DOTS) Working Group is for developing 62 the standard signaling mechanisms, together with the DDoS related 63 telemetry and threat handling requests and data transmitted by them 64 used in DDoS problem space. Although IP Flow Information Export 65 (IPFIX), Packet Sampling (PSAMP), and Packet Selection methods are 66 useful for network security inspection, there are still some gaps 67 existing to identify some categories of DDoS attacks. To fill in 68 the gaps, this document describes the connection sampling mechanism 69 and explains why it is needed for detecting DDoS attacks. It also 70 defines several new IPFIX Information Elements (IEs). Then, it 71 presents some examples to show how to use these new IPFIX IEs 72 together with the existing IPFIX IEs to detect specific DDoS attacks. 74 Table of Contents 76 1. Introduction ................................................ 3 77 2. Conventions used in this document............................ 4 78 2.1. Terminology ............................................ 4 79 3. Connection Sampling and new IEs.............................. 5 80 3.1. Packet Sampling vs Connection Sampling ..................5 81 3.2. Use Cases for New IEs................................... 6 82 3.2.1. Upstream/Downstream Counters .......................6 83 3.2.2. Fragment statistic................................. 7 84 3.2.3. Response Time Calculation ..........................8 85 3.2.4. Symptoms of Exceptions............................. 8 86 3.2.5. Extended Value of FlowEndReason ....................9 87 3.3. Definition of New IEs.................................. 10 88 4. Application of the New IEs for Attack Detection .............12 89 4.1. Detect ICMP Reflection Attack.......................... 12 90 4.2. Detect Fragment Attack................................. 13 91 4.3. Detect Slowloris Attack................................ 14 92 4.4. Detect Out-of-order Packets Attack .....................15 93 5. Security Considerations..................................... 15 94 6. IANA Considerations ........................................ 15 95 7. References ................................................. 19 96 7.1. Normative References................................... 19 97 7.2. Informative References................................. 19 98 8. Acknowledgments ............................................ 20 100 1. Introduction 102 As network security issues arising dramatically nowadays, network 103 administrators are eager to detect and identify attacks as early as 104 possible, generate countermeasures with high agility. Due to the 105 enormous amount of network attack types, metrics useful for attack 106 detection are also enormous. Moreover, attacking methods are 107 evolved rapidly, which brings challenges to designing detection 108 mechanism. 110 Specifically, DOTS WG aims for developing the standard solution to 111 fight against the DDoS attacks. The following sentence is from the 112 DOTS WG charter: 114 "The aim of DDoS Open Threat Signaling (DOTS) is to develop a 115 standards based approach for the realtime signaling of DDoS related 116 telemetry and threat handling requests and data between elements 117 concerned with DDoS attack detection, classification, traceback, and 118 mitigation." 120 According to the above sentence, the signaling mechanisms and 121 contents are all the essential parts of the solution, in which the 122 contents refer to the realtime DDoS related telemetry information 123 and threat handling messages. 125 The IPFIX Protocol [RFC7011] defines a generic exchange mechanism 126 for flow information and events. It supports source-triggered 127 exporting of information via the push model approach. The IPFIX 128 Information Model [IPFIX-IANA] defines a list of standard 129 Information Elements (IEs) which can be carried by the IPFIX 130 protocol. The IPFIX requirement [RFC3917] points out that one of 131 the target applications of IPFIX is attack and intrusion detection. 132 Although the existing IPFIX/PSAMP protocol, packet selection methods, 133 as well as the related standard IEs provide a rich source of data 134 for security inspection by checking the status/events of the traffic, 135 there are still some gaps existing to identify some categories of 136 the DDoS attacks. More detailed gap analysis is given in the 137 following section. 139 This document focuses on the DDoS related telemetry information part 140 for DOTS, and proposes using the connection sampling method with a 141 set of IPFIX IEs for the goal of inspecting mainly some connection- 142 based and Zero-Day DDoS attacks, which normally are the kinds of the 143 low & slow DDoS attack and not easy to be inspected as flood attacks. 144 Some of these IPFIX IEs already exist; some are the new defined ones 145 with their formats specified. The wise utilization of these IEs will 146 improve the DDoS attack inspection and will support the offline 147 analysis of data from different operators in the future with minimal 148 resource consumption, which is very necessary for increasing the 149 operators' intelligence of identifying new and unknown DDoS attacks. 151 This document is structured as following: Section 3 discusses the 152 connection sampling mechanism and introduces the new IPFIX IEs 153 derived from relevant use cases. Section 4 describes how to use 154 these IEs to detect specific DDoS attacks. 156 2. Conventions used in this document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC-2119 [RFC2119]. 162 2.1. Terminology 164 IPFIX-specific terminology (Information Element, Template, Template 165 Record, Options Template Record, Template Set, Collector, Exporter, 166 Data Record, etc.) used in this document is defined in Section 2 of 167 [RFC7011]. As in [RFC7011], these IPFIX-specific terms have the 168 first letter of a word capitalized. 170 This document also makes use of the same terminology and definitions 171 as [I-D.draft-ietf-dots-requirements] and [I-D.draft-ietf-dots-use- 172 cases]. 174 The following are the new terms in this document. 176 o Connection Sampling 178 Connection Sampling is a connection oriented sampling mechanism. If 179 one connection is selected for DDoS attack detection, then all the 180 packets (if possible) of this connection will be sampled during one 181 detection period. 183 o Victim 185 The target that suffers DDoS attack. 187 o Observer 189 Devices or software deployed at observation point defined in IPFIX. 191 3. Connection Sampling and new IEs 193 3.1. Packet Sampling vs Connection Sampling 195 Packet sampling selection is a widely used method to select packets 196 from network traffic for reporting. Its selection operations include 197 time-based selection, count-based selection, random selection, 198 probability-based selection and so on. Although it is easy and 199 efficient, it still has a number of limitations in inspecting some 200 types of DDoS attack: 202 o Several research projects [N. DUFFIELD, 2003], [D. BRAUCKHOFF 203 2006] show that packet sampling impacts greater on small 204 volumetric flows (with only few packets) due to the smaller 205 sampling probability compared with large volumetric flows, which 206 means that packet sampling may impair the detection performance 207 for small volumetric flow based DDoS attacks; Connection sampling 208 can pay more attention to small flows than packet sampling. 210 o The communication is 2-way between source and destination. 211 Current packet sampling is used to select a subset of packets 212 from all the observed packets. One of its purposes is to select 213 the appropriate packets to estimate the whole traffic. Although 214 packet sampling can produce flows by using property matching or 215 hash method, it does not consider semantics of the connection 216 (i.e. whether two flows are belonging to one connection or not). 217 In this scenario, packet sampling is applied independently in 218 each direction. If packets are sampled only in one direction, 219 then it will be difficult or inaccurate to detect specific DDoS 220 attacks such as SNMP/DNS Reflected Amplification because of the 221 loss of the information in the opposite direction. It cannot 222 distinguish whether there are too much requests from the victim 223 or not. 225 o Although packet sampling at full line rate, i.e. with probability 226 100%, is not excluded in principle, resource constraints may not 227 permit it in practice [RFC5474]. For certain DDoS attack such as 228 HTTP Slowloris, enough packets are needed to realize the 229 detection. In this scenario, connection sampling can provide more 230 meaningful packets than packet sampling because all the packets 231 it samples are belonging to the target connection. 233 o Connection sampling method uses some new connection related IEs 234 for attack analysis because of their meaning/value available for 235 judging the status of one connection, which current packet 236 sampling method is lack of. For example, tcpControlStateBits is 237 an IE to record the current state of TCP session. If a packet 238 with erroneous flag is identified in any stage of three 239 handshakes, it should be considered as a symptom of exception. 241 As a consequence from the above analysis, a connection oriented 242 sampling method is more suitable for the security application: 243 Rather than sampling a small part of packets in the traffic between 244 the communication peers, the connection sampling records all (if 245 possible) TCP/UDP connection packets (including packets during 246 connection setup and close phase if there is) between them once that 247 connection is selected to be sampled. In nature, the connection 248 sampling method is able to track the complete working status of the 249 connection state machine. So, it can identify the abnormal state of 250 the connection or the attack easily and accurately. Although the 251 IPFIX/PSAMP also supports the connection sampling mechanism (that is 252 the packet filtering technology for packet selection [RFC5475]), it 253 does not explicitly discuss how to use this method for the detection 254 of connection-based and Zero-Day DDoS attacks in a systematical way. 255 Furthermore, if the observer (e.g. device, middle box) supports the 256 export of the new IPFIX IEs proposed in this document, the traffic 257 volume between exporter and analyzer can be greatly reduced compared 258 with PSAMP, which should export the detailed packet information for 259 further attack analysis. 261 3.2. Use Cases for New IEs 263 In this section, several use cases are discussed to identify the 264 requirements where new IEs are desirable for the network attacks 265 detection. 267 3.2.1. Upstream/Downstream Counters 269 Take ICMP reflection attack as an example, ICMP flow model has 270 features such as the ICMP Echo/Echo Reply dominate the whole traffic 271 flow, ICMP packet interval is usually not too short (normally 1 272 pkt/s). Usually, the normal ratio between ICMP echo to ICMP echo 273 reply packets is around 1:1. When a DDOS reflection attack happens, 274 a sudden burst of messages to a destination endpoint can be detected. 275 In turn, the ratio between echo reply and echo packets will be 276 significantly biased from the normal ratio, i.e., exceed 20:1. So 277 the proper way to distinguish an attack from the normal 278 communication is to check this ratio. 280 However, the current IPFIX IEs for ICMP contain the ICMP type and 281 code for both IPv4 and IPv6 only for a single ICMP packet rather 282 than statistical property of the ICMP session. Further metrics like 283 the cumulated sum of various counters should be calculated based on 284 sampling method defined by the Packet SAMPling (PSAMP) protocol 285 [RFC5477]. Similar problems occur in TCP, UDP, SNMP and DNS attacks. 286 It would be useful to calculate the number of the upstream and 287 downstream packets for one connection separately over time in order 288 to detect the anomalies of the network. For ICMP reflection attack, 289 a more generic approach is to define two basic metrics icmpEchoCount 290 and icmpEchoReplyCount as new IPFIX IEs to represent the cumulated 291 upstream and downstream packets counter within a ICMP connection. 293 Note that in some case, the asymmetric routing mainly caused by the 294 wide application of multipath technologies (e.g., load balancing, 295 link aggregation) in network will make the bidirectional connection 296 sampling on some network devices over the multipath to be not 297 possible. This problem can be avoided by strategically deploying and 298 enabling the connection sampling function in the network devices 299 which are not located over the multipath. 301 3.2.2. Fragment statistic 303 Fragment attack employs unexpected formats of fragmentation, e.g. 304 without last fragment or incorrect fragment offset[RFC791], which 305 result in errors such as fragmentation buffer overrun and fragment 306 overlapped. Existing IPFIX fragmentation metrics includes 307 fragmentOffset, fragmentIdentification, fragmentFlags, which only 308 indicate the attributes of a single fragment, and are not suitable 309 for attack detection. Instead, the network attack should be observed 310 based upon a historic, integrated view of fragmented packets of a 311 connection. For instances, if more than 500 out of 1000 fragmented 312 packets have fragment errors, it is likely that a fragment attack 313 happens. 315 Therefore, a number of new IEs associated with fragment statistics 316 are proposed as follows: 318 o fragmentPacketCount: The number of the fragmented packets of the 319 same connection should be checked, and this metric is proposed; 321 o fragmentFirstTooShortCount: Attacker might intent to exclude 322 destination port from the first fragment so as to bypass 323 detection from firewall. This metric is proposed to indicate the 324 number of the invalid first fragments in the observed connection; 326 o fragmentFlagErrorCount: This metric is proposed to detect early 327 whether the fragment flags are incorrectly set on purpose. 329 o fragmentOffestErrorCount: This metric is proposed to count the 330 number of fragments with offset error, and the value can be used 331 to indicate attack occurs; 333 3.2.3. Response Time Calculation 335 For other DDoS attacks such as Http slowloris, there will be too many 336 connections that should be kept in the victim (server), which lead to 337 excessive resource consumption. As a result, the response time between 338 client and server will increase greatly. Challenge Collapasar(CC) 339 attack can also exhaust the resources of the server and generate the 340 similar results. Thus, the following IEs are proposed as a symptom of 341 these kinds of attacks: 343 serverResponseTime: For tcp, it denotes the time difference 344 between the time point that the observer views the SYN packet from 345 client to server and the time point that the observer views the 346 SYN-ACK packet from server to client. 348 clientResponseTime: For tcp, it denotes the time difference 349 between the time point that the observer views the SYN-ACK packet 350 from server to client and the time point that the observer views 351 the ACK packet from client to server. 353 sessionResponseTime: The sum of serverResponseTime and 354 clientResponseTime. It is the Round Trip Time (RTT) between client 355 and server. 357 3.2.4. Symptoms of Exceptions 359 In http slowloris attack the client may send packets to victim 360 periodically which can cause the performance lost on the server. The 361 characteristic of the attack is that there are too many connections 362 on the victim. However, the volume for these connections is small. 363 In order to detect this attack, the first step is to get the packets 364 that are belonging to the same connection. The second step is to 365 find the periodicity. Thus the two indices pktTimeInterval and 366 pktTimeIntervalVariance are needed. The index pktTimeInterval 367 denotes the average time difference between two successive packets 368 and the index pktTimeIntervalVariance denotes the variance of 369 multiple time difference. Large pktTimeInterval and small 370 pktTimeIntervalVariance can be a symptom of slow packet attack. On 371 the other hand, the payload size of the packets in http slowloris 372 attack is very small and the size difference is also small. So the 373 index octetVariance can be used to identify the characteristic. 375 To degrade the performance of the victim, the malicious clients may 376 send too many out-of-order packets, which will consume too much 377 memory on the server. Although out-of-order packets are permit in 378 the TCP protocol, it is possible to be leveraged to cause DDoS 379 attack. So the index tcpOutoforderTotalCount is helpful to detect 380 this kind of exception. For observer, it maintains one counter for 381 each tcp connection. The initial sequence number of the client is 382 saved in the counter. The counter increases by the sequence number 383 of the packets it sees from client to server. If the observer sees a 384 packet with lower sequence number than the current counter value, 385 then the packet will be considered as an out-of-order packet. 387 In IPFIX, the index tcpControlBits is used to record the 388 corresponding status bits in TCP header of the packets[IPFIX-IANA]. 389 In order to detect the application attacks which can cause the 390 protocol exception such as the wrong use of the tcp status bits 391 before and after the tcp connection establishment, another index 392 called tcpControlStateBits is needed. For example, when the observer 393 sees the SYN packet from client to server, it sets 15th bit of 394 tcpControlStateBits to 1; when it sees the SYN-ACK packet from 395 server to client, it sets 14th bit to 1, and so on. If one endpoint 396 sends the packet with wrong bits during the establishment of the 397 connection, then the observer will identify the exception by the 398 value of tcpControlStateBits. 400 3.2.5. Extended Value of FlowEndReason 402 Refer to [IPFIX-IANA], there are 5 defined reasons for Flow 403 termination, with values ranging from 0x01 to 0x05: 405 0x01: idle timeout 407 0x02: active timeout 409 0x03: end of Flow detected 411 0x04: forced end 413 0x05: lack of resources 415 There is an additional reason caused by state machine anomaly. When 416 FIN/SYN is sent, but no ACK is replied after a waiting timeout, the 417 existing five reasons do not match this case. Therefore, a new value 418 is proposed to extend the FlowEndReason, which is 0x06: protocol 419 exception timeout. 421 3.3. Definition of New IEs 423 The following is the table of all the new IEs that a device would 424 need to export for attack statistic analysis. The recommended 425 registrations to IANA are described in the IANA considerations 426 section. 428 +---------------------------+------------+------+-----------------+ 429 | Field Name | Size (bits)| IANA | Description | 430 | | | IPFIX| | 431 | | | ID | | 432 +---------------------------+------------+------+-----------------+ 433 | fragmentPacketCount | 32 | TBD | Counter of | 434 | | | | session | 435 | | | | fragments | 436 | fragmentFirstTooShortCount| 32 | TBD | Number of | 437 | | | | packets with | 438 | | | | first fragment | 439 | | | | too short | 440 | fragmentFlagErrorCount | 32 | TBD | Number of | 441 | | | | fragments with | 442 | | | | erroneous flag | 443 | fragmentOffsetErrorCount | 32 | TBD | Number of | 444 | | | | fragments with | 445 | | | | erroneous offset| 446 | | | | | 447 | icmpEchoCount | 32 | TBD | The number of | 448 | | | | ICMP echo. | 449 | icmpEchoReplyCount | 32 | TBD | The number of | 450 | | | | ICMP echo | 451 | | | | reply | 452 | | | | | 453 | octetVariance | 64 | TBD |IP packet byte | 454 | | | |variance | 455 | | | |statistic | 456 |tcpControlStateBits | 16 | TBD |tcp states | 457 |tcpOutoforderTotalCount | 64 | TBD |out of order | 458 | | | |packets statistic| 459 | | | | | 460 |pktTimeInterval | 64 | TBD |the average time | 461 | | | |interval between | 462 | | | |two successive | 463 | | | |packets | 464 |pktTimeIntervalVariance | 64 | TBD |the variance of | 465 | | | |pktTimeInterval | 466 | | | | | 467 |serverResponseTime | 16 | TBD |the response time| 468 | | | |of a server | 469 |clientResponseTime | 16 | TBD |the response time| 470 | | | |of a client | 471 |sessionResponseTime | 16 | TBD |the response time| 472 | | | |of a session | 473 +---------------------------+------------+------+-----------------+ 474 Table 1: Information Element Table 476 4. Application of the New IEs for Attack Detection 478 This section presents a number of examples to help for the easy 479 understanding of the application of these new IEs for attack 480 detection. 482 4.1. Detect ICMP Reflection Attack 484 According to previous analysis, the template for detecting ICMP 485 reflection attack should at least contain IEs shown in Table 2. 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Set ID = 2 | Length = 40 octets | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Template ID TBD | Field Count = 8 | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 |0| sourceIPv4Address | Field Length = 4 | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 |0| destinationIPv4Address | Field Length = 4 | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 |0| protocolIdentifier | Field Length = 1 | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 |0| packetDeltaCount | Field Length = 8 | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 |0| icmpEchoCount | Field Length = 4 | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 |0| icmpEchoReplyCount | Field Length = 4 | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 |0| flowStartSeconds | Field Length = 4 | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 |0| flowEndSeconds | Field Length = 4 | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Table 2: Template example for detecting ICMP attack 510 An example of the actual ICMP event data record is shown below in 511 a readable form as below: 513 {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 514 192.168.0.201, protocolIdentifier = 1, packetDeltaCount = 3000, 515 icmpEchoCount = 120, icmpEchoReplyCount = 2880, flowStartSeconds 516 = 100, flowEndSeconds = 200} 518 protocolIdentifier = 1 represents the ICMP proptocol. There are 30 519 ICMP messages transmited per second. The ICMP Echo Reply to ICMP 520 Echo packet ratio is 24:1, which indicates a high possibility of 521 ICMP reflection attack. 523 4.2. Detect Fragment Attack 525 The template for detecting fragment attack should at least contain 526 IEs shown in Table 3. It requires the observation point to trace 527 complete fragmented packet and accumulate the errors. 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Set ID = 2 | Length = 48 octets | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Template ID TBD | Field Count = 10 | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 |0| sourceIPv4Address | Field Length = 4 | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 |0| destinationIPv4Address | Field Length = 4 | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 |0| protocolIdentifier | Field Length = 1 | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 |0| packetDeltaCount | Field Length = 8 | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 |0| fragmentPacketCount | Field Length = 4 | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 |0|fragmentFirstTooShortCount | Field Length = 4 | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 |0|fragmentFlagErrorCount | Field Length = 4 | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 |0|fragmentOffsetErrorCount | Field Length = 4 | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 |0| flowStartSeconds | Field Length = 4 | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 |0| flowEndSeconds | Field Length = 4 | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Table 3: Template example for detecting fragment attack 556 An example of the actual fragment attack record is shown below in a 557 readable form as below: 559 {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 560 192.168.0.201, protocolIdentifier = 6, packetDeltaCount = 5000, 561 fragmentPacketCount = 4000, fragmentFirstTooShortCount = 0, 562 fragmentFlagErrorCount = 0, fragmentOffestErrorCount = 3000, 563 flowStartSeconds = 100, flowEndSeconds = 200} 565 In this case, fragment offset errors are used to exhaust resource at 566 the receiver. 568 4.3. Detect Slowloris Attack 570 The template for detecting resource exhausting application attack 571 such as http slowloris attack should contain a subnet of IEs shown 572 in Table 4. 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Set ID = 2 | Length = 48 octets | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Template ID TBD | Field Count = 10 | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 |0| sourceIPv4Address | Field Length = 4 | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 |0| destinationIPv4Address | Field Length = 4 | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 |0| protocolIdentifier | Field Length = 1 | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 |0| serverResponseTime | Field Length = 2 | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 |0| clientResponseTime | Field Length = 2 | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 |0| sessionResponseTime | Field Length = 2 | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 |0| pktTimeInterval | Field Length = 4 | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 |0| pktTimeIntervalVariance | Field Length = 4 | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 |0| flowStartSeconds | Field Length = 4 | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 |0| flowEndSeconds | Field Length = 4 | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 Table 4: Template example for detecting slowloris attack 601 An example of the actual record is shown below in a readable form as 602 below: 604 {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 605 192.168.0.201, protocolIdentifier = 6, serverResponseTime = 200, 606 clientResponseTime = 10, sessionResponseTime = 210, pktTimeInterval 607 = 500, pktTimeIntervalVariance = 1000, flowStartSeconds = 100, 608 flowEndSeconds = 200} 610 4.4. Detect Out-of-order Packets Attack 612 The template for detecting out-of-order packets attack should 613 contain IEs shown in Table 5. 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Set ID = 2 | Length = 32 octets | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Template ID TBD | Field Count = 10 | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 |0| sourceIPv4Address | Field Length = 4 | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 |0| destinationIPv4Address | Field Length = 4 | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 |0| protocolIdentifier | Field Length = 1 | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 |0| packetDeltaCount | Field Length = 8 | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 |0| tcpOutoforderTotalCount | Field Length = 4 | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 |0| flowStartSeconds | Field Length = 4 | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 |0| flowEndSeconds | Field Length = 4 | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Table 5: Template example for detecting out-of-order attack 636 An example of the actual record is shown below in a readable form as 637 below: 639 {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 640 192.168.0.201, protocolIdentifier = 6, packetDeltaCount =3000, 641 tcpOutoforderTotalCount = 2000, flowStartSeconds = 100, 642 flowEndSeconds = 200} 644 5. Security Considerations 646 No additional security considerations are introduced in this 647 document. The same security considerations as for the IPFIX protocol 648 [RFC7011] apply. 650 6. IANA Considerations 652 The following information elements are requested from IANA IPFIX 653 registry. 655 Name: fragmentPacketCount 657 Description: This Information Element is the counter of session 658 fragments. 660 Abstract Data Type: unsigned32 662 Data Type Semantics: TBD 664 Name: fragmentFirstTooShortCount 666 Description: This Information Element indicates the number of 667 packets with first fragment too short. 669 Abstract Data Type: unsigned32 671 Data Type Semantics: TBD 673 Name: fragmentFlagErrorCount 675 Description: This Information Element specifies number of 676 fragments with flag error. When the DF bit and MF bit of the 677 fragment flag are set in the same fragment, there is an error at 678 the fragment flag. 680 Abstract Data Type: unsigned32 682 Data Type Semantics: TBD 684 Name: fragmentOffsetErrorCount 686 Description: This Information Element specifies number of 687 fragments with offset error. 689 Abstract Data Type: unsigned32 691 Data Type Semantics: TBD 693 Name: icmpEchoCount 695 Description: icmp Echo packets. 697 Abstract Data Type: unsigned32 699 Data Type Semantics: deltaCounter 701 Name: icmpEchoReplyCount 703 Description: icmp Echo Reply packets. 705 Abstract Data Type: unsigned32 707 Data Type Semantics: deltaCounter 709 Name: octetVariance 711 Description: IP packet byte variance statistic. 713 Abstract Data Type: unsigned64 715 Data Type Semantics: quantity 717 Name: tcpControlStateBits 719 Description: the current tcp states of the connection. 721 Abstract Data Type: unsigned16 723 Data Type Semantics: flags 725 Name: tcpOutoforderTotalCount 727 Description: out of order packets statistic. 729 Abstract Data Type: unsigned64 731 Data Type Semantics: totalCounter 733 Name: pktTimeInterval 734 Description: the average time interval between two successive 735 packets in a flow. 737 Abstract Data Type: unsigned32 739 Data Type Semantics: quantity 741 Name: pktTimeIntervalVariance 743 Description: the variance of the time intervals between two 744 successive packets in a flow. 746 Abstract Data Type: unsigned64 748 Data Type Semantics: quantity 750 Name: serverResponseTime 752 Description: the response time of a server. 754 Abstract Data Type: unsigned16 756 Data Type Semantics: quantity 758 Name: clientResponseTime 760 Description: the response time of a client. 762 Abstract Data Type: unsigned16 764 Data Type Semantics: quantity 766 Name: sessionResponseTime 768 Description: the response time of a session. 770 Abstract Data Type: unsigned16 772 Data Type Semantics: quantity 773 A new value is added to FlowEndReason: 775 0x06: protocol exception timeout 777 The flow was terminated due to protocol state machine anomaly and 778 unexpected timeout. 780 7. References 782 7.1. Normative References 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, March 1997. 787 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification 788 of the IP Flow Information Export (IPFIX) Protocol for the 789 Exchange of Flow Information", STD 77, RFC 7011, September 790 2013. 792 [RFC3917] Quittek, J., Zseby, T., Claise, B., Zander, S., 793 "Requirements for IP Flow Information Export (IPFIX)", RFC 794 3917, October 2004. 796 [RFC5474] N. Duffield Ed., D. Chiou, B. Claise, A. Greenberg, M. 797 Grossglauser, J. Rexford, "A Framework for Packet 798 Selection and Reporting", RFC 5474, March 2009. 800 [RFC5475] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. 801 Raspall, "Sampling and Filtering Techniques for IP Packet 802 Selection", RFC 5475, March 2009. 804 [RFC5476] B. Claise, Ed., A. Johnson, J. Quittek, "Packet Sampling 805 (PSAMP) Protocol Specifications", RFC 5476, March 2009. 807 [RFC5477] T. Dietz, B. Claise, P. Aitken, F. Dressler, G. Carle, " 808 Information Model for Packet Sampling Exports ", RFC 5477, 809 March 2009. 811 7.2. Informative References 813 [IPFIX-IANA] 815 IANA, "IPFIX Information Elements registry", 817 . 819 [I-D.draft-ietf-dots-requirements] 821 Mortensen, A., Moskowitz, R., Reddy, T., "DDoS Open 822 Threat Signaling Requirements", work in progress, 823 October, 2015. 825 [I-D.draft-ietf-dots-use-cases] 827 Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., 828 Teague, N., Xia, L., " Use cases for DDoS Open Threat 829 Signaling", work in progress, October, 2015. 831 [D. BRAUCKHOFF 2006] 833 Daniela Brauckhoff, Bernhard Tellenbach, Arno Wagner, 834 Martin May, and Anukool Lakhina. 2006. Impact of packet 835 sampling on anomaly detection metrics. In Proceedings of 836 the 6th ACM SIGCOMM conference on Internet measurement 837 (IMC '06). ACM, New York, NY, USA, 159-164. 839 [N. DUFFIELD, 2003] 841 DUFFIELD, N., LUND, C., AND THORUP, M., Estimating Flow 842 Distributions from Sampled Flow Statistics. In ACM SIGCOMM 843 (Karlsruhe, August 2003). 845 8. Acknowledgments 847 The authors would thank Danping He and Yibo Zhang for their great 848 help during the initial period of this draft. 850 The authors would also thank Tienan Wang for his explain about the 851 implementation of DDoS attack solutions. 853 This document was prepared using 2-Word-v2.0.template.dot. 855 Authors' Addresses 856 Tianfu Fu 857 Huawei 858 Q11, Huanbao Yuan, 156 Beiqing Road, Haidian District 859 Beijing 100095 860 China 862 Email: futianfu@huawei.com 864 DaCheng Zhang 865 Alibaba 867 Email: Dacheng.zdc@alibaba-inc.com 869 Liang Xia (Frank) 870 Huawei 872 101 Software Avenue, Yuhuatai District 873 Nanjing, Jiangsu 210012 874 China 876 Email: Frank.xialiang@huawei.com 878 Bo Zhang (Alex) 879 Huawei 881 101 Software Avenue, Yuhuatai District 882 Nanjing, Jiangsu 210012 883 China 885 Email: Alex.zhangbo@huawei.com 887 Min Li 888 Huawei 890 Huawei Technologies Duesseldorf GmbH, European Research Center, 891 Riesstr. 25, 80992 Muchen, Germany 892 Email: l.min@huawei.com