[nanomsg] Re: RFC links
- From: Alex Elsayed <eternaleye@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 13 Aug 2013 10:38:29 -0700
On Tuesday, August 13, 2013 05:06:02 PM Martin Sustrik wrote:
> Ok, AFAIU, what you want is a two-level service/component design.
>
> The service would be bound to a fixed port number and forward messages
> to components based on name.
>
> Technically, it could be done with classic brokers (there should be an
> option to run RabbitMQ on a user-specified port and have several
> instances running in parellel), TCPMUX (you can implement it in such a
> way that port to be used could be specified by the user) or whatever.
>
> Anyway, the security vulnerability with classic TCPMUX was that someone
> could expose a new service without having to ask the admin first, right?
>
> With two level service/component design you can expose a new component
> within an existing service without asking the admin first. Yet, it may
> be the same evil component as in the previous case. How is this more
> secure?
At the raw protocol level, it doesn't make that much difference. It resolves
the namespacing issues though, and also encourages unrelated things to
actually be treated as such. Components are tightly related to each other in
this case - all of them are aimed at 'stock trading.'
In a future situation where more than one product is building on top of SP
(something I look forward to eagerly) having to coordinate those products
sharing a well-known port would be a problem. Not only might they have
colliding service names, but suddenly you're rolling out an entirely new
product (not just a component) without the admins having any say.
In addition, if someone wants to do application-level filtering/blocking
(which as I pointed out is already done for HTTP), that's not particularly
difficult either - a simple XFOO/XBAR device with some policy in the center
isn't hard to roll up, at which point the difficulty is making a policy. If
the policy is per-product, the difficulty of making one goes down drastically.
If the product ships that, then the admins can even audit that policy on
upgrades if they desire. That allows preventing an 'evil new component'
(although my concern is more 'evil new service').
They could also put that border mux/filter on a separate, very locked-down
box, since XFOO/XBAR don't care what the transport is; TCPMUX is rather too
tied to one paradigm for that. I see the mux/filter as roughly analogous to
Squid in 'reverse proxy' mode, or Apache's mod_proxy or mod_rewrite.
The admin can even use the split to improve security using host policy like
selinux - if the stuff installed as part of one product has the appropriate
security tags set, and they make it so that only stuff from *this* package can
communicate with *this* mux and vice versa (NetLabel/CIPSO even allows
extending that across IP) they can prevent Package B from adding an evil
component to Package A's mux.
So while the service/component distinction doesn't intrinsically improve
security, it makes architectural improvements to security feasible where the
other mechanisms... don't.
In addition, there's the flexibility argument - yes, SP is currently only
specced for TCP. This is not always going to be true; there's the perennial
interest in UDP and multicast, at some point something more like SST, CUSP, or
QUIC may become generally available, etc. Tying 'service/component names' to
TCP is really a step backwards.
Other related posts:
