[beepwg] Re: [Vortex] A couple of features to limit BEEP no reply attack

Benoit Amiaux <b.amiaux@ateme.com> Wed, 25 March 2009 09:07 UTC

Return-Path: <beepwg-bounces@beepcore.org>
X-Original-To: ietfarch-beep-archive@core3.amsl.com
Delivered-To: ietfarch-beep-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9053A6D1C for <ietfarch-beep-archive@core3.amsl.com>; Wed, 25 Mar 2009 02:07:25 -0700 (PDT)
X-Quarantine-ID: <35ClAd4tCjLb>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 35ClAd4tCjLb for <ietfarch-beep-archive@core3.amsl.com>; Wed, 25 Mar 2009 02:07:24 -0700 (PDT)
Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 71FD03A6CF8 for <beep-archive@lists.ietf.org>; Wed, 25 Mar 2009 02:07:24 -0700 (PDT)
Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 82FE27BE88D; Wed, 25 Mar 2009 10:08:11 +0100 (CET)
X-Original-To: beepwg@beepcore.org
Delivered-To: beepwg-lista@hl27.dinaserver.com
Received: from smtp-ext.ateme.net (smtp-ext.ateme.net [217.167.236.59]) by hl27.dinaserver.com (Postfix) with ESMTP id 60A497B1DC5 for <beepwg@beepcore.org>; Wed, 25 Mar 2009 09:49:49 +0100 (CET)
Received: from smtp-in.ateme.net (lserver.ateme.net [172.16.0.1]) by smtp-ext.ateme.net (Postfix) with ESMTP id 0B72C10009; Wed, 25 Mar 2009 09:49:47 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by smtp-in.ateme.net (Postfix) with ESMTP id E64A33401B; Wed, 25 Mar 2009 09:49:46 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lserver.ateme.net
Received: from smtp-in.ateme.net ([127.0.0.1]) by localhost (lserver.ateme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeG1aXgNFUF7; Wed, 25 Mar 2009 09:49:46 +0100 (CET)
Received: from [172.16.17.215] (pc-470.ateme.net [172.16.17.215]) by smtp-in.ateme.net (Postfix) with ESMTP id B9F693400E; Wed, 25 Mar 2009 09:49:46 +0100 (CET)
Message-ID: <49C9F02A.60806@ateme.com>
Date: Wed, 25 Mar 2009 09:49:46 +0100
From: Benoit Amiaux <b.amiaux@ateme.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Francis Brosnan Blazquez <francis@aspl.es>
References: <1236942381.17324.180.camel@vulcan.aspl.local>
In-Reply-To: <1236942381.17324.180.camel@vulcan.aspl.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado.
X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.599, requerido 6, autolearn=not spam, BAYES_00 -2.60),
X-Mailman-Approved-At: Wed, 25 Mar 2009 10:08:09 +0100
cc: Vortex <vortex@lists.aspl.es>
cc: BEEPwg <beepwg@beepcore.org>
Subject: [beepwg] Re: [Vortex] A couple of features to limit BEEP no reply attack
X-BeenThere: beepwg@beepcore.org
X-Mailman-Version: 2.1
Precedence: list
Reply-To: b.amiaux@ateme.com
List-Id: <beepwg.beepcore.org>
List-Help: <mailto:beepwg-request@beepcore.org?subject=help>
List-Post: <mailto:beepwg@beepcore.org>
List-Subscribe: <http://beepcore.org/mailman/listinfo/beepwg>, <mailto:beepwg-request@beepcore.org?subject=subscribe>
List-Unsubscribe: <http://beepcore.org/mailman/listinfo/beepwg>, <mailto:beepwg-request@beepcore.org?subject=unsubscribe>
Sender: beepwg-bounces@beepcore.org
Errors-To: beepwg-bounces@beepcore.org
X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus
X-MailScanner-ID: 82FE27BE88D.02BB3
X-DinaScanner-From: beepwg-bounces@beepcore.org

Hello,

Francis Brosnan Blazquez a écrit :
> Hi,
> I've been working on a couple of features that will allow limiting how
> BEEP implements some reply requirements that may be used to setup an
> attack. 
> It would be great to known your opinion about this.

Just a few newbie comments, as an user of the vortex library.

- I'm one of the people forced to use connection termination instead of 
proper connection closure, due to misbehaving peers. It's very easy to 
trigger just pause one peer process and wait for the other side to wait 
indefinitely. I think it's doable to implement this on top of the 
library without changing the BEEP protocol itself, by enforcing, if the 
user wants it, a timeout on expected replies. It would allow at least, 
to try to close the connection properly first, instead of always 
assuming the worst and terminate it.

- About the 'no-reply' option, I'm not sure about whether it's a good 
idea not knowing whether the peer will reply or not. I like the 
semantics of an 'NFN' message much more. It would save bandwidth and not 
disrupt the in-order message mechanism per channel.

Bye!
Benoit Amiaux