Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt

[Joe Touch <[e-mail]>]

On 11/1/2013 12:17 PM, Kent Watsen wrote:
>
> Good point, Tom.
>
> Even good old tcpmux (port 1) defined by Jon Postel...
>
> You're right that, if a session-layer were added between TLS and the
> app-protocol, then the necessary indirection would be in place to allow
> IETF to only use one port for all protocols.  I recall Joe Touch
> mentioning working on such a thing as well.   [technically, we'd need two
> ports, one for TLS and another for reverse-TLS]

Not quite; I was working on a way to decouple the service name from the 
port number. That would not involve using a single port for all 
services; that would constrain the number of concurrent connections more 
than now, rather than relieve those constraints.

The original idea is here, though it's evolving and we should be issuing 
an update shortly, as we're implementing it in Linux and FreeBSD:
http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt

> To be honest, I don't know why we're still clinging to ports, given that
> firewalls have long-past moved beyond port-based filtering.  I would
> welcome IETF standardizing something in this area.  In the meanwhile, we
> are where we are, hence the request for a port.

To to be clear, I'm not talking about zeroconf, mDNS, tcpmux, or 
portnames as an alternative. Regardless of the utility of those 
mechanisms, there will always be requests for specific port numbers, 
e.g., to allow network administrators to (try to) identify services by 
port and manage access (e.g., firewalls) accordingly.

I do see the goal here, and the reason for the request. I appreciate 
that the floodgates have not yet opened, but I'm concerned that if 
netconf over SSH or SSL needs separate port numbers for each service 
when connections are initiated in reverse, that the same will be true 
for dozens of other services over SSH or SSL. So this problem isn't 
going away, and I am hoping those involved here can at least:

	- appreciate the problem
	- address it more carefully in this doc
	- explore alternatives, and at least explain why
	they don't currently work

At a minimum that would help us all figure out how to handle this for 
the next service that makes this request.

Joe