Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00

Rob Sherwood <capveg@cs.umd.edu> Wed, 21 February 2007 18:33 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwHO-00086s-FK; Wed, 21 Feb 2007 13:33:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwHN-00086l-LI for tcpm@ietf.org; Wed, 21 Feb 2007 13:33:25 -0500
Received: from circular.cs.umd.edu ([128.8.128.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJwHM-0006xB-C9 for tcpm@ietf.org; Wed, 21 Feb 2007 13:33:25 -0500
Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by circular.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l1LIXNFt020496; Wed, 21 Feb 2007 13:33:23 -0500
Received: (from capveg@localhost) by loompa.cs.umd.edu (8.12.10/8.12.5) id l1LIXNXC025097; Wed, 21 Feb 2007 13:33:23 -0500 (EST)
Date: Wed, 21 Feb 2007 13:33:23 -0500
From: Rob Sherwood <capveg@cs.umd.edu>
To: Gavin McCullagh <gavin.mccullagh@nuim.ie>
Subject: Re: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00
Message-ID: <20070221183323.GG20215@loompa.cs.umd.edu>
References: <BAB4DC0CD5148948A86BD047A85CE2A7022D8F94@E03MVZ4-UKDY.domain1.systemhost.net> <20070220193652.GZ20215@loompa.cs.umd.edu> <20070221102317.GP3162@nuim.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20070221102317.GP3162@nuim.ie>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

On Wed, Feb 21, 2007 at 10:23:17AM +0000, Gavin McCullagh wrote:
> Hi,
> 
> On Tue, 20 Feb 2007, Rob Sherwood wrote:
> 
> > Should people decide that this two phases approach is preferable, it
> > might be possible to simplify the first phase test as follows.  Rather
> > then reordering segments N-1,N,N+1,..,N+D to N-1,N+1,..,N+D,N as Toby
> > et. al suggest, it might be better to more frequently perform this test
> > with D=1, (i.e., simply swap the order of two sequential segments) and
> > after some threshold number K failures, apply the second phase randomly
> > skipped segment test.
> 
> Perhaps I misunderstand, but is it not necessary to have variation in D of
> at least 
>         0 < D < 4
> for the attack to be definitively prevented?
> 
> The "lazy ack" form of the attack just omits duplicate acks in order that a
> loss is never detected.  If the above were implemented with D=1 it appears
> that an attacker could always send the first duplicate ack in response to a
> missing packet but omit the second or third duplicate ack.  This would seem
> to allow the attack to continue but also pass the N-1,N+1,N test.
> 
> I guess if lots of packets are being lost as part of the attack this kind
> of precision may be impossible on the part of the attacker so maybe the
> above is not so important.

Your last paragraph sums it up correctly, IMHO.  If the receiver is
actually receiving all packets, then of course it can defeat any test
-- but then there is no attack.  With Lazy ack, if the receiver were
dropping some constant percentage of packets p, then over n tests,
we can expect the receiver to fail p*n tests, and this solution can
be engineered so that k (the number of failed tests before phase 2)
is chosen to prevent the amplification rate from being too high.

In an alternate attack, the attacker could duplicate ack all packets,
but then the amplication factor suffers (1 data packet/(D+1) acks ==
1500/(D+1)*40 == 37.5x/(D+1)).   Maybe it does make sense to consider
D>1 such that the amplification factor suffers more.  Obviously, D>37,
i.e., the value the prevents *any* amplification, is too large for
practical considerations, but it does make the case for a larger value
of D (contrary to what I was suggesting earlier).

- Rob
.

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm