Loading ...
Sorry, an error occurred while loading the content.

a question about SYN attack

Expand Messages
  • william Li
    Hi Folks: I want through the archive, and find out the summary about the SYN flood attack from David Borman. Unfortunately his summary(src) URL:
    Message 1 of 9 , Oct 12, 1999
    • 0 Attachment
      Hi Folks:

      I want through the archive, and find out the summary
      about the SYN flood attack from David Borman. Unfortunately
      his summary(src) URL:

      ftp://ftp.bsdi.com/contrib/bsdi_contrib/44Lite-SYNcache.gz)

      is not accessible anymore and his e-mail dab@... can
      not be reached either.

      Is there an RFC for this problem ?
      Is there any solution (src) available ?

      Very appreciated your help.
    • Zachary Amsden
      One discussion of SYN attacks is found below: ftp://koobera.math.uic.edu/www/syncookies/archive Zachary Amsden zamsden@engr.sgi.com
      Message 2 of 9 , Oct 12, 1999
      • 0 Attachment
        One discussion of SYN attacks is found below:

        ftp://koobera.math.uic.edu/www/syncookies/archive

        Zachary Amsden
        zamsden@...

        william Li wrote:
        >
        > Hi Folks:
        >
        > I want through the archive, and find out the summary
        > about the SYN flood attack from David Borman. Unfortunately
        > his summary(src) URL:
        >
        > ftp://ftp.bsdi.com/contrib/bsdi_contrib/44Lite-SYNcache.gz)
        >
        > is not accessible anymore and his e-mail dab@... can
        > not be reached either.
        >
        > Is there an RFC for this problem ?
        > Is there any solution (src) available ?
        >
        > Very appreciated your help.
        >
      • william Li
        This is the syn_cooky solusion. I believe that Vernon s random_drop solusion super-set this one. Does anyone have info about the radom_drop solusion ? Thanks,
        Message 3 of 9 , Oct 12, 1999
        • 0 Attachment
          This is the syn_cooky solusion. I believe that
          Vernon's random_drop solusion super-set this
          one. Does anyone have info about the radom_drop
          solusion ?

          Thanks,


          Zachary Amsden wrote:
          >
          > One discussion of SYN attacks is found below:
          >
          > ftp://koobera.math.uic.edu/www/syncookies/archive
          >
          > Zachary Amsden
          > zamsden@...
          >
          > william Li wrote:
          > >
          > > Hi Folks:
          > >
          > > I want through the archive, and find out the summary
          > > about the SYN flood attack from David Borman. Unfortunately
          > > his summary(src) URL:
          > >
          > > ftp://ftp.bsdi.com/contrib/bsdi_contrib/44Lite-SYNcache.gz)
          > >
          > > is not accessible anymore and his e-mail dab@... can
          > > not be reached either.
          > >
          > > Is there an RFC for this problem ?
          > > Is there any solution (src) available ?
          > >
          > > Very appreciated your help.
          > >

          --
          Cheers

          William Li
          InterNetworking Systems, Lucent Technologies
        • Vernon Schryver
          ... I think the syn-cooky solution was different, and neither a super-set, sub-set, extension, or precursor of random-drop. I also don t like it. Exactly what
          Message 4 of 9 , Oct 12, 1999
          • 0 Attachment
            > From: william Li <liw@...>

            > This is the syn_cooky solusion. I believe that
            > Vernon's random_drop solusion super-set this
            > one. Does anyone have info about the radom_drop
            > solusion ?


            I think the syn-cooky solution was different, and neither a super-set,
            sub-set, extension, or precursor of random-drop. I also don't like it.


            Exactly what is the question?

            Dave Borman's solution can be viewed as a superset of random drop. He
            switched to a hash table to find TCB's, something that everyone who deals
            with large numbers of sockets must do to avoid performance problems. He
            also changed things so that much less state is kept for each partly open
            connection. When that table overflowed, he picked an arbitrary,
            reasonably random connection to throw out of the table. That last bit
            of picking a random connection to give up on instead of either the classic
            4.*BSD tactic of the newest connection or other systems' giving up on
            the oldest connection is crux of random-drop.

            Note that the idea of random-drop was suggested by a public note by
            Robert Morris Jr.


            Has something happened to BSDI? Is there any reason to think that their
            FTP site won't be back? I can't reach them either, but it looks more like
            a routing problem at about the nearest default free router from here
            than a corporate dissolution.


            Vernon Schryver vjs@...
          • Paul Ferguson
            Please see: ftp://ftp.isi.edu/in-notes/rfc2267.txt and http://users.quadrunner.com/chuegen/smurf.txt - paul
            Message 5 of 9 , Oct 12, 1999
            • 0 Attachment
              Please see:

              ftp://ftp.isi.edu/in-notes/rfc2267.txt

              and

              http://users.quadrunner.com/chuegen/smurf.txt

              - paul

              At 10:08 AM 10/12/1999 -0700, william Li wrote:

              >Hi Folks:
              >
              >I want through the archive, and find out the summary
              >about the SYN flood attack from David Borman. Unfortunately
              >his summary(src) URL:
              >
              >ftp://ftp.bsdi.com/contrib/bsdi_contrib/44Lite-SYNcache.gz)
              >
              >is not accessible anymore and his e-mail dab@... can
              >not be reached either.
              >
              >Is there an RFC for this problem ?
              >Is there any solution (src) available ?
              >
              >Very appreciated your help.Reporting-MTA: dns; drawbridge.ascend.com
              >Arrival-Date: Mon, 11 Oct 1999 18:19:08 -0700 (PDT)
              >
              >Final-Recipient: RFC822; dab@...
              >Action: delayed
              >Status: 4.4.1
              >Remote-MTA: DNS; relay.bsdi.com
              >Last-Attempt-Date: Mon, 11 Oct 1999 22:28:48 -0700 (PDT)
              >Will-Retry-Until: Sat, 16 Oct 1999 18:19:08 -0700 (PDT)
              >
              >Return-Path: <liw@...>
              >Received: from fw-ext.ascend.com (fw-ext [198.4.92.5])
              > by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id SAA19237
              > for <dab@...>; Mon, 11 Oct 1999 18:19:08 -0700 (PDT)
              >Received: from russet.ascend.com by fw-ext.ascend.com
              > via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP;
              > 12 Oct 1999 01:24:20 UT
              >Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178])
              > by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id SAA28353
              > for <dab@...>; Mon, 11 Oct 1999 18:24:19 -0700 (PDT)
              >Received: from wli-sun.eng.ascend.com (wli-sun.eng.ascend.com [10.40.40.132])
              > by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id SAA07477
              > for <dab@...>; Mon, 11 Oct 1999 18:26:03 -0700 (PDT)
              >Received: from ascend.com (localhost [127.0.0.1])
              > by wli-sun.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id SAA01504
              > for <dab@...>; Mon, 11 Oct 1999 18:24:19 -0700 (PDT)
              >Sender: liw@...
              >Message-ID: <38028DC3.942B40B7@...>
              >Date: Mon, 11 Oct 1999 18:24:19 -0700
              >From: william Li <liw@...>
              >X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
              >X-Accept-Language: en
              >MIME-Version: 1.0
              >To: dab@...
              >Subject: help
              >Content-Type: text/plain; charset=us-ascii
              >Content-Transfer-Encoding: 7bit
              >
              >Hi David:
              >
              >2 years ago, you have the infamous syn attack
              >resolved at:
              >
              >ftp://ftp.bsdi.com/contrib/bsdi_contrib/44Lite-SYNcache.gz
              >
              >Of course, the site is closed, could you
              >point out the new site? or mail me the
              >portion of the fix if possible.
              >
              >Thanks,
              >--
              >Cheers
              >
              >William Li
              >InterNetworking Systems, Lucent Technologies
            • william Li
              Thanks, Vernon. You answered my question with the following comment. BTW, netbsd has a syn_cache implementation:
              Message 6 of 9 , Oct 12, 1999
              • 0 Attachment
                Thanks, Vernon. You answered my question with
                the following comment.

                BTW, netbsd has a syn_cache implementation:
                ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-1.4.1/source/

                Vernon Schryver wrote:
                >
                > Dave Borman's solution can be viewed as a superset of random drop. He
                > switched to a hash table to find TCB's, something that everyone who deals
                > with large numbers of sockets must do to avoid performance problems. He
                > also changed things so that much less state is kept for each partly open
                > connection. When that table overflowed, he picked an arbitrary,
                > reasonably random connection to throw out of the table. That last bit
                > of picking a random connection to give up on instead of either the classic
                > 4.*BSD tactic of the newest connection or other systems' giving up on
                > the oldest connection is crux of random-drop.
              • David Borman
                William, ... BSDI is back on the air, after a 2 day outage. Our ISP had a broken backbone between POPs, and we were on the wrong side. :-( Anyway, all of
                Message 7 of 9 , Oct 12, 1999
                • 0 Attachment
                  William,

                  > I want through the archive, and find out the summary
                  > about the SYN flood attack from David Borman. Unfortunately
                  > his summary(src) URL:
                  >
                  > ftp://ftp.bsdi.com/contrib/bsdi_contrib/44Lite-SYNcache.gz)
                  >
                  > is not accessible anymore and his e-mail dab@... can
                  > not be reached either.

                  BSDI is back on the air, after a 2 day outage. Our ISP had a
                  broken backbone between POPs, and we were on the wrong side. :-(

                  Anyway, all of bsdi.com is now accessable again. For the time
                  being, I've put a copy of the 44 SYN cache diffs up at:

                  ftp://ftp.bsdi.com/private/44-syn-diffs.gz

                  -David Borman, dab@...
                • David Borman
                  ... Correct. The idea behind the syn-cookie is that when a SYN is received, send out the SYN/ACK, and forget about the connection. When the ACK is received,
                  Message 8 of 9 , Oct 13, 1999
                  • 0 Attachment
                    > Date: Tue, 12 Oct 1999 17:09:48 -0600 (MDT)
                    > From: Vernon Schryver <vjs@...>
                    > Subject: Re: a question about SYN attack
                    >
                    > > From: william Li <liw@...>
                    >
                    > > This is the syn_cooky solusion. I believe that
                    > > Vernon's random_drop solusion super-set this
                    > > one. Does anyone have info about the radom_drop
                    > > solusion ?
                    >
                    >
                    > I think the syn-cooky solution was different, and neither a super-set,
                    > sub-set, extension, or precursor of random-drop. I also don't like it.

                    Correct. The idea behind the syn-cookie is that when a SYN is received,
                    send out the SYN/ACK, and forget about the connection. When the ACK
                    is received, the connection is then created. But to avoid switching
                    the SYN attack to an ACK attack, some magic encoding is done in the
                    sequence number in the SYN/ACK, so that when the ACK is received, it
                    can be verified whether or not it is in response to a SYN/ACK that we
                    sent out. The issues with syn-cookies is how to do that encoding,
                    and if you have to drop to a lower level of service due to lack of
                    bits for encoding state information (like TCP window scale option).

                    > Dave Borman's solution can be viewed as a superset of random drop. He
                    > switched to a hash table to find TCB's, something that everyone who deals
                    > with large numbers of sockets must do to avoid performance problems. He
                    > also changed things so that much less state is kept for each partly open
                    > connection. When that table overflowed, he picked an arbitrary,
                    > reasonably random connection to throw out of the table. That last bit
                    > of picking a random connection to give up on instead of either the classic
                    > 4.*BSD tactic of the newest connection or other systems' giving up on
                    > the oldest connection is crux of random-drop.

                    Well, it's not exactly random drop. Each hash bucket has a limit, and
                    the overall table has a limit. When we decide that we need to drop a
                    connection due to either limit being exceeded, we drop the oldest connection
                    on the hash bucket where we are trying to put the new connection.
                    The hashing function is designed to be non-predictable (from the outside),
                    so that there is a fairly good distribution across all the buckets.

                    > Has something happened to BSDI?
                    > ...

                    No, other than our ISP had a 48 hour outage between POPs that knocked us
                    off the net for 48 hours (compounded by anyone trying to call BSDI on
                    Monday not being able to get anyone, since the main office was closed
                    for Columbus Day.)

                    -David Borman, dab@...
                  • David Borman
                    ... I don t agree with NetBSD s decision to push all connections through the SYN cache, as the SYN cache introduces a situation where valid connections won t
                    Message 9 of 9 , Oct 13, 1999
                    • 0 Attachment
                      > Subject: Re: a question about SYN attack
                      > From: Jason Thorpe <thorpej@...>
                      > Date: Tue, 12 Oct 1999 15:20:16 -0700
                      >
                      > On Tue, 12 Oct 1999 11:49:24 -0700
                      > Zachary Amsden <zamsden@...> wrote:
                      >
                      > > One discussion of SYN attacks is found below:
                      > >
                      > > ftp://koobera.math.uic.edu/www/syncookies/archive
                      > >
                      > > Zachary Amsden
                      > > zamsden@...
                      >
                      > NetBSD also implements the Borman "SYN cache" (it's based on the original
                      > published BSDI diff, but has changed rather significantly since then). In
                      > NetBSD, it is used for all passive embryonic connections (unlike the BSD/OS
                      > version, which was activated only when the system was under "attack").

                      I don't agree with NetBSD's decision to push all connections through
                      the SYN cache, as the SYN cache introduces a situation where valid
                      connections won't be established. Specifically, we don't do retransmission
                      of the SYN/ACK out of the SYN cache (since it is assumed that when we
                      are under attack, retransmitting all the SYN/ACKs will take up a lot of
                      extra cycles for which there will be no benifit). This means that if
                      we respond with a SYN/ACK to a valid connection, the returning ACK gets
                      lost, and there is no initial data coming from the client, then the
                      connection hangs, since ACKs are not retransmitted.

                      My view is that when we are under a SYN flood attack, we're willing to
                      take the risk that some connections might hang, but when we are not
                      under attack we want to be as robust as possible, meaning we do the
                      SYN/ACK retransmissions as necessary.

                      Has NetBSD done something to address this issue?

                      -David Borman, dab@...
                    Your message has been successfully submitted and would be delivered to recipients shortly.