Talk:SYN cookies

Computing: Networking / Software Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Low-importance).
	This article is supported by WikiProject Software (assessed as Low-importance).

Cryptography: Computer science

	This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography articles
???	This article has not yet received a rating on the importance scale.
	This article is supported by WikiProject Computer science.

rewrite

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)[reply]

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

capitalization

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)[reply]

initial sequence number

"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)[reply]

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)[reply]

singular

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

Missing TCP Options

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: [2] — Preceding unsigned comment added by 93.36.135.151 (talk) 17:54, 31 March 2013 (UTC)[reply]

The use of TCP Timestamp option is now mentioned. --WikiWikiPhil (talk) 13:17, 8 December 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

According to research released by Jakob Lell [3], Syn cookies have a side effect of making it potentially easier to guess the ISN. This is possible due to the fields required to encode the cookie (an MSS and timestamp) actually reduce the possible values of the ISN and allow for more than one ISN to be accepted. This enables one to blindly guess the ISN which can allow spoofing of the tcp connection. That means that someone on your same segment can spoof a tcp connection as you. 66.68.161.156 (talk) —Preceding undated comment added 04:20, 23 August 2013 (UTC)[reply]

Drawbacks

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)[reply]