Re: Negative ack slew, window scaling, ...

On Fri, Sep 26, 2003 at 01:16:52PM -0400, Victor.Duchovni@morganstanley.com wrote:
>
> There 4.0beta1 code handles window scaling more gracefully by also scaling
> the maximum ack slew:
>
> #define MAXACKWINDOW 66000
> (-ackskew <= (MAXACKWINDOW << fdata->td_winscale)) &&
> ( ackskew <= (MAXACKWINDOW << fdata->td_winscale))) {

This is wrong. It should be tdata in both cases.

[...]

>
> I am bit puzzled both by this better code and the original. While
> a positive ack slew can reasonably be almost a full window behind the
> sender, it seems to me that a negative slew is at most one MSS ahead of
> the sender, because total seize of a fragmented TCP frame is at most equal
> to the MSS. This would suggest that the bound on the negative slew can be
> much smaller and independent of the window scale (after all IP
> fragmentation is independent of TCP window scaling).

No. An ack can be circling around on the internet for some time.
When the ack finally pops up, you can indeed safely ignore it, but it
will lead to a blocked packet. So in order to not generate blocks if
you do not need to, we set an arbitrary limit.

>
> Secondly, the code allows negative ack slew to permanently advance
> tdata->td_end, and repeated slewed acks can move td->td_end arbitrarily
> far away from the actual sender state without any corresponding
> transmission from the sender.

This was explained in the comment in the code. Be advised that in order
to be able to "exploit" this, you have to either know the current
window (so you are already able to inject spoofed packets), or
be very lucky because the total sequence number space is much larger
then the (ackskew) window.

>
> It seems to me, that the (at most 1*MSS) uncertainty in the sender's
> *next* sequence number should be calculated separately from tdata->td_end,
> only observed packets from the sender should advance td_end, with the
> uncertainty taken into account when the value is used.

Why bother?

>
> While I cannot off hand think of any security consequences of allowing the
> recipient to arbitrarily advance the sender sequence number, the mere
> possibility makes me uneasy for reasons I can not at this time rationally
> justify.

Like I said earlier, you cannot advance the td_end arbitrarily, unless
you have can sniff the connection, In this case it doesn't matter
what ipfilter does as you always insert spoofed packets that "look right".

>
> Please forgive my ignorance, I could easily be the victim of my own
> limited exposure to the problem space and IPFilter code. If I am missing
> something important, please clue me in. If with luck there is a
> kernel of truth in the above rant, perhaps someone can polish it into a
> better formed analysis that might lead to improvements in the code.

Best is to read my paper on this subject:


http://www.madison-gurkha.com/public...senix-sec2001/

-Guido