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

[Francis Brosnan Blazquez]

Hi David, 

> First, regarding reply-limit:
> 
> * The reply-limit feature could be implemented by the library  
> implementing the BEEP protocol.  The library could automatically  
> terminate the session whenever it determined that the remote peer was  
> taking too long to reply to requests.  Clients using the library could  
> override this timeout value on a per-session and per-channel basis.   
> Can you provide an example showing why it is better to make this a  
> feature of the BEEP protocol instead of just implementing this in the  
> library?

Ok. In general, having a BEEP peer with pending replies is a problem yet
not solved. This drives to a situation where users start to doing the
only thing that can solve this, assuming session close requirements,
that is, to shutdown the session. It is important to note this is a
protocol violation.

Knowing this, you can think you can implement a per-session or
per-channel policy (out of the BEEP context) to take a measure, but, at
end, having a BEEP session with only one channel (including 0) with
pending replies yields to the same solution, again, you have to shutdown
the session (mainly because you'll never fulfill BEEP close requirements
in such context). 

With the time you find people asking "why my app gets blocked on session
or channel close?". When you answer to this question people find they
have to shutdown the connection to ensure, in every case, they will
never be blocked. 

So, as a general conclusion I find that:

1) All solutions comes to shutdown the session in the case of pending
replies.
2) All of them are always activated via timeout.
3) Current solution is a protocol violation. 

Assuming these factors I find convenient providing a standard API,
especially to site administrators, to model the solution that is
currently accepted (or at least I think so) rather making all people to
go into a creative process (which again, it is a protocol violation).

>From the perspective of a general purpose BEEP application server, makes
sense providing an API that will provide site administrators with the
basis to implement and configure session timeout as currently accepted
(based on channel numbers, profiles running on them and their network
setup/bandwidth) but within the standard.

(Note: I refer to API as the BEEP server side configuration that will be
available if reply-limit or a similar feature appears).

However, and I think the most important, you shouldn't implement this in
the library without being supported by the protocol. I mean, having a
BEEP peer that closes connections its a protocol violation. BEEP clearly
states you can't do this. However, the feature will allow, under
required situation, and supported by the protocol, to close after such
timeout, which was previously advised.

> * When using reply-limit, if peer A takes longer than the limit to  
> reply, is it considered a protocol violation if peer B doesn't  
> terminate the session?  In other words, who's responsibility is it to  
> enforce the reply-limit?  Both peers?  Or just the receiving peer?

I didn't think about this ;-) 

Assuming "reply-limit" is meanly designed to allow BEEP peer to advice
its intention to consider a protocol violation to not reply within a
period, I don't find a protocol violation to not proceeding after
timeout expiration. 

I'm not sure what would be the best option for this. Maybe you can
provide some insights on how to proceed here.

> Regarding "no-reply":
> 
> * Because the "no-reply" feature still allows replies, a downside of  
> using "no-reply" instead of NFN messages is that each peer still has  
> to keep track of all of the un-replied-to messages it has sent, in  
> order to verify that each RPY that does arrive has a valid msgno.  The  
> peer's memory usage will increase for each message it sends that the  
> remote peer does not reply to.  Do you agree that this feature would  
> be unusable in low-memory environments, unless the peer stopped  
> validating the msgno of incoming RPY messages?

Yes, I agree. "no-reply" only disables channel close requirements. Maybe
it is time for a true one-way notification.

My intention was never to have one-way notification but a way to protect
BEEP listeners against no reply attack. 

> * The issue you mention about the NFN scheme not supporting  
> correlation between requests and replies was first raised because I  
> suggested that the NFN scheme could be used to implement support for  
> out-of-order replies.  As was pointed out to me, and I agree, the  
> application would have to do extra work to correlate these out-of- 
> order replies, which could instead be handled by the msgno value in  
> the frame header if the protocol were changed to allow out of order  
> RPYs.  But in the cases where you do not want a reply, this issue does  
> not apply.

Yes, I agree.

> * The "no-reply" feature seems mis-named.  You are not creating a  
> channel in which there are no replies, you are creating a channel in  
> which replies are optional, and the choice is made by the receiver,  
> not the sender.  This does not seem like a useful feature to me.  I  
> would understand a feature that allowed for a channel on which replies  
> were not allowed at all (eg, it is against the rules to send a RPY  
> when you receive a MSG on the channel) and I would understand a  
> feature that allowed for channel on which the sender specified whether  
> or not a RPY was needed (eg, the sender could send a NFN if it didn't  
> want a RPY, and it could send a MSG if it did want a RPY)... but I  
> don't understand the "no-reply" feature, because it allows the  
> receiver to decide whether or not to respond.  

Ok.

> Can you provide an  
> example protocol where it is useful to allow the receiving peer the  
> option to decide whether or not it replies?  

As an example we can have all request/response protocols created by
people. From my experience with Vortex I find people have little or no
interest in having all content flushed in both directions, etc (close
requirements). 

However, they find really useful having a quick way to close the
connection, no matter if there are pending replies. In fact, I've
announced this draft in the Vortex list and it is having a well
reception (especially no-reply feature).

>From the perspective of a client requesting for some resource at a
listener, it is too hard to wait for all pending replies to outstanding
messages. Think about those cases where you want to stop/exit from your
client application (no matter pending messages).

> Also, I suggest renaming  
> the feature to "optional-reply".

Ok. I see it more appropriate.

> Regarding the over-all goal of limiting BEEP no reply attack:
> 
> * Anytime a remote peer does not behave the way you want, you have the  
> right to terminate the session.  

I don't think so. BEEP clearly states you can't do this. This is the
problem I see. Reducing the issue, you have under the same
classification BEEP peers that are just taking long to generate a reply,
with BEEP peer not behaving properly. I think you can't apply the same
solution for both.

> Why is this not sufficient for  
> protecting against the no reply attack?  Can't all of this just be  
> implemented by the library?  For example, if the client of the library  
> asks to close a channel, and the remote peer refuses, the library  
> could automatically terminate the session -- or it could terminate the  
> session on the third failed attempt -- or whatever policy you want.   
> And if the client of the library sends a message but receives no reply  
> after some timeout, the library could automatically terminate the  
> session.  Does any of this have to be part of the protocol?  

I think this is not a technical reason. I find that the solution applied
at the end it's the same, that is, shutting down the session. 

However not providing a solution within the BEEP protocol will leave
people with an insane pattern, which is a protocol violation, that is
becoming an accepted practice making protocols that requires "patience",
like relay servers or central software with agents, to be not
practicable (unless the same toolkit is used).

> What is  
> the advantage of broadcasting your reply-limit to the other peer?  If  
> I tell you my reply-limit is 10, and you take 11 seconds to reply on  
> channel 0, I'll terminate the session.  But I could do the same even  
> if I didn't tell you what my reply-limit is, right?  

Yes.

> What is the  
> difference?

Mainly because you can go closing BEEP session because you find it is
more appropriate. This is a protocol violation. Again, one of the BEEP
power relay in the fact that peers won't do this. 

"reply-limit" only seek to enforce BEEP peers, especially on channel 0,
to reply to request performed. These replies shouldn't take long
assuming they are start and close channel requests.

Broadcasting reply-limit is just a notification that you will be
implementing such timeout. Without it, remote BEEP peer is allowed to
take all the time he wants to process your request, with no limit, and
you can't close its session. Doing so, without an advice of any form, is
not what BEEP standard says.

> * In the case where a peer is is performing the permanent negative  
> close attack on only one channel, I could see the use for a "channel  
> terminate" message that the peer could send over channel 0 to indicate  
> that it would no longer consider valid any messages sent with that  
> channel number.  Do you think this would solve the problem  
> effectively?  If the remote peer is performing the permanent negative  
> close attach on all channels (or just on channel 0) then terminating  
> the session is already the appropriate response, right?

I think permanent negative attack, especially with public BEEP services
used by untrusted peer, have only one solution: to shutdown the session
after some tries. 

At the end, even having such new invalidation message, you will have to
also modify what BEEP says about closing a channel, stating that
channels "invalidated" are ignored during the close process, which is
elaborated form of saying "just close the session".

> You goal of limiting BEEP no reply attacks is good, but I don't yet  
> see any compelling reasons to make the features you have described  
> part of the protocol.  If you can describe some profiles where these  
> features would be useful it might be easier for me to understand the  
> purpose of the features and comment on them more effectively.

I disagree. I think there are enough reason, at least for
"optional-reply". Rather placing some examples, let me summarize with
all points:

>From my experience with Vortex and hearing people that use it, I
perceive "optional-reply" as really useful. The explanation is simply:
most of people only want to do request/response protocols/applications
and mostly all of them finds annoying current close requirements. 

In fact, I think most of these people are shutting down connection
before closing to avoid any lock issue. It is worth to mention, again,
this is an insane pattern, hides bugs (you don't have to face with
missing replies, etc) and disables an important part of BEEP, the
session close, which is beneficial for the user if properly used.

For the case of "reply-limit", I think it is an good attempt to
conciliate those profiles that could take advantage of current close
requirements as defined by RFC3080 and those protocols that only uses
the exchange part of the BEEP protocol. 

At the end David, I can place some examples but we will both end up
saying either "you can close the session via library" or "you can close
the session via timeout already notified via reply-limit". 

"reply-limit" provides a chance to the developer to decide if its
protocol cares about replies or not, avoiding the general pattern "in
case of doubt, shutdown the session".  Not accepting "reply-limit" will
imply that the current practice will be applied to all protocols and, as
a side effect, will invalidate a complete section from the RFC which
describes session close requirements.

In the other hand, taking the problem with a different point of view,
maybe "reply-limit" is not necessary because nobody cares about close
requirements, that is, all people is shutting down the session with no
problem at all. Can someone say something about this?

Thanks for your comments David. Cheers!

> Thanks,
> David

-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.