Subject: [tcpm] syn flooding draft

From: Wesley Eddy <[email-masked]>
Date: Thu, 13 Apr 2006 15:48:11 -0400

FYI: An updated version of the draft on TCP SYN flooding and defenses
(including SYN cookies) is available:
http://www.ietf.org/internet-drafts/draft-eddy-syn-flood-02.txt

I am soliciting comments/questions/suggestions.

-- 
Wesley M. Eddy
Verizon Federal Network Systems
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Mikael Olsson <[email-masked]>
Date: Wed, 19 Apr 2006 14:58:45 +0200

Couple of things off the top of my head:

1. On the problem with SYN Cookies and daemons sending the first
  data packet: Yes, packet loss will cause problems here, but remember
  that TCP implementations should only rely on SYN Cookies when their
  half-open queue is full anyway.

2. Attacks on the SYN Cookie scheme itself:
- 7 bits of authentication means an attacker that knows the
  authentication algorithm of the responder "only" needs to
  send 128 times as many packets to establish a fully spoofed
  complete connection that now uses a full TCB as well as
  application resources.
- 40 bytes per SYN * 128 = 5120 bytes.
  5120 bytes * 8 bits * 100 connections = 4Mbit to create 100 connections,
  which is likely to hurt most servers to some extent.
- Connection speeds are always on the rise. A 10mbit upstream pipe is
  far from uncommon today. An attacker on even such a "modest" connection
  is capable of bringing most any server to its knees in as little as
  one second.
- Determining where in the ISN the authentication bits are stored can
  easily be automated by sending as few as maybe a dozen packets and
  detecting which bits are ALWAYS affected as a result of changing
  a single field. This probe could obviously not be spoofed though.

3. On SYN Cache replacement schemes:
   This is implementation rather than spec, but then again so is
   "SYN Cache" to begin with so I figure it's fair game:
   Rather than replacing the oldest entry (common practice), while under
   attack, it makes more sense to replace a random entry. The more slots
   an attacker manages to fill, the higher the chance that the next
   spoofed packet will replace one of the attacker's own slots.

/Mikael

-- 
Mikael Olsson, Clavister AB
Torggatan 10, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com

---

From: Mark Allman <[email-masked]>
Date: Wed, 26 Apr 2006 15:53:48 -0400

Folks- 

> http://www.ietf.org/internet-drafts/draft-eddy-syn-flood-02.txt

has been discussed a bit on the list.  The vibe Ted and I have picked up
is that folks think its a good document to have around (even though
several folks have identified possible areas for improvement).  So,
we're asking if folks think that TCPM should take on this document as a
WG item.  As the document states, it's targeted as informational and a
guess at a timeframe (a WAG between Wes, Ted and I) is 6 months.

If you think this ought to be on our plate (or not), please say so.
(Lack of positive response will meet with the same decision as an
overwhelmingly negative response.)

Thanks!

allman

-- 
Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/