[e2e] ISN regeneration when Stateless SYN cookies are used

[Michael B Greenwald]

   Fri, 19 Oct 2001 02:25:08 +0530
   "gangadharan annapurna" <nallu17 at hotmail.com>

   I sense some confusion here. Let me clarify:
   
   (a) The server can't achieve anything by advertising a smaller window size, 
   it is the client that is controlling this. So, there is really nothing the 
   server can do at this point...

Although I was half joking about the window size, it is the client's window
size that is relevant, and it is the client that sets the window in the
SYN.  (It is the client who is getting reset, so presumably the client is
the one who cares about avoiding this problem.)  The "duplicate" (new)
SYN-ACK's ISN must fall between
 old-ISN and (old-ISN + client-offered-window-size)
for it to be valid and cause a reset connection.  If
client-offered-window-size is small then the odds of the delayed SYN-ACK
causing a reset are small.

   (b) It is possible to come up with a scenarrio which deterministically

Deterministically?  Are you sure?

I may misunderstand the Linux algorithm, but here's what I thought:

First of all, your "f(t)" increases only once every minute, so the odds are
high that if the delay is within 30 seconds there won't even be two
distinct SYN-ACKS, so no chance of a RST. (i.e. they'll just be normal
duplicates just like the "normal" TCP).

Second, even if there is a distinct new SYN-ACK, it is unlikely (but not
impossible) to cause a RST.  f(t) appears inside one of the two MD5 hashes,
so the second ISN will appear to be randomly chosen anywhere inside the
sequence number space, so it is unlikely that the "new SYN-ACK" will have
an ISN that is inside the client's window.

I just looked quickly at the linux code, and it's not quite as unlikely as
I thought (although still *very* unlikely).  The MD5 hash with f(t)
("count") is only used to set the low order 24 bits of the ISN, not all 32
bits.  f(t) affects the 25th bit, so you're still pretty safe as long as
the window size is under 32MB.  If that's not good enough (remember, this
is only an issue at all if the retransmission of the SYN crossed a minute
boundary, which is unlikely for RTTs that are on the order of 5 seconds)
--- if that's not good enough, then maybe linux could change the
implementation so that the first hash would be mod 2^24, and the second
(with f(t) inside it) would be for the full 32 bits.  Then you'll be
extremely safe from RST no matter what the window.

So while there is an *extremely* small chance of the RST occuring in the
first place, it is unlikely to occur on a second or third attempt.  I just
don't see how it is deterministic (even if the window is 32 Meg long, you
still have to hit the clock just right). 

   fails to establish the connection with the way the ISN is chosen. If I
   assume that ISN is incremented every 4 micro seconds (RFC 793 etc), then
   it would get incremented by 250K per second. So any connection which
   advertises a window size of greater or equal to 250K * RTT is 'never'
   going to succeed (assuming no packet loss, of course). I feel that this
   is a common occurance with window-scaling and should be addressed.
   
You should feel free to argue/demonstrate that it is an important problem,
and then address it (I think a sufficient fix is to swap the "%2^24" in the
two md5 hashes).  I'll admit that I'm not personally too worried, but I'll
also admit that I may be short-sighted here.