Open Stack

On 04/25/2013 12:52 PM, Eric Windisch wrote:
> I've read through this and had a discussion with Simo on IRC for clarity, before posting.
> 
> It isn't a terrible proposal. My biggest concerns are the following, as pertains to signing-only:
> 
> 1) Keyserver lookups on both sides, not just one-sided, on signing.
> 2) Practical requirement for the matchmaker for signing, even for AMQP.
> 
> On the encryption side, PKI has the same requirements, but using slower algorithms. If we accept that the typical use-case will be message signing, then we may prefer to optimize for that, not for encryption. Perhaps we could figure out a middle-ground here with a single sender-side lookup and a token from the keyserver? That might be a slippery slope.
> 
> The practical requirement for the matchmaker is a HUGE one. This means that not only does a keyserver lookup have to be performed when sending each message, but also a matchmaker lookup. The matchmaker would perform local routing decisions, rather than making those decisions on a broker. These routing decisions must be made locally such that the peers on both sides of the connection are known in advance, for keying purposes.
> 
> This is already the case with ZeroMQ, for which it is a necessity, but it is not presently the case for AMQP. Demanding the use of the matchmaker for AMQP eliminates most, if not every, advantage that one might perceive out of Rabbit/Qpid (as presently designed). Basically, ZeroMQ starts to look a hell of a lot more attractive in this model, to the degree that it would become silly to consider running our present Rabbit/Qpid drivers with signing enabled.
> 
> Of course, the Rabbit/Qpid drivers could be rewritten for a distributed broker model, mirroring what we have with ZeroMQ.
> 
> Hell, I'm the ZeroMQ driver maintainer - I don't mind if everyone wants to switch to ZeroMQ, or switch to the messaging model it advocates. I'd be happy for it. However, I'm not the one suggesting we do this - but the community should realize that Simo is effectively, whether he knows it or not, pushing for either the adoption of ZeroMQ or the rewrite of our RabbitMQ/Qpid drivers. It might not be obvious now, but that is the path this particular road leads to. It isn't a bad road, but we shouldn't be surprised when we get to the end.
> 
> The proposal to use PKI for signing, despite what might otherwise be complexities and difficulties around that proposal, would not significantly change our messaging model. This kind of gets thrown out as soon as we introduce encryption, however, where we fall back into the matchmaker trap such that we can determine the remote peer's identity for encryption purposes.

I don't think he was advocating a matchmaker requirement.  In fact, we
spoke about this specifically.  The idea is what in cases when we're
sending a specific service+host, the key used reflects that.  In the
case where we're sending to any one of a specific service, the key is
service-wide.  Is that acceptable?  Maybe.  We have to look at when each
case is used.

In nova, the case that we're *most* concerned about is anything
involving compute nodes.  In the case of compute, we're almost always
talking directly to a specific compute node.  There's one case where we
broadcast to all computes, but I think we can probably re-engineer that
case.

A service-wide example would be scheduler.  We're not nearly as
concerned about the scheduler, so a key for scheduler.* is probably
acceptable.

-- 
Russell Bryant