|
|
|
|
|
|
by theamk
3283 days ago
|
|
|
Note: that answer is mostly incorrect. 1. While simple TCP/IP implementations have SYN flood issues, there are plenty of ways to mitigate them, including SYN cookies and third-party firewalls and load balancers. In fact, the SYN flood mitigations are so good, that most modern attacks are either raw traffic, or higher-level connections. 2. TLS pads your messages to block size (for example, 16 bytes). If your message size varies by a bigger amount, just pad all of your messages manually. This takes 2 lines in modern scripting languages. No need to switch to all-new suite. 3. This is just outright wrong. If you have messages which are "fully encrypted, authenticated, validated", then it means you run ZeroMQ with either TLS or CurveZMQ. Both of them have full protection against replay attack. |
|
|
1. See my reply to theamk above 2. The padding is good, but it needs to be the exact same size for all packets, which implies always using the biggest size. 3. See my reply to theamk above.
We are expecting to run over unreliable networks that may have intermittent dropouts, so connection based solutions would require repeatedly reestablishing the connections, which would be cumbersome. The replay attack protection only exists within a connected sequence.
Overall we think that our solution is simpler and less error prone to configure, and can operate over a wider range of conditions than existing solutions with fewer constraints.