[nanomsg] Re: RFC links
- From: Alex Elsayed <eternaleye@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sat, 10 Aug 2013 14:17:05 -0700
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
Other related posts:
