Subject: a question about SYN attack

From: william Li <[email-masked]>
Date: Tue, 12 Oct 1999 10:08:37 -0700

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 [email-masked] can
not be reached either.

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

Very appreciated your help.

Subject: help
From: william Li <[email-masked]>
To: [email-masked]
Date: Mon, 11 Oct 1999 18:24:19 -0700

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

---

From: Jason Thorpe <[email-masked]>
Date: Tue, 12 Oct 1999 15:20:16 -0700

On Tue, 12 Oct 1999 11:49:24 -0700 
 Zachary Amsden <[email-masked]> wrote:

 > One discussion of SYN attacks is found below:
 > 
 > ftp://koobera.math.uic.edu/www/syncookies/archive
 > 
 > Zachary Amsden
 > [email-masked]

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

Information on obtaining the NetBSD source code can be found at:

	http://www.netbsd.org/

 > > Very appreciated your help.

        -- Jason R. Thorpe <[email-masked]>

---

From: David Borman <[email-masked]>
Date: Wed, 13 Oct 1999 11:06:54 -0500 (CDT)

> Date: Tue, 12 Oct 1999 17:09:48 -0600 (MDT)
> From: Vernon Schryver <[email-masked]>
> Subject: Re: a question about SYN attack
>
> > 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, [email-masked]

---

From: David Borman <[email-masked]>
Date: Wed, 13 Oct 1999 11:20:02 -0500 (CDT)

> From: Jason Thorpe <[email-masked]>
> Date: Tue, 12 Oct 1999 15:20:16 -0700
>

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?

---

From: David Borman <[email-masked]>
Date: Tue, 12 Oct 1999 22:28:21 -0500 (CDT)

William,

> is not accessible anymore and his e-mail [email-masked] can

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

---

From: Jason Thorpe <[email-masked]>
Date: Tue, 12 Oct 1999 15:20:16 -0700

http://www.netbsd.org/

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 12 Oct 1999 17:09:48 -0600 (MDT)

Exactly what is the question?

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    [email-masked]

---

From: David Borman <[email-masked]>
Date: Wed, 13 Oct 1999 11:20:02 -0500 (CDT)

---

From: David Borman <[email-masked]>
Date: Wed, 13 Oct 1999 11:06:54 -0500 (CDT)

---

From: Jason Thorpe <[email-masked]>
Date: Wed, 13 Oct 1999 10:38:10 -0700

On Wed, 13 Oct 1999 11:20:02 -0500 (CDT) 

 > connection hangs, since ACKs are not retransmitted.

[ ...snip... ]

 > Has NetBSD done something to address this issue?

Yes.  A while back I added logic to handle transient unreachable-errors
and retransmit logic to the NetBSD SYN cache implementation.  I'm pretty
sure it's all in the 1.4.1 release (and may have also been in 1.4; I'm
not entirely certain, tho...)

When we decided to push all connections through the SYN cache, it really
helped clean up that code path; using both paths was quickly turning into
a real maintenance headache.

The net result (no pun intended :-) is that connections over a flaky network
continue to get through, even while the machine is being flooded at a high
rate.

---

From: David Borman <[email-masked]>
Date: Tue, 12 Oct 1999 22:28:21 -0500 (CDT)

William,

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 12 Oct 1999 17:09:48 -0600 (MDT)

---

From: Jason Thorpe <[email-masked]>
Date: Tue, 12 Oct 1999 15:20:16 -0700

http://www.netbsd.org/

---

From: David Borman <[email-masked]>
Date: Wed, 13 Oct 1999 11:20:02 -0500 (CDT)

---

From: David Borman <[email-masked]>
Date: Wed, 13 Oct 1999 11:06:54 -0500 (CDT)

---

From: Jason Thorpe <[email-masked]>
Date: Wed, 13 Oct 1999 10:38:10 -0700

[ ...snip... ]

---

From: David Borman <[email-masked]>
Date: Tue, 12 Oct 1999 22:28:21 -0500 (CDT)

William,

---

From: David Borman <[email-masked]>
Date: Wed, 13 Oct 1999 11:06:54 -0500 (CDT)

---

From: Jason Thorpe <[email-masked]>
Date: Wed, 13 Oct 1999 10:38:10 -0700

[ ...snip... ]

---

From: David Borman <[email-masked]>
Date: Wed, 13 Oct 1999 11:20:02 -0500 (CDT)