idnits 2.17.1 draft-park-tcpm-intentional-syn-drop-option-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 date (December 5, 2018) is 1962 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Ahn 3 Internet-Draft M. Park 4 Intended status: Informational Soongsil University 5 Expires: June 8, 2019 December 5, 2018 7 Intentional SYN Drop for mitigation against SYN flooding attacks 8 draft-park-tcpm-intentional-syn-drop-option-00 10 Abstract 12 This document proposes an option to mitigate SYN flooding attacks, 13 called Intentional SYN Drop (ISD). This option can mitigate the SYN 14 flooding attack by intentionally dropping the first SYN. It also 15 includes a connection management mechanism to detect intelligent 16 attackers who mimic normal clients. Therefore, it can effectively 17 mitigate the SYN flooding DDoS attack. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 8, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. The concept of Intentional SYN Drop . . . . . . . . . . . . . 2 56 4. Intelligent attack . . . . . . . . . . . . . . . . . . . . . 3 57 5. Proposed Intentional SYN Drop Mechanism . . . . . . . . . . . 4 58 5.1. Dropped SYN List . . . . . . . . . . . . . . . . . . . . 4 59 5.2. SYN-RCVD Timer . . . . . . . . . . . . . . . . . . . . . 4 60 6. Informative References . . . . . . . . . . . . . . . . . . . 5 61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 This document proposes an option to mitigate SYN flooding attacks 67 which drops the first SYN packet of a new TPC session in order to 68 distinguish attack traffic from normal traffic. Unlike a typical 69 reaction of normal clients, i.e., re-transmission of the SYN, 70 attackers are not likely to re-transmit the SYN packet. Therefore, a 71 server does not allocate any resource for the connection for the 72 attack, by which the server can avoid resource exhaustion caused by a 73 lot of half-open connection. In the case that attackers mimic normal 74 clients, a connection management mechanism is also proposed. 76 2. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 3. The concept of Intentional SYN Drop 84 The main idea is based on the straightforward fact, i.e., while 85 normal clients re-transmit a TCP packet when a timeout occurs, 86 attackers do not re-transmit anything. Therefore, nothing happens in 87 a server. 89 client Server Attcker1 Attacker2 Attacker3 Server 90 | | | | | | 91 |SYN | |SYN | | | 92 |----------->|drop |----------------------------->|drop 93 |---+ | | | | | 94 | | | | | SYN | | 95 |timeout | | |------------------>|drop 96 | | | | | | | 97 |<--+ | | | | SYN | 98 |SYN | | | |------->|drop 99 |----------->|SYN-RCVD | | | | 100 | SYN,ACK| | | | | 101 |<-----------| | | | | 102 | ... | | | | | 103 | ... | | | | | 104 | | | | | | 106 (a) Normal case (b) Attack case 108 Figure 1: Basic concept 110 4. Intelligent attack 112 However, intelligent attackers can succeed in a SYN flooding attack 113 if they mimic normal clients. Consider the case that they send two 114 more SYN packets with a certain time interval as if they retransmit 115 the SYN because of a timeout. The server still suffers from a SYN 116 flooding attack. 118 Attcker1 Attacker2 Attacker3 Server 119 |SYN | | | 120 |-------------------------------->|drop 121 | |SYN | | 122 | |--------------------->|drop 123 | | | SYN | 124 | | |---------->|dro 125 | | | | 126 |SYN | | | 127 |-------------------------------->|SYN-RCVD 128 | |SYN | | 129 | |--------------------->|SYN-RCVD 130 | | | SYN | 131 | | |---------->|SYN-RCVD 132 | | | | 133 | | | | 135 Figure 2: Intelligent SYN Flooding Attack 137 5. Proposed Intentional SYN Drop Mechanism 139 We need newly added two entities, Dropped SYN List and SYN-RCVD 140 Timer. The connection management mechanism works as shown in 141 Figure 3. When a server receives SYN, it checks if the SYN is a 142 retransmitted SYN with DSL. If so, it records the information of the 143 SYN in DSL, and discards the SYN. On the other hand, if the SYN was 144 re-transmitted, the state of the session becomes SYN_RCVD, and SYN/ 145 ACK is sent to the client in a usual handshake way. Then SYN- 146 RCVD_Timer starts. If the SYN-RCVD_Timer expires, the session is 147 removed. 149 +--------------+ 150 +-------> | CLOSED |<---+ 151 | +--------------+ | 152 | | A | 153 | | | | 154 | | | |rcv syn & not in DSL(SYN) 155 | | | |------------------------ 156 | Timer V | |Discard SYN & Record in DSL 157 | expires +--------------+ | 158 | ------- | Listen | ---+ 159 | x +--------------+ 160 | | rcv syn & in DSL(SYN) 161 | | --------------------- 162 | | snd syn & set timer 163 | V 164 | +--------------+ 165 +---------| SYN_RCVD | 166 +--------------+ 168 Figure 3: Intentional SYN Drop Finite State Machine 170 5.1. Dropped SYN List 172 Dropped SYN List (DSL) has the list of the first arrived SYN packets. 173 A server checks if an incoming SYN is the retransmitted SYN with DSL. 174 The record of DSL consists of arrival time, source IP, source port, 175 destination IP, and destination port. 177 5.2. SYN-RCVD Timer 179 SYN-RCVD Timer (SRTimer) is used to prevent an intelligent attacker 180 from exhausting server's resource. Because the intelligent attacker, 181 who knows the first SYN is dropped, retransmits SYN like normal 182 users, the TCP session of the server side remains in the SYN-RCVD, 183 which also causes the SYN flooding. To avoid this vulnerability, we 184 utilize the time difference between the first SYN arrival time and 185 the second one. If the first SYN and second SYN arrived at time t1 186 and t2 respectively, we can expect that ACK from the client should 187 arrive within a(t2-t1), where a is a grace period factor. If ACK 188 does not arrive in the period, we can remove the TCP session of SYN- 189 RCVD. The value of a(grace period factor) may vary depending on 190 network and system conditions. 192 6. Informative References 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", RFC 2119, March 1997. 197 Appendix A. Acknowledgements 199 This work was supported by Institute for Information & communications 200 Technology Promotion(IITP) grant funded by the Korea government(MSIT) 201 (No.2018-0-00254, SDN security technology development). 203 Authors' Addresses 205 Sungwon Ahn 206 School of Electronic Engineering 207 Soongsil University 208 369, Sangdo-ro, Dongjak-gu 209 Seoul, Seoul 06978 210 Republic of Korea 212 Phone: +82 2 828 7176 213 EMail: swa@ssu.ac.kr 215 Minho Park 216 School of Electronic Engineering 217 Soongsil University 218 369, Sangdo-ro, Dongjak-gu 219 Seoul, Seoul 06978 220 Republic of Korea 222 Phone: +82 2 828 7176 223 EMail: mhp@ssu.ac.kr