[beepwg] A couple of features to limit BEEP no reply attack
Francis Brosnan Blazquez
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 <fra...@aspl.es>
Advanced Software Production Line, S.L.
Francis Brosnan Blazquez
Balazs,
> I just ran through it quickly, but it sound really great. In the
> environment where we use BEEP we had to take care of this "manually"
> and
> it would be really great if that reply-limit was built in the
> protocol.
Thanks for your comments!
> Balazs
David Kramer
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
> <draft-brosnan-beep-limit-close.txt>
Martin Thomson
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
> > Francis Brosnan Blazquez <fran...@aspl.es>
Francis Brosnan Blazquez
> 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
> 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
> I think that David has said almost everything that I was going to. No
> point me wasting my time reiterating it.
Ok.
> 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.
Though I see your point, I find no easy solution to implement a
round-trip discovery extension, which, again, can be blocked in the same
way.
It is expected that BEEP peers will provide appropriate values for this
reply-limit which includes such round-trip delay.
Cheers!
> Ta,
> Martin
--
Francis Brosnan Blazquez <fra...@aspl.es>
Thomson, Martin
RTT discovery is performed by every TCP stack. It's part of working out the necessary window size to maximize throughput. I don't know if this information is made available by any TCP stacks, but it isn't impossible to measure. Even above TCP where retransmits could interfere its' probably still doable.
I'd still say that the main concern I have is that your interpretation of what constitutes a "protocol violation" is too narrow a view. More holistically, a badly behaving peer needs to be treated as such, regardless of where the errors occur. Niceties like proper channel and session closure are luxuries - a badly behaving peer does not deserve to be treated in such a civilised fashion.
Cheers,
Martin
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
Francis Brosnan Blazquez
> Sorry about the delay in responding...
;-) No problem..
> RTT discovery is performed by every TCP stack. It's part of working
> out the necessary window size to maximize throughput. I don't know if
> this information is made available by any TCP stacks, but it isn't
> impossible to measure. Even above TCP where retransmits could
> interfere its' probably still doable.
Fine. I could place such mention so developers can consider it. However,
as you are guessing, such APIs are missing especially on windows (pretty
much like TCP maximum negotiated segment size).
> I'd still say that the main concern I have is that your interpretation
> of what constitutes a "protocol violation" is too narrow a view. More
> holistically, a badly behaving peer needs to be treated as such,
> regardless of where the errors occur. Niceties like proper channel
> and session closure are luxuries - a badly behaving peer does not
> deserve to be treated in such a civilised fashion.
Ok. Just to point reply-limit is to protect a peer from BNRA especially
over channel 0 rather giving especial care to badly behaving peers.
After this initial poll I think there are few interest in reply-limit
feature. I still think this is a remaining issue to solve and, with some
degree, this "silence" confirms close session is not being used at this
moment due to problems it carries, especially in an untrusted/public
environment. No problem, next issue...
..what about "optional-reply"? What's your opinion about it?
Cheers!
> Cheers,
Benoit Amiaux
Francis Brosnan Blazquez a écrit :
> 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.
Just a few newbie comments, as an user of the vortex library.
- I'm one of the people forced to use connection termination instead of
proper connection closure, due to misbehaving peers. It's very easy to
trigger just pause one peer process and wait for the other side to wait
indefinitely. I think it's doable to implement this on top of the
library without changing the BEEP protocol itself, by enforcing, if the
user wants it, a timeout on expected replies. It would allow at least,
to try to close the connection properly first, instead of always
assuming the worst and terminate it.
- About the 'no-reply' option, I'm not sure about whether it's a good
idea not knowing whether the peer will reply or not. I like the
semantics of an 'NFN' message much more. It would save bandwidth and not
disrupt the in-order message mechanism per channel.
Bye!
Benoit Amiaux
Francis Brosnan Blazquez
> Optional reply might be better solved by creating a new message type,
> as David suggested. That way there is no need to have conditional
> logic to handle the message.
Though a NFY message (one-way notification) would be really interesting,
it will not solve the general request/response pattern without requiring
the application layer to place some MIME message-id to correlate such
interaction.
I have no problem with this though this suppose an approach change where
it is better accepted using MIME as part of the solution.
After giving a try to the problem and perceiving what people say, if
this is the preferred direction (having a new one-way notification frame
type), which is fine for me, I think proper consequences must be taken
on async channels. They won't be required with this new situation.
Cheers!
Francis Brosnan Blazquez
> Just a few newbie comments, as an user of the vortex library.
>
> - I'm one of the people forced to use connection termination instead
> of
> proper connection closure, due to misbehaving peers. It's very easy
> to
> trigger just pause one peer process and wait for the other side to
> wait
> indefinitely. I think it's doable to implement this on top of the
> library without changing the BEEP protocol itself, by enforcing, if
> the
> user wants it, a timeout on expected replies. It would allow at
> least,
> to try to close the connection properly first, instead of always
> assuming the worst and terminate it.
>
> - About the 'no-reply' option, I'm not sure about whether it's a good
> idea not knowing whether the peer will reply or not. I like the
> semantics of an 'NFN' message much more. It would save bandwidth and
> not
> disrupt the in-order message mechanism per channel.
Thanks for your comments Benoit. It seems there are consensus with these
two points. Cheers!
> Bye!
> Benoit Amiaux