Subject: TCPMUX (RFC 1078) status

From: Martin Sustrik <[email-masked]>
Date: Sat, 10 Aug 2013 07:43:23 +0200

Hi all,

Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used? 
Is it the case that there are inetd daemons in TCPMUX mode running 
everywhere, or can it be rather considered a dead protocol?

Specifically, if I implement a new TCPMUX daemon how likely I am to 
clash with an existing TCPMUX daemon listening on port 1?

Martin

---

From: Wesley Eddy <[email-masked]>
Date: Sat, 10 Aug 2013 15:29:28 -0400

> clash with an existing TCPMUX daemon listening on port 1?

It's in the FreeBSD inetd, among others, but to to my
knowledge, nobody actually turns it on.  There are
probably security issues.

-- 
Wes Eddy
MTI Systems

---

From: Martin Sustrik <[email-masked]>
Date: Sat, 10 Aug 2013 21:33:29 +0200

> probably security issues.

I am aware of inetd and alternatives. I was more interested whether 
there's some significant deployment base of systems with TCPMUX turned on.

So far, the only relevant info I've found is that TCPMUX was turned on 
by default on SGI Irix systems, but given that these had end of life in 
2006, I guess there's not much of them left out there.

Martin

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Aug 2013 13:18:01 -0700

> probably security issues.

There are semantics issues to; see draft-touch-tcp-portnames-00 for 
information (this is being revised for resubmission shortly, FWIW).

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 15 Aug 2013 21:23:25 -0400

> 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.

[1] http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-00

-- 
Wes Eddy
MTI Systems

---

From: Martin Sustrik <[email-masked]>
Date: Fri, 16 Aug 2013 07:19:49 +0200

> information (this is being revised for resubmission shortly, FWIW).

Nice, however, it requires changes to TCP stack, so even if it succeeds 
it won't be a practical option for at least few years to come.

Martin

---

From: Martin Sustrik <[email-masked]>
Date: Fri, 16 Aug 2013 07:38:02 +0200

> would be concerned that it could be used to get around port-based

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.

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.

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)

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.

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.

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.

Martin

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Aug 2013 10:52:36 -0700

> it won't be a practical option for at least few years to come.

There have been other stack changes that have been deployed fairly quickly.

However, that's not relevant to the reason I cited the doc; the doc has 
a discussion of TCPMUX and its problems.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Aug 2013 11:07:17 -0700

> 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.

> Since then it turned out that this as a limitation that people are most

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.

> 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.

> 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.

> some kind of multiplexer such as TCPMUX for those that care more about

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?

(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; 
FWIW, I cited it because of its description of the limitations of 
TCPMUX, not because the approach there was relevant here).

> 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).

Joe

---

From: Martin Sustrik <[email-masked]>
Date: Tue, 20 Aug 2013 14:35:20 +0200

> - because very few services can be identified solely by in-band

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

> 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.

> useful way to avoid HOL blocking.

Ack.

> 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.

> you are now (i.e., without TCPMUX).

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.

> 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...

> TCPMUX, not because the approach there was relevant here).

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

> 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

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Aug 2013 08:01:12 -0700

> have control of it. I.e. you cannot randomly plug-in your code into it.

You have control over a web server you install. Yes, that would eat one 
IP address, but there are a lot more IP addresses than port numbers 
(i.e., using a port to avoid using a separate IP address consumes the 
wrong resource).

However, see my other message - it's hard to recommend an approach when 
we don't understand the problem you're trying to solve.

Joe

---

From: Martin Sustrik <[email-masked]>
Date: Wed, 21 Aug 2013 09:50:13 +0200

> we don't understand the problem you're trying to solve.

The scenario is simple.

You want admin to open one port in the firewall when the project is 
started. Going through the corporate process at this point is bearable 
and makes sense.

Afterwards, you want to be able to expose arbitrary services through 
that port without having to go through port-opening process over and 
over again.

The services are actually different aspects of the same distributed 
application, say, data distribution service, management service, 
heartbeating service etc. so not requiring additional process for adding 
them makes sense.

The real problem here IMO is how to distinguish between "adding a 
completely new application" -- which should require approval process -- 
and "adding a new component within an existing distributed application" 
-- which should be managed by devs themselves.

Martin

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Aug 2013 08:12:39 -0700

> that port without having to go through port-opening process over and

