[dwviel]

Great question. Some issues with ZeroMQ:

It uses TCP/IP which has security issues that can lead to resource exhaustion. The SYN is sent but the sender never acknowledges the reply, so the server simple keeps the resource reserved waiting for the sender to get back to it.

It leaks information in the message even if fully encrypted. Just the size of the message in a control system usually tells you what it is.

It doesn’t protect against packet replay, which is particularly serious for control systems. An attacker can just sniff some messages, which are fully encrypted, authenticated, validated, etc., and save them for later. Then, when needed, resend them to reenact the former actions. E.g. “open valve” message is captured. Later, the “open valve” message is resent to, once again, open the valve, even though the legitimate user may have closed it and expect it to be closed.

[theamk]

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.

[dwviel]

Great comments.

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.

[theamk]

1. Your reply was "SYN cookies can be a solution, but it has limitations, and to overcome those limitations requires changes to the TCP protocol." Can you tell me more about these limitations? I thought the SYN cookies work pretty well. And they are pretty simple to setup -- in fact, they need no setup at all, as they are already enabled by default in the recent distributions.

2. Right, so how does your protocol solve a padding problem? Why won't this method work with ZeroMQ?

3. As I was saying above, this is still wrong. Both TLS and CurveZMQ are protected against replay attack.