[Vortex] A couple of features to limit BEEP no reply attack
Robert M. Münch
robert.muench at robertmuench.de
Fri Mar 13 13:06:05 CET 2009
Am 13.03.2009, 12:06 Uhr, schrieb Francis Brosnan Blazquez
<francis at aspl.es>:
> I've been working on a couple of features that will allow limiting how
> BEEP implements some reply requirements that may be used to setup an
> It would be great to known your opinion about this.
Hi Francis, I just read your proposal and I think it's a good addition.
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.
"A BEEP peer asking for "reply-limit" support that receives a greetings
reply without such feature MAY close the connection (and should log a
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.
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
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.
Just my two cents.
Robert M. Münch
Mobile: +49 (177) 245 2802
More information about the Vortex