There's nothing new about multiplexing services over a single port; it's 
a known problem with a few common solutions:
	- dispatch the connections inside your system based on
	in-band info
	- initiate connections inside a handler, and transfer them
	to spawned subprocesses
	- use initial connections to exchange inband info for other
	connections on dynamic ports (as done in FTP)

They each have their challenges.

> heartbeating service etc. so not requiring additional process for adding

Each distinct, independently-useable service may warrant a new port or 
could all be muxed together. Which of these you seek is up to you. 
That's a design decision.

> -- which should be managed by devs themselves.

IMO it's easy - any group of services you want others to be able to use 
independently could justify a new port, but you can always mux them all 
together if you want to avoid additional firewall configuration issues.

I.e., this is your call. But it doesn't appear to have anything to do 
with the notion of a single port to access any *existing* service, which 
is what TCPMUX and its descendants does.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Aug 2013 08:15:42 -0700

...
> that port without having to go through port-opening process over and

One additional point - if you really mean "arbitrary", including 
existing services, I hope you understand that a network operator that 
shuts down ANY current services would conclude they must then block 
yours too.

I.e., if I don't want FTP over the firewall (because it uses cleartext 
passwords), I definitely don't want TCPMUX (which allows FTP), or any 
other "accesses arbitrary services" port.

So that seems like a non-starter, unless by "arbitrary" you mean 
"extensions within your system" - which is how all current ports already 
work.

Joe

---

From: Martin Sustrik <[email-masked]>
Date: Wed, 21 Aug 2013 17:31:32 +0200

> together if you want to avoid additional firewall configuration issues.

So what would you use for muxing, if TCPMUX is not a good idea?

Martin

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Aug 2013 10:00:09 -0700

> So what would you use for muxing, if TCPMUX is not a good idea?

You need to roll your own. The requirements of systems vary widely, as 
do the costs/benefits of different approaches.

I listed a few before, but here's a more comprehensive list:
	- service per message
		demux based on message ID
		use IPC (interprocess comm) to handoff internal
		to your system

	- service per connection
		demux based on the first message in an
		association (TCP or UDP), and either continue to
		forward messages to a different process or handoff
		the connection

	- subservice on different ports
		determine what subservice you want to initiate,
		start it on an ephemeral port, and indicate the
		port number in-band (e.g., as with FTP and others)

Given you want to keep things on a single port, the first two are 
probably more useful.

Joe

---

From: Bob Braden <[email-masked]>
Date: Wed, 21 Aug 2013 11:03:07 -0700

On 8/15/2013 6:23 PM, Wesley Eddy wrote:
> 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 
Wes,

Indeed, TCPMUX is quite historic... it represents a Road Not Taken. My 
memory is a bit hazy after 30+ years,
but I think there was a serious discussion around 1979 of using strings 
instead of contact port numbers
for opening TCP connections. Here is the hazy part... I *think* that 
Chaosnet used strings, and two
well known MIT Daves introduced a proposal to adopt this mechanism for 
TCP. (Also, maybe XNS
used strings? Not sure about that...) The internet working group 
ultimately rejected the idea, I think when Jon Postel argued that 
contact ports provided greater conceptual economy.

Maybe I got this wrong, but in any case I hope that someone else who was 
in the room then will correct me. Jack? Vint? Dave?  Danny?

Bob Braden

---

From: Martin Sustrik <[email-masked]>
Date: Thu, 22 Aug 2013 09:44:27 +0200

>          forward messages to a different process or handoff

So, if I proceed with this option why not use RFC1078 to implement it? 
Why write a new RFC if there's an old one that fits the bill?

Martin

---

From: Martin Sustrik <[email-masked]>
Date: Thu, 22 Aug 2013 09:46:54 +0200

> contact ports provided greater conceptual economy.

Hi Bob, thanks for historic insight. Btw, do you remember why TCPMUX was 
even defined given the above sentiment?

Martin

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Aug 2013 07:57:48 -0700

> Why write a new RFC if there's an old one that fits the bill?

There are two cases to consider:

	- you're creating your own set of services, at which point
	you'll need to roll your own dispatch mechanism

	- you want to use TCPMUX, either for your own services or for
	all services
		you should already realize why that's a dead-end.
		any sysadmin that blocks *any* ports will always
		block TCPMUX

One final reason TCPMUX isn't deployed is that it changes the semantics 
of many existing services, many of which are defined as "if the 
connection opens, then the service is there".

If you roll your own version, you can define your services to accept 
those semantics.

Joe