Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02

On Wed, Mar 26, 2008 at 01:05:27PM -0700, Jakob Heitz wrote:
> Intentionally dropping segments at the sender
> has an unacceptable negative impact on honest
> connections. No wonder this never flew.

My experiments have show this to be a <0.01% impact on perfomance and
no impact on correctness.  You might argue that my experiments do not
have a wide deployment and might depend on network conditions, but I
don't know why you say the solution is "unacceptable".

> You can detect a possible attacker of this nature
> just by looking for acks of segments you have
> not yet sent. After all, the attacker is sending
> acks for what he didn't receive, so he has no idea
> how far into the future to ack.
> Even if you look for future acks, they may be legit
> ones from a previous connection or old ones from
> the same connection if the sequence space has wrapped.
>
> So I suggest as a defense, if you receive an ack of
> the future, to halve the congestion window.

As I say in my paper, this is not a reasonable defense.

1) The attack does not necessarily send Acks ahead of what is sent and
	I outline a number of ways to avoid doing so.
2) If this is the detection condition, it opens a new DoS where a different
	type of attacker can inject out-of-window Acks into valid connections
	to create false possitives in this test.  Thus, if what you propose 
	were implemented, a third party could force the congestion window
	to be arbitarily small for a connection between two honest nodes,
	without guessing the sequence number.

- Rob
.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm