4 ms·
> - you can somewhat negotiate window scaling when tcp timestamps are enabled. Reading the RFC, couldn't the requested window scale be jammed into the sequence
by Majromax 7y ago
> - you can somewhat negotiate window scaling when tcp timestamps are enabled.
Reading the RFC, couldn't the requested window scale be jammed into the sequence number? Section 2.3 limits the window scale to <= 14 bits. This article suggests that the MSS category fits into 2 bits, so we take up 6 of the 32 sequence number bits for mandatory additional data.
The syn cookie would then be (MSScat | WSCALE | HASH(key | saddr | daddr | sport | dport | sseq | MSScat | WSCALE)). The hash could then be 26 bits, leaving a very small probability of forgery of 2^-26.
To re-address the problem of replay attacks, the server could rotate keys rather than include a timestamp in the data component. The cookie would need to verify with one of the (small) K most recent keys. If K were 2, then any ACKs younger than COOKIE_AGE would verify, ACKs up to twice COOKIE_AGE might verify, and older ACKs would be rejected. The probability of forgery would marginally increase to 2^-25.
But, I'm no TCP expert. I'm sure there's something misguided or wrong in the above?
- toast0 7y agoFreeBSD uses a pretty similar approach to what you've described: MSS and Windows Scale are each turned into 3-bit table entries, SACK gets one bit, and one bit indicates which MAC secret was used; secrets are rotated every 15 seconds, two are kept, so client ACK needs to come in 15-30 seconds depending on where in the rotation cycle you are; 24-bits are used for the MAC. 15 second round trip covers the vast majority of internet connections. Details nicely commented here: https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_syncache.c#L1967 https://github.com/freebsd/freebsd/blob/master/sys/netinet/t...
- Majromax 7y agoPerfect, that's exactly the kind of thing I was looking for. Although I'm a little confused by the comment's description of the birthday attack -- it doesn't immediately seem useful to me for an attacker to find separate connections that generate the same cookie.
- toast0 7y agoI'm not a cryptographer, but as I understand it, the birthday attack says if you have a valid hash for one thing, you can generate more things, and get a collision in a surpisingly small number of iterations. In this context, it's easy to get a valid hash --- when the system is in syncookie mode, send a SYN from an address where you have visibility of the SYN+ACK responses. Then, you could use that cookie (sequence number) to spoof ACK packets with other sources, and they've estimated the number of packets you need to spoof before you'll have probably generated a connection. That number of packets is significantly fewer than when the syncache has not overflowed recently, and you need to have sent a SYN, and have an exact match of the sequence number.