-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
Robustness fix blackhole #15610
Robustness fix blackhole #15610
Conversation
…packets Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
…d-io#15595 is fixed" This reverts commit 013e25f. Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
479d9a7
to
03214c0
Compare
Enabling TLS fixes the issue with blackholing https://github.com/etcd-io/etcd/actions/runs/4583625819 |
do not get time to follow up #15595, please clarify why the issue did not affect TLS. |
Proxy we are using is doing byte manipulation on arbitrary byte, with no regards for packets. It just reads the stream of bytes and writes stream of bytes. This means that it doesn't really simulate packet loss line normal network will experience, as it will repackage remaining bytes into new packets. So for receiver behind the proxy they just get arbitrary bytes from stream, without any signs of manipulation (repackaging by proxy provides new control sums). I expect that for TLS this doesn't work as byte manipulation will make data invalid after decryption. So without TLS blackholing is not really packet loss, but a removal of arbitrary bytes from connection stream. This is works more like arbitrary packet manipulation than what can happen in real network. Enabling TLS helps as receiver can detect corrupted byte stream and avoid using corrupted byte stream. |
Thanks for the clarification. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
cc @ahrtr @ptabor