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

[David Kramer <[e-mail]>]

Francis,

I read your draft proposal for the reply-limit and no-reply features  
and have a few questions and comments.

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?

* 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?

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?

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

* 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.  Can you provide an  
example protocol where it is useful to allow the receiving peer the  
option to decide whether or not it replies?  Also, I suggest renaming  
the feature to "optional-reply".

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.  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?  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?  What is the  
difference?

* 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?

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.

Thanks,
David

On Mar 13, 2009, at 4:06 AM, Francis Brosnan Blazquez wrote:

> Hi,
>
> 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.
>
> Cheers!
> -- 
> Francis Brosnan Blazquez <[e-mail]>
> Advanced Software Production Line, S.L.
> <draft-brosnan-beep-limit-close.txt>