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

Rob Sherwood <capveg@cs.umd.edu> Wed, 26 March 2008 19:36 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 B940428C5D7; Wed, 26 Mar 2008 12:36:46 -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 DhLGfO-O9Q6A; Wed, 26 Mar 2008 12:36:42 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5FE28C18A; Wed, 26 Mar 2008 12:36:42 -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 0B2623A6C0D for <tcpm@core3.amsl.com>; Wed, 26 Mar 2008 12:36:42 -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 qCBqZiDT-C56 for <tcpm@core3.amsl.com>; Wed, 26 Mar 2008 12:36:40 -0700 (PDT)
Received: from circular.cs.umd.edu (circular.cs.umd.edu [128.8.128.176]) by core3.amsl.com (Postfix) with ESMTP id 0720828C196 for <tcpm@ietf.org>; Wed, 26 Mar 2008 12:36:39 -0700 (PDT)
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 m2QJYCoq019550; Wed, 26 Mar 2008 15:34:12 -0400
Received: from loompa.cs.umd.edu (localhost [127.0.0.1]) by loompa.cs.umd.edu (8.13.8+Sun/8.12.5) with ESMTP id m2QJXsIg005062; Wed, 26 Mar 2008 15:33:54 -0400 (EDT)
Received: (from capveg@localhost) by loompa.cs.umd.edu (8.13.8+Sun/8.13.8/Submit) id m2QJXcJf005057; Wed, 26 Mar 2008 15:33:38 -0400 (EDT)
Date: Wed, 26 Mar 2008 15:33:38 -0400
From: Rob Sherwood <capveg@cs.umd.edu>
To: Pekka Savola <pekkas@netcore.fi>
Message-ID: <20080326193338.GO24842@cs.umd.edu>
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>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.LRH.1.10.0803262012190.27746@netcore.fi>
User-Agent: Mutt/1.5.16 (2007-06-09)
Cc: tcpm@ietf.org
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

On Wed, Mar 26, 2008 at 08:21:49PM +0200, Pekka Savola wrote:
> On Wed, 26 Mar 2008, Bob Briscoe wrote:
> > I'd tend to agree with ROb - publication is unlikely to get the
> > solution out there any quicker.
> 
> First, I suggest you or someone contact the most interesting vendors 
> (some BSD and Linux communities) about this and potentially obtain a 
> CVE number.  Fernando Gont might be willing to help with this process 
> as he has been through it before.

When I first published my paper (2005), I brought the issue up with
CERT and they issued the problem [VU#102014]
(http://www.kb.cert.org/vuls/id/102014).  While not a CVE, I believe it
has the same effect (maybe others may disagree).  

> But if you believe this issue is progressing in the IETF, maybe 
> publishing the PoC is premature.  If the progress is slow I'd suggest 
> contacting vendors' security teams now.

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
c) people who believe this attack is practical and dangerous, but felt
	my randomly-skipped segments solution was not "good" for
	reasons of efficiency, correctness, etc.

In my mind, publishing the PoC could convince people in group (a) to
move to group (b).  If the attack were to become active in the wild,
then maybe people might move from (b) to (c).  But that still leaves
the bottleneck on people in group (c) to come up with a "good"
solution.  Bob Briscoe et al. have come up with a variant on my
solution, but I am not certain how well its been scrutinised or if it
has even been implemented.

So, in my mind, the best case is that publishing the PoC could get more
people looking at potential solutions to the attack, at the cost of
potentially causing widespread DoS.  Given that analysis, I chose not
to publish my code, but I will leave it to Stefanos to decide what to
do with his.

- Rob
.

[1] I guess there is a forth group (namely, me) that believed the attack
was practical and dangerous, and that the skipped segment solution was
good, but I guess we can discount that :-)
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm