[zeromq-dev] About CURVE and ROUTER sockets
André Caron
andre.l.caron at gmail.com
Sun Jan 18 19:43:42 CET 2015
I've looked at that already and still prefer the router-router setup and
have a convenient solution for discovery, which I'll get back to shortly.
Obviously my immediate curve problem would be solved when using the Harmony
pattern because you always create a new dealer socket for each outbound
connection. However, it seems to me like this is a non-starter because the
Harmony pattern doesn't provide for secure exchange of public keys. How
would you prevent untrusted peers from connecting to your nodes?
The problem I'm trying to solve is running an elastic group of nodes
securly over an untrusted network. My current solution is to use a
directory service which is known to all nodes prior to joining. This
directory service has a well-known endpoint, identity and public key. To
add a new node on the network, the administrator generates a new keypair,
registers the new public key with the directory service and then starts the
new node, which can then connect to the directory and discover other
nodes. Since each node has a secure connection with the directory, it can
discover the endpoint, identity and public key for each peer it wants to
connect to. Then, nodes can connect to each other using whatever protocol
of their choosing.
The pros are that this solution is simple to configure and maintain and
that the directory is not a performance bottleneck. The cons are that it
requires a "central" directory service which is a potential security SPOF,
but that's perfectly acceptable to me for this problem.
Maybe you have a better suggestion, but I don't see how I can do this with
the Harmony pattern.
André
On Sun, Jan 18, 2015 at 1:17 PM, Pieter Hintjens <ph at imatix.com> wrote:
> I'd recommend reading about the Harmony pattern in the Guide.
> Router-to-router topologies tend to be nasty. I don't use them, and
> don't recommend them.
>
> On Sun, Jan 18, 2015 at 5:57 PM, André Caron <andre.l.caron at gmail.com>
> wrote:
> > Hi all,
> >
> > I've been building an example of a router-router setup in which all nodes
> > dynamically discover each other. This currently works like a charm.
> Now,
> > I'm trying to add curve support for this application, which is proving a
> bit
> > confusing despite the API's apparent simplicity.
> >
> > Basically, all my nodes have a single router socket which is used both to
> > connect to other peers and to receive connections. However, I can't
> seem to
> > do this when each peer has their own curve keypair.
> >
> > I have two problems:
> > - the same socket can not be a curve server and client at the same time
> (so
> > I need at least both two sockets, one to connect and one to receive
> > connections); and
> > - a curve client can only set one server key so I cannot connect to
> multiple
> > peers using a single router socket.
> >
> > The first problem I can live with -- have 2 sockets instead of 1 is not a
> > major issue. However, the 2nd problem is really annoying. Creating a
> new
> > socket for each logical outbound connection smes to me like an
> anti-pattern
> > in ZeroMQ.
> >
> > So I'm wondering how I should handle this.
> >
> > I found this on the zmq_curve(7) man page:
> >
> >> A socket can change roles at any point by setting new options. The role
> >> affects all zmq_connect and zmq_bind calls that follow it.
> >
> > Is it safe to assume that I can simply set a new server key before each
> > zmq_connect()?
> >
> > Thanks,
> >
> > André
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150118/39afae7e/attachment.htm>
More information about the zeromq-dev
mailing list