[Iccrg] review of Compound TCP draft

[weddy at grc.nasa.gov]

On Wed, Nov 21, 2007 at 12:52:30PM -0800, Lachlan Andrew wrote:
> 
> On 21/11/2007, Murari Sridharan <muraris at microsoft.com> wrote:
> > "One thought, that might be fruitless:  Given the delay-based component,
> > is CTCP increasingly vulnerable to ACK-spoofing attacks in comparison
> > to normal TCP?"
> >
> > Can you clarify the exact attack here. Are you suggesting that if somebody (in the middle) can inject ACKs in the window it might make things worse since our RTT samples are skewed to be much smaller and as a result we might increase aggressively thinking there is no congestion? If so why is this a problem only to delay based algorithms I think any high-speed algorithm that is ack clocked is equally vulnerable.
> 
> I think Wes's concern is that the algorithm might be fooled into
> thinking there is less queueing delay, and hence increase the window
> faster.  Purely loss-based algorithm will not increase their windows
> faster based on their estimate of the queueing, and so are less
> sensitive.  (Of course, proxies which reduce the RTT can still
> increase the throughput of loss-based algorithms.)
> 
> I think that the algorithm is OK, because spoofing ACKs is likely to
> make the estimated *base* RTT lower, which makes *all* other delays
> seem to be delayed.  Thus an attacker would be likely to get a lower
> overall rate by spoofing ACKs.  It is a good point and should be
> mentioned in the draft as a point for investigation, since my "thought
> experiment" is not conclusive.
> 


Yeah, I think this is basically where I was going, though I didn't (and
still haven't) really thought about it carefully :) ... Just to be
clear, I wasn't necessarily posing an actual concern needing to be
addressed, just asking a "what if" question with regards to
ack-spoofing.  The topic is actually larger than CTCP.  We understand
how ack spoofing affects congestion controllers based on either number
of segments or bytes acked (e.g. [1], and others), but maybe there's
interesting research in how it affects controllers that use delay as an
input?  I don't know myself, and it may turn out to be
not-so-interesting at all ...

[1] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
    "TCP Congestion Control With a Misbehaving Receiver", ACM
    Computer Communication Review, 29(5), October 1999.