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

[Francis Brosnan Blazquez]

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 at aspl.es>
Advanced Software Production Line, S.L.