[e2e] ISN regeneration when Stateless SYN cookies are used

[gangadharan annapurna]

Thanks. Couple of points:

(a) Does not matter what the interval that you choose to increment f(t) 
(which I assume is the monotonically increasing portion of the ISN), 2 SYNs 
can alwasy straddle the boundary. So, the argument that just because the 
interval is 60 seconds is going to protect all the connections does not 
sound right to me. It still looks like a problem for clients with request a 
window size of 32MB or larger.

(b) Another look at the Linux code confirms what you say(as far as I can 
see) and leads to another question: Incrementing the ISN every 60 seconds 
may not be a very good idea as it will disallow reusing the same 
(address,port) pair between 2 peers within that time period. Is this 
considered acceptable?



>From: Michael B Greenwald <mbgreen at dsl.cis.upenn.edu>
>To: "gangadharan annapurna" <nallu17 at hotmail.com>
>CC: mbgreen at dsl.cis.upenn.edu, john at loverso.southborough.ma.us,   
>mahesh at erg.abdn.ac.uk, end2end-interest at postel.org
>Subject: Re: [e2e] ISN regeneration when Stateless SYN cookies are used
>Date: Thu, 18 Oct 2001 18:55:15 EDT
>
>    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.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp