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

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]

[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