Re: TCPMUX (RFC 1078) status

[Martin Sustrik <[e-mail]>]

On 16/08/13 20:07, Joe Touch wrote:
>
>
> On 8/15/2013 10:38 PM, Martin Sustrik wrote:
>> On 16/08/13 03:23, Wesley Eddy wrote:
>>
>>>> There are semantics issues to; see draft-touch-tcp-portnames-00 for
>>>> information (this is being revised for resubmission shortly, FWIW).
>>>>
>>> I totally agree.  In fact, in the update to the TCP roadmap [1], we
>>> added TCPMUX to the section on "Historic and Undeployed Extensions",
>>> though it definitely bears further discussion than is currently in
>>> the roadmap.  I think we should add a reference to your portnames doc
>>> to explain why this should be Historic plus check a bit more to see if
>>> the code that's out there is really being used or whether it's just
>>> hanging out like a vestigal limb in the various inetd packages.
>>>
>>> If it's fair to ask Martin ... I'm kind of curious why you might want
>>> to be using it or think it sounds useful?  I think a lot of admins
>>> would be concerned that it could be used to get around port-based
>>> firewall rules, etc.
>>
>> Ok, let me explain.
>>
>> I am coming from enterprise messaging world (think of IBM MQ series,
>> JMS, ActiveMQ, RabbitMQ et c.)
>>
>> Once I was participating on AMQP protocol development (now at OASIS).
>> So, what AMQP and other enterprise messaging products do is exposing a
>> "message broker" on a single TCP port, which then forwards messages to
>> any connected services. As can be seen, single open firewall port can be
>> used to access any internal service.
>
> I don't understand that statement.
>
> Services are currently indicated by the destination port. If there is
> only one destination port available, there is only one service provided
> - because very few services can be identified solely by in-band
> information.

"service" here is used in very generic manner; it means "some 
functionality that can be executed remotely".

>> That being obviously the *wrong* way to do things, I've written ZeroMQ
>> later which takes the strict approach: If you want to expose a new
>> service, you have to use a separate TCP port number.
>>
>> Since then it turned out that this as a limitation that people are most
>> complaining about.
>
> It would be useful if you could be more specific about the problem you
> are trying to solve.
>
> So far I hear "people want one port that serves multiple services". I'd
> like a pony ;-) I.e., just because they want it, doesn't mean it either
> makes sense or should get it.

It's about cutting the corporate process out of the deployment loop.

If every update to your system require opening/closing ports in the 
firewall, the corporate process kicks in and each iteration is going to 
take months if not years.

>> Now, the reason seems to be that ZeroMQ requires you to use different
>> TCP connections for doing different kinds of stuff to avoid head-of-line
>> blocking et c. (think of SCTP channels simulated via TCP)
>
> Different connections don't have anything to do with the use of a single
> port. A single port can serve multiple connections, and yes - that's a
> useful way to avoid HOL blocking.

Ack.

>> What that means is that you have a lot of fine-grained services and as
>> the development of your application proceeds you add more of them,
>> remove them and so on.
>>
>> That in turn requires admins (and the corporate approval process!) to
>> get into the deployment cycle and open the TCP ports as appropriate. The
>> result is that the development basically grinds to halt.
>
> That sounds a lot like the desires of admins is in conflict with the
> desires of your users. I.e., an admin that wants to block anything they
> don't explicitly allow WANTS to block this sort of mechanism too.

Yes. That's the pretty common case. There's a internal conflict at your 
customer's site that you cannot solve. However, despite the conflick, 
you still need to deploy, otherwise you'll go bankrupt.

>> The solution IMO is to preserve the port-based services functionality
>> for those that truly care about security and -- optionally -- support
>> some kind of multiplexer such as TCPMUX for those that care more about
>> short deployment cycle.
>
> TCPMUX won't do what you're asking - if you're asking to block based on
> the service type. If it did, then the sysadmin would just block TCPMUX
> connections to services they didn't know, and you'd be right back where
> you are now (i.e., without TCPMUX).
>
> Again, what is the goal?

Admins are concerned about ports, not TCPMUX services because that's 
what they corporate process requires.

Yes, it isn't sane, but don't expect things to be sane in corporate 
environment.

> (note: the goal of the portnames approach is NOT to provide a single
> multiplexing port; it's to decouple the dest port's two uses - demux
> info and service identifier. the primary reason for portnames is to
> allow more than 65K concurrent/timewait connections to a single service;

The proposal looks good. Once it is widely deployed, I'll be happy to 
drop the TCPMUX idea. Till then though...

> FWIW, I cited it because of its description of the limitations of
> TCPMUX, not because the approach there was relevant here).

Yes. TCPMUX can support max 65536 concurrent connections. Not good, but 
still better than nothing.

>> That being said, IIRC, there's such functionality in WebSockets as well.
>> Open a connection to fixed pot (80) and particular URL (string), then
>> after the initial negotiation, switch to raw TCP mode and hand the
>> connection to whatever application is suppose to handle it. The reason I
>> don't like that solution is that you have to have web server installed
>> to work as a multiplexer, which is kind of strange.
>
> If you want a multiplexer to serve different connections from a single
> service port, you need a multiplexer server (tcpmux daemon, websockets,
> whatever you want to call it).

Ack. The web server is a problem though, because you typically don't 
have control of it. I.e. you cannot randomly plug-in your code into it.

Martin