[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. Münch" <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.
- [beepwg] A couple of features to limit BEEP no re… Francis Brosnan Blazquez
- [beepwg] Re: [Vortex] A couple of features to lim… Francis Brosnan Blazquez
- Re: [beepwg] A couple of features to limit BEEP n… David Kramer
- [beepwg] Re: A couple of features to limit BEEP n… Martin Thomson
- [beepwg] Re: [Vortex] A couple of features to lim… Francis Brosnan Blazquez
- Re: [beepwg] A couple of features to limit BEEP n… Francis Brosnan Blazquez
- Re: [beepwg] Re: A couple of features to limit BE… Francis Brosnan Blazquez
- RE: [beepwg] Re: A couple of features to limit BE… Thomson, Martin
- RE: [beepwg] Re: A couple of features to limit BE… Francis Brosnan Blazquez
- [beepwg] Re: [Vortex] A couple of features to lim… Benoit Amiaux
- Re: [beepwg] Re: A couple of features to limit BE… Francis Brosnan Blazquez
- Re: [beepwg] Re: [Vortex] A couple of features to… Francis Brosnan Blazquez