Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh

[Kent Watsen <[e-mail]>]

> My recollection of the conclusion was that the problem space was
> not big enough, and an SSH-specific solution was inappropriate.  
> A more general approach should be investigated.

If this is still a concern, we might be able to extend the protocol so that it could reverse *any* TCP-based client/server protocol (HTTP, POP, IMAP, etc.)  Is there a perceived need to reverse other protocols? - perhaps to resolve the NAT traversal case?


> ...assuming the security experts approve

So far their objections have primarily been that the solution proposed wasn't integrated into the SSH protocol enough.  There were few comments/concerns regarding security (see my July 12 email for details)


> The main reason given is that the client connection maintenance is
> not worth the resources and coding effort.

Just to clarify, the coding effort on the devices is really quite small.  All that is needed is a daemon to initiate the TCP connection, complete the bootstrap sequence, and then fork/exec `sshd -i` in exactly the same way that `inetd` does.  SSH itself can't differentiate how the underlying transport was established.  Juniper has C-based source code for doing this that we have provided to partners in the past, but we should be able to open source it in order to validate the draft, presuming it moves forward...


Thanks,
Kent