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

Jakob Heitz <jheitz@redback.com> Wed, 26 March 2008 20:07 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: ietfarch-tcpm-archive@core3.amsl.com
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487B828C6B6; Wed, 26 Mar 2008 13:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.591
X-Spam-Level:
X-Spam-Status: No, score=-100.591 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MO0jSEs4vLVm; Wed, 26 Mar 2008 13:07:49 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 561B328C2F2; Wed, 26 Mar 2008 13:07:49 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BBD53A6E23 for <tcpm@core3.amsl.com>; Wed, 26 Mar 2008 13:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CnEElYDAK9z for <tcpm@core3.amsl.com>; Wed, 26 Mar 2008 13:07:46 -0700 (PDT)
Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 5A5723A6DE0 for <tcpm@ietf.org>; Wed, 26 Mar 2008 13:07:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 29FE0C01BF4; Wed, 26 Mar 2008 13:05:27 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14411-05; Wed, 26 Mar 2008 13:05:27 -0700 (PDT)
Received: from [127.0.0.1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id DA8C1C01BF7; Wed, 26 Mar 2008 13:05:26 -0700 (PDT)
Message-ID: <47EAAC87.2090606@redback.com>
Date: Wed, 26 Mar 2008 13:05:27 -0700
From: Jakob Heitz <jheitz@redback.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: tcpm@ietf.org
References: <200803260029.33658.v13@v13.gr> <20080326042515.GD24842@cs.umd.edu><200803261438.m2QEchkI001007@bagheera.jungle.bt.co.uk><alpine.LRH.1.10.0803262012190.27746@netcore.fi> <20080326193338.GO24842@cs.umd.edu> <78C9135A3D2ECE4B8162EBDCE82CAD7703442C8F@nekter>
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7703442C8F@nekter>
X-Virus-Scanned: by amavisd-new at redback.com
Subject: Re: [tcpm] PoC for draft-moncaster-tcpm-rcv-cheat-02
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.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://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Intentionally dropping segments at the sender
has an unacceptable negative impact on honest
connections. No wonder this never flew.

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.

Caitlin Bestler wrote:
>> Rob Sherwood wrote
>>
>> I contact vendors in 2005, and the response was luke warm (as was the
>> response on this list).  My take on this issue is that people are
>> divided into three[1] camps:
>>
>> a) people who do not believe this attack practical
>> b) people who believe the attack is practical, but not dangerous
> enough
>> 	to motivate patching TCP implementations
> 
> I'd rephrase that as:
> 
> b) people who believe the attack is practical, but that the problem is
> an
>    application layer problem that should be solved at the application
> layer
>  -- and especially not by transport layer solutions that would have a
>     negative impact on honest connections.
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
Jakob Heitz. x5475. 510-566-2901
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm