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

[Robert M. Münch]

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
> attack.
>
> 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.  
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.

"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.

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.


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
http://www.robertmuench.de