Talk:SYN cookies

From Wikipedia, the free encyclopedia

This article is part of WikiProject Cryptography, an attempt to build a comprehensive and detailed guide to cryptography on Wikipedia. If you would like to participate, you can choose to edit the article attached to this page, or visit the project page, where you can join the project and see a list of open tasks.

It is intended that this article be included in WikiReader Cryptography, a WikiReader on the topic of cryptography. Help and comments for improving this article would be especially welcome. A tool for coordinating the editing and review of these articles is the daily article box.

I re-wrote the SYN Cookies article from scratch to avoid any copyright violations. I believe the replacement article is much clearer than the original, anyway. The new article is currently on the Temporary subpage. Tylerl 21:52, 16 August 2006 (UTC)

Done: Moved rewritten article over deleted copyright infringement. —Centrx→talk • 21:32, 21 August 2006 (UTC)

Shouldn't it be SYN cookies, not SYN Cookies? A cookie, in this sense, is a token, and shouldn't be capitalized. It'd be like saying SYN Tokens instead of SYN tokens. Sword 15:26, 20 February 2007 (UTC)

"many implementations use zero as the initial sequence number" - surely not? 793 (Transmission Control Protocol), page 27, under the heading "Initial Sequence Number Selection", makes clear that this should not be so. Alang 04:19, 6 March 2007 (UTC)

Agreed. I also believe that statement is incorrect, so I've removed it.

In addition to the RFC, [1] (which is referenced from TCP Sequence Prediction Attack) states that "TCP/IP stacks based upon BSD Unix increase the sequence number by 128,000 every second and by 64,000 for every new TCP connection." If BSD doesn't use sequence numbers of 0, and since the RFC says not to, I'd say it's definitely not common. Crispy 05:15, 11 June 2007 (UTC)

Shouldn't this be SYN cookie (singular)? Isopropyl 16:24, 11 July 2007 (UTC)

[edit] Self-DoS and bounce flooding

Isn't it also one of the drawbacks of using syncookies that the server using them will respond to an incoming synflood with an outgoing synack flood of the same intensity?

This can lead to self-DoS in case of asymmetric bandwidth (e.g. ADSL) because the upstream connection can be saturated by the outgoing SYN ACK packets even if the downstream could handle the incoming SYNs; additionally, traffic shaping typically gives precedence to ACK packets, so that these SYN ACKs could easily make the connection unusable even under relatively light attack.

Also, syncookies enable an attacker to anonymously bounce flood a victim by flooding a server with spoofed SYN packets that show the victim as their source.

I didn't want to just go and add these issues to the page as it's something I thought of but haven't seen written down anywhere else, so maybe it's original research. :)

--195.56.53.118 21:18, 21 June 2007 (UTC)

[edit] A defence against IP spoofing?

It seems to me that SYN cookies are a pretty effective defence against IP spoofing, at least for protocols which use TCP. You need to be able to guess the ISN to spoof, and SYN cookies, inter alia, make that impossible - even if the attacker could guess the timestamp and MSS code, and knew the address and port of each endpoint, he couldn't compute the 's' part, because he doesn't know the secret used in the hash. No 's' part, no valid cookie, no connection.

Bernstein mentions this in his article, under "Blind connection forgery". At least, if i've understood it right.

Anyway, if this is a known use of SYN cookies, we don't mention it, and we certainly should.

-- Tom Anderson 2008-06-04 23:49 +0100