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

Francis Brosnan Blazquez <francis@aspl.es> Wed, 25 March 2009 10:50 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 3F4843A6938 for <ietfarch-beep-archive@core3.amsl.com>; Wed, 25 Mar 2009 03:50:15 -0700 (PDT)
X-Quarantine-ID: <37Yuy74q9y1q>
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.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, 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 37Yuy74q9y1q for <ietfarch-beep-archive@core3.amsl.com>; Wed, 25 Mar 2009 03:50:14 -0700 (PDT)
Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 31B3E3A6894 for <beep-archive@lists.ietf.org>; Wed, 25 Mar 2009 03:50:13 -0700 (PDT)
Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 311C27B7581; Wed, 25 Mar 2009 11:50:54 +0100 (CET)
X-Original-To: beepwg@beepcore.org
Delivered-To: beepwg-lista@hl27.dinaserver.com
Received: from dolphin.aspl.es (unknown [212.170.101.196]) by hl27.dinaserver.com (Postfix) with ESMTP id 8ADA579A23A for <beepwg@beepcore.org>; Wed, 25 Mar 2009 11:50:41 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by dolphin.aspl.es (Postfix) with ESMTP id 08C886C00A; Wed, 25 Mar 2009 11:46:56 +0100 (CET)
X-Virus-Scanned: amavisd-new at dolphin.aspl.es
Received: from dolphin.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kukc+a2qshse; Wed, 25 Mar 2009 11:46:52 +0100 (CET)
Received: from [192.168.0.132] (barracuda [10.0.0.4]) by dolphin.aspl.es (Postfix) with ESMTP id D2F116C009; Wed, 25 Mar 2009 11:46:51 +0100 (CET)
Subject: Re: [beepwg] Re: [Vortex] A couple of features to limit BEEP no reply attack
From: Francis Brosnan Blazquez <francis@aspl.es>
To: b.amiaux@ateme.com
In-Reply-To: <49C9F02A.60806@ateme.com>
References: <1236942381.17324.180.camel@vulcan.aspl.local> <49C9F02A.60806@ateme.com>
Content-Type: text/plain
Organization: Advanced Software Production Line, S.L.
Date: Wed, 25 Mar 2009 11:50:33 +0100
Message-Id: <1237978233.20276.55.camel@vulcan.aspl.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Content-Transfer-Encoding: 7bit
X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado.
X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.499, requerido 6, BAYES_00 -2.60, RDNS_NONE 0.10),
cc: Vortex <vortex@lists.aspl.es>
cc: BEEPwg <beepwg@beepcore.org>
X-BeenThere: beepwg@beepcore.org
X-Mailman-Version: 2.1
Precedence: list
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: 311C27B7581.E860E
X-DinaScanner-From: beepwg-bounces@beepcore.org

Hi Benoit,

> 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.

Thanks for your comments Benoit. It seems there are consensus with these
two points. Cheers!

> Bye!
> Benoit Amiaux
-- 
Francis Brosnan Blazquez <francis@aspl.es>;
Advanced Software Production Line, S.L.