[nanomsg] Re: RFC links
- From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 14 Aug 2013 23:08:19 +0300
Hi Martin,
On Sat, Aug 10, 2013 at 11:55 PM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
>> 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.
>
Isn't the good way to solve the problem is to declare that your
service requires ports 5550-5650? One may declare that port 5555 used
for requests 5556 for heartbeats and 5557-5650 are reserved for future
use.
This way if admins trust you, they will open ports ahead of time. If
they don't, they should probably consider TCPMUX and ETSN evil too,
because it allows to add another service at any time.
Everything else sounds like cheating. If you want to cheat, there is
another way of cheating. Do heartbeats for every reserved port to make
sure they work up to the point you need them for something more
useful.
It's not like I'm a man of principle. I really sympathize with people
who can't easily open the ports :) Just looking at the problem from
this point of view makes the problem solvable without loosing the
ability to monitor network traffic for each service separately.
--
Paul
Other related posts:
