Subject: Re: [Netconf] [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt

From: Kent Watsen <[email-masked]>
Date: Thu, 20 Jun 2013 00:37:53 +0000

On 6/19/13 6:13 PM, "Joe Touch" <[email-masked]> wrote:
>I was party to the discussion of this issue during the original draft
>(see archives of 5/24/2011), and thought there was appreciation that
>there was no reason to need a new port for this service.

This is why the -01 draft from before was using port 22, but
the problem is that there will be a conflict if the application
may want to run real SSH on port 22.

>Regarding the netconf draft, that might warrant a single port, but again
>not two ports for the different directions.

The same principle applies here.  Yes, we could repurpose the
NETCONF port (830), but then there will be a port conflict if
the application server itself wants to be managed via NETCONF
on port 830.  Besides, this draft is truly about reversing SSH,
any SSH subsystem could be run on top of it...

>As I noted on this list in 2011, directionality should be negotiated
>in-band, not by port number.

This seem fine (assuming it's done in the SSH Transport protocol,
such the device is the SSH server and the application is the SSH
client), except for one thing, it's not implementable *today*.
Optimistically, it might take a couple years for implementations
to support it, if ever.  Case in point, did you know that after
more than two years, there is still not a single implementation
for RFC 6187 (x.509v3 certs for SSH)?

In contrast, I have running code for the solution presented in
the current draft that I hope to post to code.google.com as a
reference implementation.  Mind you that this implementation
doesn't make use of all the the host-key algs we'd like, but
it works with at least two SSH-implementations (Petrov's patch
to OpenSSH and a Java library called J2SSH Maverick).

A little off topic, but the -00 draft I submitted before, in
2011, worked with *every* SSH implementation I tried, without
any patches necessary.  But I chose to model this draft after
the -01 proposal because I believe it's better to leverage the
algorithm negotiation built into SSH and I have running code
for the common case of the device running openssh and the
management app written in Java.

Thanks,
Kent

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jun 2013 18:02:26 -0700

> may want to run real SSH on port 22.

Why is this a conflict in that way? It's just a matter of who initiates 
the connection, and who initiates the security exchange after that. 
I.e., why wouldn't this be most naturally implemented as "real SSH on 
port 22"?

> on port 830.

The same answer above applies.

>  Besides, this draft is truly about reversing SSH,

I understand why it has not yet been *implemented*, but disagree that it 
is not *implementable*.

> to OpenSSH and a Java library called J2SSH Maverick).

I sincerely hope you are posting code that uses some arbitrary dynamic 
port, rather than squatting on an assigned port.

However, it would be useful to explain further the issue here. So far, 
all I can tell is that it would be easier to pull up a demo 
implementation using a separate port, but there doesn't seem to be 
enough justification as to why this is a separate *service* than forward 
SSH.

Joe