[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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
             draft-park-tcpm-intentional-syn-drop-option-00

Abstract

   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 https://datatracker.ietf.org/drafts/current/.

   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
   (https://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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of




Ahn & Park                Expires June 8, 2019                  [Page 1]


Internet-Draft            Intentional_SYN_Drop             December 2018


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  The concept of Intentional SYN Drop . . . . . . . . . . . . .   2
   4.  Intelligent attack  . . . . . . . . . . . . . . . . . . . . .   3
   5.  Proposed Intentional SYN Drop Mechanism . . . . . . . . . . .   4
     5.1.  Dropped SYN List  . . . . . . . . . . . . . . . . . . . .   4
     5.2.  SYN-RCVD Timer  . . . . . . . . . . . . . . . . . . . . .   4
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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.











Ahn & Park                Expires June 8, 2019                  [Page 2]


Internet-Draft            Intentional_SYN_Drop             December 2018


   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       |          |           |
           |-------------------------------->|drop
           |          |SYN       |           |
           |          |--------------------->|drop
           |          |          | SYN       |
           |          |          |---------->|dro
           |          |          |           |
           |SYN       |          |           |
           |-------------------------------->|SYN-RCVD
           |          |SYN       |           |
           |          |--------------------->|SYN-RCVD
           |          |          | SYN       |
           |          |          |---------->|SYN-RCVD
           |          |          |           |
           |          |          |           |

                 Figure 2: Intelligent SYN Flooding Attack



Ahn & Park                Expires June 8, 2019                  [Page 3]


Internet-Draft            Intentional_SYN_Drop             December 2018


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



Ahn & Park                Expires June 8, 2019                  [Page 4]


Internet-Draft            Intentional_SYN_Drop             December 2018


   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.







































Ahn & Park                Expires June 8, 2019                  [Page 5]


Internet-Draft            Intentional_SYN_Drop             December 2018


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: swa@ssu.ac.kr


   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: mhp@ssu.ac.kr























Ahn & Park                Expires June 8, 2019                  [Page 6]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/