-
Notifications
You must be signed in to change notification settings - Fork 354
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Metadata-pushes rate is not capped on responder, may lead to server resources starvation #865
Comments
Hey! First of all, we appreciate issues and bug reports! However, sometimes it is HARD to figure out what the issue is about. In certain: how to reproduce it; what is the root cause; what is possible solutions to mitigate it! Having no such info just makes it challenging for maintainers to help submitter / improve project by resolving the issue. Therefore, we created issues' templates for that purpose so the issue submitter can express all important points that maintainers need in order to resolve an issue. Otherwise, if thoughts were not expressed clearly just make the issue useless and waste maintainers' time on figuring out what was said. Therefore, please respect maintainers by following general issues' templates if you submitting an issue! Thanks in advance.
The same as for point 1 - any code that reproduces that, or is it just a theoretical assumption that has no proof? On the
WDYT @rstoyanchev @rwinch? Cheers, |
I think metadata pushes are not meant to be used for sending a lot of data or to be sent very frequently. We can add some basic rate limiting mechanism that allows up a certain number of pushes and/or metadata size within some period of time. That can be much lower than the general 16 MB frame size from the spec. Also since metadata isn't subject to fragmentation then we are not aggregating fragments and an application can use interception to reject large metadata pushes or any metadata pushes as a workaround. |
Closes rsocketgh-865 Signed-off-by: Rossen Stoyanchev <rstoyanchev@vmware.com>
Closes rsocketgh-865 Signed-off-by: Rossen Stoyanchev <rstoyanchev@vmware.com>
External clients can start hundreds of thousands of metadata-pushes over multiple connections.
If metadata-push handler is present and It does not implement rate limiting on its own, then server is subject to resource starvation attack.
If metadata-push handler is absent, then exception with stacktrace is created for every metadata-push - this just consumes cpu cycles. With sufficiently large number of metadata-pushes RSocket becomes unresponsive.
Problem worsens with websocket transport of this repository. By default It sets frame size limit to ~16MB - this opens opportunity for memory overflow given there may be arbitrarily large number of concurrent metadata-pushes with size close to said size limit.
The text was updated successfully, but these errors were encountered: