Talk:SYN cookies

message: 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)
replies: text: Done: Moved rewritten article over deleted copyright infringement. —Centrx→talk • 21:32, 21 August 2006 (UTC)
thread_title: rewrite

message: 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)
thread_title: capitalization

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

message: The article says "Second, the server must reject all TCP options (such as large windows), because the server discards the SYN queue entry where that information would otherwise be stored". But actually now the Linux kernel does a trick in order to save also large window option, ECN and other:   — Preceding unsigned comment added by 93.36.135.151 (talk) 17:54, 31 March 2013 (UTC)
replies: text: The use of TCP Timestamp option is now mentioned. --WikiWikiPhil (talk) 13:17, 8 December 2020 (UTC)
thread_title:  Missing TCP Options 

message: 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)
replies: text: That is not a specific limitation to SYN cookies since each SYN request will be followed up with an equal number of SYN+ACKs whether you are using SYN cookies or not. Greetings --hroest 21:20, 9 February 2010 (UTC)
replies: text: That's not entirely true; if you don't have a way to weather a SYN flood, eventually your backlog queue will fill up and you won't be able to send new SYN+ACK packets (only at a much reduced rate, as old half-open connections time out, freeing up backlog slots). --195.56.53.118 (talk) 00:18, 4 October 2010 (UTC)
thread_title:  Self-DoS and bounce flooding 

message: 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
:I dont see the advantage compared to completely random sequence numbers. If anything, SYN cookies make it easier to guess the sequence number correctly since a lot of its components are already known to the attacker (source IP, time etc) and the search space is reduced compared to completely random sequence numbers. So, if anything, SYN cookies make it easier for the attacker, not harder, to guess the sequence number. Greetings --hroest 21:32, 9 February 2010 (UTC)
thread_title:  A defence against IP spoofing? 

message: A problem arises when the connection-finalizing ACK packet sent by the client is lost ... In this case, the client assumes that the connection was established successfully
Something is wrong here. I think it should be "connection-initializing ACK packet sent to the client is lost". Polarbear (talk) 19:10, 16 March 2023 (UTC)
thread_title:  Drawbacks