[Bro-Dev] 0MQ security considerations

[Jonathan Siwek]

> > upon reconnection. In 0MQ, the 'tcp' transport is considered a
> > "disconnected" TCP transport, meaning that the connectivity state of peers is
> > transparent to applications.
> 
> Oh, that's actually something that could bite us in another way as
> well. When Bro starts talking to Bro, there's some state that's
> exchanged initially just after the connection has been setup and
> before "normal" messages start being exchanged. If we don't learn
> about a reconnect (which is I how interpret your statement above), we
> can't do that state exchange.

If the acceptor needs to recognize new connections, that doesn't seem
well-suited to it, but if the client can say "I'm new" that could work.

Also, the idea of having a listening socket and an accepted socket fd
like in traditional socket APIs isn't there in 0MQ.  You just have
a socket bound at one endpoint that may accept connections from multiple
endpoints, but anything written to the bound socket is going to be
received by all connected endpoints.  There's a ZMQ_PAIR that does
communication between just two endpoints, but only a single peer can be
connected at one time.  I think we really need try to use 0MQ as a
parallelism framework and not just as a networking library or else it's
going to be a struggle to get things to work.
 
> This *may* be something we could get around by changing parts of the
> protocol but (1) that would make switching to 0mq quite a bit more
> complicated, and (2) I'm not sure right now whether it would work at
> all.

In general, I'm getting the feeling that even the original idea of "let's
just try replacing the socket code with 0MQ and increment upon that" isn't
going to be easy, and to really take advantage of 0MQ's strengths requires
some redesign.

> Is there a way around this, like not doing transparent reconnects and
> setting up new connections instead?

Not that I saw.

- Jon