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

Francis Brosnan Blazquez <francis@aspl.es> Mon, 16 March 2009 08:55 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 BAB3428C11B for <ietfarch-beep-archive@core3.amsl.com>; Mon, 16 Mar 2009 01:55:01 -0700 (PDT)
X-Quarantine-ID: <az3PEXS5iqTc>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -0.294
X-Spam-Level:
X-Spam-Status: No, score=-0.294 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3]
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 az3PEXS5iqTc for <ietfarch-beep-archive@core3.amsl.com>; Mon, 16 Mar 2009 01:55:00 -0700 (PDT)
Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 92CAE3A6AAC for <beep-archive@lists.ietf.org>; Mon, 16 Mar 2009 01:55:00 -0700 (PDT)
Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 759A278870A; Mon, 16 Mar 2009 09:55:35 +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 896D478870A for <beepwg@beepcore.org>; Mon, 16 Mar 2009 09:55:26 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by dolphin.aspl.es (Postfix) with ESMTP id 12D9D740F8; Mon, 16 Mar 2009 09:52:21 +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 piCq+7zC+aQd; Mon, 16 Mar 2009 09:52:16 +0100 (CET)
Received: from [192.168.0.132] (barracuda [10.0.0.4]) by dolphin.aspl.es (Postfix) with ESMTP id 820B974054; Mon, 16 Mar 2009 09:52:16 +0100 (CET)
From: Francis Brosnan Blazquez <francis@aspl.es>
To: "Robert M." =?ISO-8859-1?Q?M=FCnch?= <robert.muench@robertmuench.de>
In-Reply-To: <op.uqqbwfagtb1j4j@sony-laptop>
References: <1236942381.17324.180.camel@vulcan.aspl.local> <op.uqqbwfagtb1j4j@sony-laptop>
Content-Type: text/plain
Organization: Advanced Software Production Line, S.L.
Date: Mon, 16 Mar 2009 09:55:19 +0100
Message-Id: <1237193719.5260.27.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>
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
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: 759A278870A.5D430
X-DinaScanner-From: beepwg-bounces@beepcore.org

Hi Robert,

> Hi Francis, I just read your proposal and I think it's a good addition.  
> Some comments/remarks:
> 
> 1. reply-limit: I think getting better timeout control not only for  
> channel 0 but for the other channels as well makes a lot of sense. I  
> couple of weeks ago I posted a question regarding timeout handling to the  
> list but got no answer to it. Especially if one want to use BEEP in a P2P  
> network manner (like implementing CHORD on top of it) it's mandatory to  
> get timeout information on a connection & channel base. This is because  
> peers can enter/leave a P2P ring at any time, the network is broken,  
> you-name-it. The timeout triggers the stabilization round of the P2P ring.

Ok.

> "A BEEP peer asking for "reply-limit" support that receives a greetings  
> reply without such feature MAY close the connection (and should log a  
> diagnostic error)."
> 
> Wouldn't it be better in this case to allow the BEEP peer askining for  
> "reply-limit" support to further allow to use the send reply-limit on its  
> side? So, one can "force" timout handling on the initiator side to keep  
> things up & running.

I'm not sure to understand this Robert, I mean, the intention with
reply-limit is to protect the BEEP side that start channels and issues
MSG frames from being blocked (especially if it is a listener server
that initiates exchanges) pretty much like you describe. Can you
elaborate on this?

> How about a feature to make a counter-proposal on the limit? Example:  
> Listner sends reply-limit of 5s, the reciever knows that on the current  
> hardware etc. the maximum time to fullfill a request can be 10s. In this  
> case a counter proposal of 10s would be sent. The listener is free to  
> accept or reject the counter-proposal. If it's rejected connection can be  
> closed or the listern can decide to keep it until the initial reply-delay  
> is reached.

Ok. I'll think about this. Maybe this can be left to be configured by
the site administrator. Giving to the client the power to control
timeout may be dangerous in situations where the listener receiving the
connection issue MSG frames or start channels.

> 2. no-reply: Supporting "server-to-client notifications" is a very good  
> addition too! That's what I use a lot. It allows for a bunch of  
> push-applications and is IMO one of the strength of BEEP.
> 
> Again I think a fallback to "listern announced that no-reply is required,  
> client rejects but doesn't close connection, listern is free to decided to  
> continue assuming no-reply mode" makes sense.

I think so. That's why I used MAY rather MUST to leave site
administrators and application developers to close or not the connection
based on the kind of protocol being developed on top of BEEP. 

Thanks for your comments Robert!

> Just my two cents.
-- 
Francis Brosnan Blazquez <francis@aspl.es>
Advanced Software Production Line, S.L.