![]() ![]() some load balancers (who also try hard not to keep the state). It’s sufficiently rare in today’s protocols, though.Īnother problem that the above approach will create afresh is that it assumes that the retransmitted client SYNs will have the same ISN, which isn’t the same in practice with e.g. The problem that is impossible to solve, however, is the lost third ACK (acknowledging SYN-ACK) from the client, if the client doesn’t send any data to server upon the connect. Then every packet other than the first data packet will be discarded as invalid, and eventually the client-side retransmits will take care that everything works properly. This particular problem is solvable by having (client_sequence_number+1) to be part of the HMAC (thus checking it as well), and by storing the MSS in the MSB part of the generated server sequence number rather than in the LSB. We ran into this on localhost first, but then later across the internet with external clients. For those unfamiliar with FreeBSD, the localhost interface on FreeBSD runs full TCP, and under high load can drop packets and retransmit. If the hosts had low enough round trip times, the number of ACK probes sent could be tremendous. The server would see an ACK ahead of where it had sent, and send an ACK probe. The details are a bit hazy, but the client would get an ACK with SEQ behind where it had ACKed, and would send an ACK probe with it's latest values. I guess you would have a similar lack of dogs, but also, if a connection was opened and closed quickly, a re-transmitted packet from the client would satisfy the SYN cookie calculation, and the server would re-open the connection, but at it's original sequence number. I'm sure there's something misguided or wrong in the above?įreeBSD had a more fun SYN cookie bug in 2015 (fixed here, and I think this is the diff where it was introduced determining which releases it touched is an exercise for the reader) the initial sequence of the sender had been left out. The probability of forgery would marginally increase to 2^-25.īut, I'm no TCP expert. ![]() 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 cookie would need to verify with one of the (small) K most recent keys. To re-address the problem of replay attacks, the server could rotate keys rather than include a timestamp in the data component. The hash could then be 26 bits, leaving a very small probability of forgery of 2^-26. The syn cookie would then be (MSScat | WSCALE | HASH(key | saddr | daddr | sport | dport | sseq | MSScat | WSCALE)). 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. 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. you can somewhat negotiate window scaling when tcp timestamps are enabled. ![]()
0 Comments
Leave a Reply. |