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

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=A0am, David Kramer <[email protected]> wrote:
> Francis,
>
> I read your draft proposal for the reply-limit and no-reply features =A0
> and have a few questions and comments.
>
> First, regarding reply-limit:
>
> * The reply-limit feature could be implemented by the library =A0
> implementing the BEEP protocol. =A0The library could automatically =A0
> terminate the session whenever it determined that the remote peer was =A0
> taking too long to reply to requests. =A0Clients using the library could =
=A0
> override this timeout value on a per-session and per-channel basis. =A0
> Can you provide an example showing why it is better to make this a =A0
> feature of the BEEP protocol instead of just implementing this in the =A0
> library?
>
> * When using reply-limit, if peer A takes longer than the limit to =A0
> reply, is it considered a protocol violation if peer B doesn't =A0
> terminate the session? =A0In other words, who's responsibility is it to =
=A0
> enforce the reply-limit? =A0Both peers? =A0Or just the receiving peer?
>
> Regarding "no-reply":
>
> * Because the "no-reply" feature still allows replies, a downside of =A0
> using "no-reply" instead of NFN messages is that each peer still has =A0
> to keep track of all of the un-replied-to messages it has sent, in =A0
> order to verify that each RPY that does arrive has a valid msgno. =A0The =
=A0
> peer's memory usage will increase for each message it sends that the =A0
> remote peer does not reply to. =A0Do you agree that this feature would =
=A0
> be unusable in low-memory environments, unless the peer stopped =A0
> validating the msgno of incoming RPY messages?
>
> * The issue you mention about the NFN scheme not supporting =A0
> correlation between requests and replies was first raised because I =A0
> suggested that the NFN scheme could be used to implement support for =A0
> out-of-order replies. =A0As was pointed out to me, and I agree, the =A0
> application would have to do extra work to correlate these out-of-
> order replies, which could instead be handled by the msgno value in =A0
> the frame header if the protocol were changed to allow out of order =A0
> RPYs. =A0But in the cases where you do not want a reply, this issue does =
=A0
> not apply.
>
> * The "no-reply" feature seems mis-named. =A0You are not creating a =A0
> channel in which there are no replies, you are creating a channel in =A0
> which replies are optional, and the choice is made by the receiver, =A0
> not the sender. =A0This does not seem like a useful feature to me. =A0I =
=A0
> would understand a feature that allowed for a channel on which replies =
=A0
> were not allowed at all (eg, it is against the rules to send a RPY =A0
> when you receive a MSG on the channel) and I would understand a =A0
> feature that allowed for channel on which the sender specified whether =
=A0
> or not a RPY was needed (eg, the sender could send a NFN if it didn't =A0
> want a RPY, and it could send a MSG if it did want a RPY)... but I =A0
> don't understand the "no-reply" feature, because it allows the =A0
> receiver to decide whether or not to respond. =A0Can you provide an =A0
> example protocol where it is useful to allow the receiving peer the =A0
> option to decide whether or not it replies? =A0Also, I suggest renaming =
=A0
> 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 =
=A0
> right to terminate the session. =A0Why is this not sufficient for =A0
> protecting against the no reply attack? =A0Can't all of this just be =A0
> implemented by the library? =A0For example, if the client of the library =
=A0
> asks to close a channel, and the remote peer refuses, the library =A0
> could automatically terminate the session -- or it could terminate the =
=A0
> session on the third failed attempt -- or whatever policy you want. =A0
> And if the client of the library sends a message but receives no reply =
=A0
> after some timeout, the library could automatically terminate the =A0
> session. =A0Does any of this have to be part of the protocol? =A0What is =
=A0
> the advantage of broadcasting your reply-limit to the other peer? =A0If =
=A0
> I tell you my reply-limit is 10, and you take 11 seconds to reply on =A0
> channel 0, I'll terminate the session. =A0But I could do the same even =
=A0
> if I didn't tell you what my reply-limit is, right? =A0What is the =A0
> difference?
>
> * In the case where a peer is is performing the permanent negative =A0
> close attack on only one channel, I could see the use for a "channel =A0
> terminate" message that the peer could send over channel 0 to indicate =
=A0
> that it would no longer consider valid any messages sent with that =A0
> channel number. =A0Do you think this would solve the problem =A0
> effectively? =A0If the remote peer is performing the permanent negative =
=A0
> close attach on all channels (or just on channel 0) then terminating =A0
> the session is already the appropriate response, right?
>
> You goal of limiting BEEP no reply attacks is good, but I don't yet =A0
> see any compelling reasons to make the features you have described =A0
> part of the protocol. =A0If you can describe some profiles where these =
=A0
> features would be useful it might be easier for me to understand the =A0
> 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 <[email protected]>
> > Advanced Software Production Line, S.L.
> > <draft-brosnan-beep-limit-close.txt>
>
>