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

On Mon, 29 Sep 2003, Guido van Rooij wrote:

> > #define MAXACKWINDOW 66000
> > (-ackskew <= (MAXACKWINDOW << fdata->td_winscale)) &&
> > ( ackskew <= (MAXACKWINDOW << fdata->td_winscale))) {
>
> This is wrong. It should be tdata in both cases.
>

Thanks, will look into it.

> > 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.
>

Old packets have a *positive* ack slew. Negative ack slew is for ACKs that
are ahead of the highest seq+len from the other side. The reason this is
possible is that (apparently) the length only takes the first fragment
into account. Negative ack slew never gets more negative as the packet
ages (td_end never moves back). Negative ack slew should never exceed the
MSS (I think).

> >
> > 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.
>

The comment talks about why negative slew is allowed, but not about why it
is cumulative or about why it adjusts td_end instead of merely
compensating for the uncertainty elsewhere (by a allowing a fuzz of order
1*MSS in the 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?

Because this is not cumulative. At the very least the negative slew bound
should be smaller than the positive slew bound.

>
> >
> > 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".

What is odd here is that party A can effectively adjust the sequence+len
state for party B, by sending a succession of growing ACK values. This
puts party B out of window, even though what was "out of window" (actually
the window has nothing to do with it, just ACKS for packets never sent)
was party A's ACK packets. This should not be possible, perhaps this is
harmless...

>
> >
> > 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/
>

Thanks, will do.

--
Victor Duchovni
IT Security,
Morgan Stanley