[nanomsg] Re: RFC links
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg <nanomsg@xxxxxxxxxxxxx>
- Date: Sat, 10 Aug 2013 22:55:57 +0200
On 10/08/13 22:24, Alex Elsayed wrote:
And I agree that dynamic ports suck horribly. I just think that
one-port-many-services *also* sucks - on the developer side, making it
convenient for the admin is always a good thing. You want to get your
stuff rolled out as soon as possible, and making it easy for the admin
helps with that.
But on the admin side, you need to ask "Does this have the potential to
be a nightmare inside of a few years?"
Permitting TCPMUX amounts to a very broad firewall exception that can be
extended to more services later *without* the admin giving the okay.
It's giving a significant amount of security and policy leeway to the
developers, and the admin has no ability to lock it down later without
breaking all of the things that rely on it which *were* okay.
Right. This is the relevant topic to discuss.
Let me give an examples to start the discussion with:
Imagine you are a company providing some kind of service via the net.
Your service requires your client's admins to open ports 5555, 5556 and
5557. So far so good.
At some point you have 1000 clients and you implement a new version of
the product that requires port 5558 to be opened. At that point you are
stuck. You cannot deploy the thing until 1000 different admins (god
forbid some of the clients are banks with 3+ month approval process!)
open a new port in their firewalls. There's no way for you go forward
with the development and the issue can literally ruin your business.
So, the obvious solution is to introduce some kind of multiplexing.
That works for a while, then admins catch up and start complaining about
a security hole. And that's where we are with the discussion in this thread.
Now, let's have a look at what happens in the meantime in the real world:
Almost all the traffic nowadays goes through port 80, which then
basically functions as a multiplexer for various web services.
Lately, WebSockets go even one step further. What they provide is
basically TCP functionality multiplexed on port 80.
All in all it looks like the admins have already lost the battle.
Blocking TCPMUX is of little use if you have HTTP open. And you just
cannot close port 80, or everyone else in the company will rip your guts
out.
What follows from above, IMO, is that nanomsg should simply use
WebSockets for multiplexing, but that, as already mentioned, would
require to modify existing web servers which is rarely an option.
So we are back to TCPMUX/ETSN...
Do you see any way out of this dilemma?
Martin
Other related posts:
