On Saturday, August 10, 2013 10:55:57 PM Martin Sustrik wrote:
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.
Mmm, I'd say that maintaining the old version with bugfixes in a
branch for 3
months is likely not exceedingly onerous, and the *reason* the bank
has such
an approval process is *exactly* the kind of security concerns I'm
talking
about. Exposing a new service is a real problem here - it has new
security
ramifications, it has new policy concerns, etc. The bank admins would
be fully
justified in saying 'hell no' to TCPMUX, because it means they can no
longer
properly audit what is and is not permitted.
That three-month process isn't just *there*, it has a reason to be
there.
Bypassing it isn't the solution.
You can still do development on the current one. Just a.) don't sell
new
installs of the old version b.) Keep a branch that gets bugfixes only
and c.)
encourage migration by your clients.
That's a good practice to have *anyway* whenever you make a
potentially-
incompatible change - see gstreamer 0.10 and 1.0.
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.
In high-security environments, this is locked down too - via a proxy
that does
policy, an application-level firewall, any number of things. However
(and
here's the important part):
Any additional protocol that needs to be special cased this way hugely
*increases* the amount of work the admins need to put in. It ceases to
be
convenient, and instead becomes hugely inconvenient. That can block a
sale
entirely, rather than simply delaying an upgrade.
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?
Well, part of it is that I disagree on the exact nature of the
dilemma, and
another part is that I disagree on your assessment of how HTTP and
WebSockets
fit into it.
The procedural problems with rollout you named aren't because of the
extra
port, they're because of the new service. Making the service not need
another
port doesn't solve the issue - just papers over it until someone
notices.
Martin
