Network Working Group S. Ahn
Internet-Draft M. Park
Intended status: Informational Soongsil University
Expires: June 8, 2019 December 5, 2018

Intentional SYN Drop for mitigation against SYN flooding attacks


This document proposes an option to mitigate SYN flooding attacks, called Intentional SYN Drop (ISD). This option can mitigate the SYN flooding attack by intentionally dropping the first SYN. It also includes a connection management mechanism to detect intelligent attackers who mimic normal clients. Therefore, it can effectively mitigate the SYN flooding DDoS attack.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

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."

This Internet-Draft will expire on June 8, 2019.

Copyright Notice

Copyright (c) 2018 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 ( 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

This document proposes an option to mitigate SYN flooding attacks which drops the first SYN packet of a new TPC session in order to distinguish attack traffic from normal traffic. Unlike a typical reaction of normal clients, i.e., re-transmission of the SYN, attackers are not likely to re-transmit the SYN packet. Therefore, a server does not allocate any resource for the connection for the attack, by which the server can avoid resource exhaustion caused by a lot of half-open connection. In the case that attackers mimic normal clients, a connection management mechanism is also proposed.

2. Terminology

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 [RFC2119].

3. The concept of Intentional SYN Drop

The main idea is based on the straightforward fact, i.e., while normal clients re-transmit a TCP packet when a timeout occurs, attackers do not re-transmit anything. Therefore, nothing happens in a server.

client     Server     Attcker1  Attacker2  Attacker3   Server
  |            |            |          |          |        |
  |SYN         |            |SYN       |          |        |
  |----------->|drop        |----------------------------->|drop
  |---+        |            |          |          |        |
  |   |        |            |          | SYN      |        |
  |timeout     |            |          |------------------>|drop
  |   |        |            |          |          |        |
  |<--+        |            |          |          | SYN    |
  |SYN         |            |          |          |------->|drop
  |----------->|SYN-RCVD    |          |          |        |
  |     SYN,ACK|            |          |          |        |
  |<-----------|            |          |          |        |
  |    ...     |            |          |          |        |
  |    ...     |            |          |          |        |
  |            |            |          |          |        |
  (a) Normal case                  (b) Attack case

Figure 1: Basic concept

4. Intelligent attack

However, intelligent attackers can succeed in a SYN flooding attack if they mimic normal clients. Consider the case that they send two more SYN packets with a certain time interval as if they retransmit the SYN because of a timeout. The server still suffers from a SYN flooding attack.

  Attcker1  Attacker2  Attacker3      Server
	|SYN       |	      |           |
	|          |SYN       |           |
	|          |--------------------->|drop
	|          |          | SYN       |
	|          |          |---------->|dro
	|          |          |           |
	|SYN       |          |           |
	|          |SYN       |           |
	|          |--------------------->|SYN-RCVD
	|          |          | SYN       |
	|          |          |---------->|SYN-RCVD
	|          |          |           |
	|          |          |           |  

Figure 2: Intelligent SYN Flooding Attack

5. Proposed Intentional SYN Drop Mechanism

We need newly added two entities, Dropped SYN List and SYN-RCVD Timer. The connection management mechanism works as shown in Figure 3. When a server receives SYN, it checks if the SYN is a retransmitted SYN with DSL. If so, it records the information of the SYN in DSL, and discards the SYN. On the other hand, if the SYN was re-transmitted, the state of the session becomes SYN_RCVD, and SYN/ACK is sent to the client in a usual handshake way. Then SYN-RCVD_Timer starts. If the SYN-RCVD_Timer expires, the session is removed.

      +-------> |    CLOSED    |<---+  
      |         +--------------+    |
      |           |          A      |
      |           |          |      |       
      |           |          |      |rcv syn & not in DSL(SYN)
      |           |          |      |------------------------
      |	Timer	  V          |      |Discard SYN & Record in DSL       
      | expires +--------------+    |            
      |	-------	|    Listen    | ---+       
      |   x     +--------------+
      |           | rcv syn & in DSL(SYN)
      |           | ---------------------
      |           | snd syn & set timer
      |           V  
      |         +--------------+    
      +---------|   SYN_RCVD   |

Figure 3: Intentional SYN Drop Finite State Machine

5.1. Dropped SYN List

Dropped SYN List (DSL) has the list of the first arrived SYN packets. A server checks if an incoming SYN is the retransmitted SYN with DSL. The record of DSL consists of arrival time, source IP, source port, destination IP, and destination port.

5.2. SYN-RCVD Timer

SYN-RCVD Timer (SRTimer) is used to prevent an intelligent attacker from exhausting server's resource. Because the intelligent attacker, who knows the first SYN is dropped, retransmits SYN like normal users, the TCP session of the server side remains in the SYN-RCVD, which also causes the SYN flooding. To avoid this vulnerability, we utilize the time difference between the first SYN arrival time and the second one. If the first SYN and second SYN arrived at time t1 and t2 respectively, we can expect that ACK from the client should arrive within a(t2-t1), where a is a grace period factor. If ACK does not arrive in the period, we can remove the TCP session of SYN-RCVD. The value of a(grace period factor) may vary depending on network and system conditions.

6. Informative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.

Appendix A. Acknowledgements

This work was supported by Institute for Information & communications Technology Promotion(IITP) grant funded by the Korea government(MSIT) (No.2018-0-00254, SDN security technology development).

Authors' Addresses

Sungwon Ahn School of Electronic Engineering Soongsil University 369, Sangdo-ro, Dongjak-gu Seoul, Seoul 06978 Republic of Korea Phone: +82 2 828 7176 EMail:
Minho Park School of Electronic Engineering Soongsil University 369, Sangdo-ro, Dongjak-gu Seoul, Seoul 06978 Republic of Korea Phone: +82 2 828 7176 EMail: