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

"Thomson, Martin" <Martin.Thomson@andrew.com> Mon, 23 March 2009 17:58 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 BA3163A6BFD for <ietfarch-beep-archive@core3.amsl.com>; Mon, 23 Mar 2009 10:58:56 -0700 (PDT)
X-Quarantine-ID: <YvFia4mkyXy4>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -1.723
X-Spam-Level:
X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_05=-1.11]
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 YvFia4mkyXy4 for <ietfarch-beep-archive@core3.amsl.com>; Mon, 23 Mar 2009 10:58:55 -0700 (PDT)
Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 3C3563A6BBF for <beep-archive@lists.ietf.org>; Mon, 23 Mar 2009 10:58:54 -0700 (PDT)
Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 1C41F7CF207; Mon, 23 Mar 2009 18:59:34 +0100 (CET)
X-Original-To: beepwg@beepcore.org
Delivered-To: beepwg-lista@hl27.dinaserver.com
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by hl27.dinaserver.com (Postfix) with ESMTP id 8A3BE7CF47E for <beepwg@beepcore.org>; Mon, 23 Mar 2009 18:59:17 +0100 (CET)
X-SEF-Processed: 5_0_0_910__2009_03_23_13_19_17
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 23 Mar 2009 13:19:17 -0500
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Mar 2009 12:59:12 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Subject: RE: [beepwg] Re: A couple of features to limit BEEP no reply attack
Date: Mon, 23 Mar 2009 12:59:12 -0500
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF1058BCB58@AHQEX1.andrew.com>
In-Reply-To: <1237382051.5260.273.camel@vulcan.aspl.local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [beepwg] Re: A couple of features to limit BEEP no reply attack
Thread-Index: Acmny4WBF+zMpXAuQhiXESmDvUbRKwECCWpA
References: <1236942381.17324.180.camel@vulcan.aspl.local> <9471C896-E007-4745-8A49-885D51B6B130@apple.com> <ffc28d54-b4e6-4eaa-ba21-2d6d9f94a2b8@v38g2000yqb.googlegroups.com> <1237382051.5260.273.camel@vulcan.aspl.local>
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "Francis Brosnan Blazquez" <francis@aspl.es>, "Martin Thomson" <martin.thomson@gmail.com>
X-OriginalArrivalTime: 23 Mar 2009 17:59:12.0623 (UTC) FILETIME=[12AF27F0:01C9ABE1]
X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado.
X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.6, requerido 6, autolearn=not spam, BAYES_00 -2.60, SPF_HELO_PASS -0.00),
cc: Vortex <vortex@lists.aspl.es>
cc: 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: 1C41F7CF207.6014F
X-DinaScanner-From: beepwg-bounces@beepcore.org

Sorry about the delay in responding...

RTT discovery is performed by every TCP stack.  It's part of working out the necessary window size to maximize throughput.  I don't know if this information is made available by any TCP stacks, but it isn't impossible to measure.  Even above TCP where retransmits could interfere its' probably still doable.

I'd still say that the main concern I have is that your interpretation of what constitutes a "protocol violation" is too narrow a view.  More holistically, a badly behaving peer needs to be treated as such, regardless of where the errors occur.  Niceties like proper channel and session closure are luxuries - a badly behaving peer does not deserve to be treated in such a civilised fashion.

Cheers,
Martin

> -----Original Message-----
> From: beepwg-bounces@beepcore.org [mailto:beepwg-bounces@beepcore.org]
> On Behalf Of Francis Brosnan Blazquez
> Sent: Wednesday, 18 March 2009 6:14 AM
> To: Martin Thomson
> Cc: Vortex; beepwg@beepcore.org
> Subject: Re: [beepwg] Re: A couple of features to limit BEEP no reply
> attack
> 
> Hi Martin,
> 
> > I think that David has said almost everything that I was going to.
> No
> > point me wasting my time reiterating it.
> 
> Ok.
> 
> > One further note on reply-limit that might be related to David's
> > second point: there are no provisions made for round trip time.  The
> > serving peer might respond within the specified time, but that time
> > might have elapsed by the time at the client before then, or before
> > the response arrives.
> 
> Though I see your point, I find no easy solution to implement a
> round-trip discovery extension, which, again, can be blocked in the
> same
> way.
> 
> It is expected that BEEP peers will provide appropriate values for this
> reply-limit which includes such round-trip delay.
> 
> Cheers!
> 
> > Ta,
> > Martin
> --
> Francis Brosnan Blazquez <francis@aspl.es>
> Advanced Software Production Line, S.L.
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]