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

[Martin Thomson <[e-mail]>]

I think that David has said almost everything that I was going to.  No
point me wasting my time reiterating it.

One further note on reply-limit that might be related to David's
second point: there are no provisions made for round trip time.  The
serving peer might respond within the specified time, but that time
might have elapsed by the time at the client before then, or before
the response arrives.

Ta,
Martin

On Mar 14, 8:31 am, David Kramer <[e-mail]> wrote:
> 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>
>
>