Skip to content
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

In pathological cases, L5 can misinterpret data as control information #22

Open
ghost opened this issue Mar 24, 2019 · 1 comment
Open

Comments

@ghost
Copy link

ghost commented Mar 24, 2019

This issue is low priority, as it is triggered only by unlikely circumstances.

Under the following circumstances, the L5 protocol can misconstrue data as control information, leading to undesirable effects. Not all implementations are necessarily vulnerable to these problems, but the specification should probably be adjusted to resist them.

  1. A node sends a packet that coincidentally has the data openstream; for example, it might be the last part of bulk data that ends in that string. The receiving node assumes that it should start an L5 session, but the node that send the accidental openstream isn't aware of this and doesn't respond correctly. Both nodes break.
  2. Due to poor luck, the string chosen as the end-of-session marker is sent by one end or the other. The receiving end assumes the connection is closed, while the other continues to try to communicate. Both nodes break.

These issues could both be resolved by adding some kind of marker to distinguish control and data messages. This would also provide the benefit of being able to use a simple closestream to end a session, avoiding the necessity of generating and exchanging a random end marker. There are several possibilities for the form this marker could take, but the one I gravitate towards is beginning data messages with a specific character. The most obvious choice is d, for data.

@ghost
Copy link
Author

ghost commented Mar 24, 2019

Another possible solution is adding the ability to specify that a packet is a control message in the L3 format. This has the potential to be used by other L4 or L5 protocols, if any are ever developed.

Yet another possible fix is to require that these control strings be escaped if they occur alone in a message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

0 participants