Re: TCPMUX (RFC 1078) status
On 21/08/13 19:00, Joe Touch wrote: 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 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? - 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) Martin
Re: TCPMUX (RFC 1078) status
On 21/08/13 20:03, Bob Braden wrote: 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. Hi Bob, thanks for historic insight. Btw, do you remember why TCPMUX was even defined given the above sentiment? 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? Martin
Re: TCPMUX (RFC 1078) status
On 8/22/2013 12:44 AM, Martin Sustrik wrote: On 21/08/13 19:00, Joe Touch wrote: 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 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? 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
Re: TCPMUX (RFC 1078) status
On 20/08/13 17:01, Joe Touch wrote: However, see my other message - it's hard to recommend an approach when 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
Re: TCPMUX (RFC 1078) status
On 8/21/2013 12:50 AM, Martin Sustrik wrote: On 20/08/13 17:01, Joe Touch wrote: However, see my other message - it's hard to recommend an approach when 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. 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. 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. 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. 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. 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
Re: TCPMUX (RFC 1078) status
On 8/21/2013 12:50 AM, Martin Sustrik wrote: ... 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. 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
Re: TCPMUX (RFC 1078) status
On 21/08/13 17:12, Joe Touch wrote: 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. 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. So what would you use for muxing, if TCPMUX is not a good idea? 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. Martin
Re: TCPMUX (RFC 1078) status
On 8/21/2013 8:31 AM, Martin Sustrik wrote: On 21/08/13 17:12, Joe Touch wrote: 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. 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. 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
Re: TCPMUX (RFC 1078) status
On 8/15/2013 6:23 PM, Wesley Eddy wrote: 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. 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
Re: TCPMUX (RFC 1078) status
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
Re: TCPMUX (RFC 1078) status
On 8/20/2013 5:35 AM, Martin Sustrik wrote: 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. 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
Re: TCPMUX (RFC 1078) status
On 8/15/2013 10:19 PM, Martin Sustrik wrote: On 15/08/13 22:18, Joe Touch wrote: 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? It's in the FreeBSD inetd, among others, but to to my knowledge, nobody actually turns it on. There are probably security issues. There are semantics issues to; see draft-touch-tcp-portnames-00 for 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. 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
Re: TCPMUX (RFC 1078) status
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. 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. 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. 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. 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? (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). 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). Joe
Re: TCPMUX (RFC 1078) status
On 8/10/2013 12:29 PM, Wesley Eddy wrote: On 8/10/2013 1:43 AM, Martin Sustrik wrote: 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? It's in the FreeBSD inetd, among others, but to to my knowledge, nobody actually turns it on. There are 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
Re: TCPMUX (RFC 1078) status
On 8/15/2013 4:18 PM, Joe Touch wrote: On 8/10/2013 12:29 PM, Wesley Eddy wrote: On 8/10/2013 1:43 AM, Martin Sustrik wrote: 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? It's in the FreeBSD inetd, among others, but to to my knowledge, nobody actually turns it on. There are probably security issues. 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. [1] http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-00 -- Wes Eddy MTI Systems
Re: TCPMUX (RFC 1078) status
On 15/08/13 22:18, Joe Touch wrote: 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? It's in the FreeBSD inetd, among others, but to to my knowledge, nobody actually turns it on. There are probably security issues. There are semantics issues to; see draft-touch-tcp-portnames-00 for 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
Re: TCPMUX (RFC 1078) status
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. 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
Re: TCPMUX (RFC 1078) status
On 8/10/2013 1:43 AM, Martin Sustrik wrote: 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? 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
Re: TCPMUX (RFC 1078) status
On 10/08/13 21:29, Wesley Eddy wrote: On 8/10/2013 1:43 AM, Martin Sustrik wrote: 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? It's in the FreeBSD inetd, among others, but to to my knowledge, nobody actually turns it on. There are 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
