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

Dear Joe, All,

We indeed are going in circles.

> 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

Thank you for your suggestions. We will.

At the end the decision will be taken in the NETCONF session based on the options available.

Cheers, 
Mehmet 

> -----Original Message-----
> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext
> Joe Touch
> Sent: Friday, November 01, 2013 9:32 PM
> To: Kent Watsen; t.petch
> Cc: Netconf
> Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt
> 
> 
> 
> 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
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf