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

["t.petch" <[e-mail]>]

----- Original Message -----
From: "Kent Watsen" <[e-mail]>
To: "Andy Bierman" <[e-mail]>; "t.petch" <[e-mail]>;
<[e-mail]>; <[e-mail]>
Sent: Tuesday, July 19, 2011 10:32 PM

> 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?

Kent

As far as I can see, that is impossible with the architecture that the IETF
currently uses.

When a TCP connection is established, then the port (usually) determines the
'application'.
What happens next is up to the application.  It would have been immensely useful
had
there been a requirement for all applications (ie the layer above TCP/UDP/SCTP)
to start with a
negotiation, who is to be client, are we using security, ....?  Some
applications have
precisely this, but it is specific to the application.

So a generic call home has to be application specific, in which case it cannot
be
generic.

What we can do, and what you could have done, is define a new port which conveys
precisely that semantic, negotiation follows, or else role reversal follows,
become
the client to me instead of the server (which is part of what you have done).
But
it remains application specific and I cannot see any other solution.  Where the
application needs role reversal, allocate a new port; but I do not think that
that is
sufficiently complicated to warrant an I-D.

Tom Petch

> ...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