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

[t.petch <ietfc%btconnect.com@localhost>]

----- Original Message -----
From: "Kent Watsen" <kwatsen%juniper.net@localhost>
To: "t.petch" <ietfc%btconnect.com@localhost>; "Martin Bjorklund" <mbj%tail-f.com@localhost>
Cc: <ietf-ssh%NetBSD.org@localhost>; <netconf%ietf.org@localhost>
Sent: Wednesday, June 26, 2013 5:38 PM
On 6/26/13 9:09 AM, "t.petch" <ietfc%btconnect.com@localhost> wrote:

>
>Yes!  That is exactly what I said.  But what I also said is that Kent
>says
>" It works fairly well for automating the discovery of devices with
>static IPs
>on a reachable network, but not at all when the devices are behind a
>firewall that won't allow inbound SSH connections."
>
>Works not at all ..  when the devices are behind a firewall.
>
>So if devices behind a firewall is a requirement, then the design fails
>to meet it.
>
>If that is not a requirement, why has Kent raised it (and it has been
>raised before)?
>
>This should confuse everyone (not just me:-)


Hi Tom,

By saying a firewall wouldn't allow inbound SSH connections, let's
simplify and assume the firewall doesn't allow any inbound TCP
connections, but outbound TCP-connections are fine.

The proposed solution is to repurpose the TCP connection initiated from
behind the firewall.  Once the network management application accepts
the
TCP connection, it can pass the accepted TCP socket into its SSH client
of
choice (e.g. a SSH library like J2SSH or even using OpenSSH's
"ControlPath" parameter).  On the "device" side, the accepted TCP
connection can be passed into an SSH server - for instance using
`sshd -i`
exactly like `inetd` would do when listening on port 22.

Does it make sense now?   [Martin is right that this section of the
draft
could be clearer]

<tp>
Yes, that I understand.

But ... the firewalls I know, at least the better ones, can look for and
reject PDU of protocols such as SSH, regardless of which ports the TCP
connection is using.  So in that sense, a device behind a firewall that
filters SSH connections still cannot be accessed.  Is this an acceptable
limitation?

My other point is that I cannot see how this is a generic solution as
the I-D claims.  You need something to signal that this three-way TCP
handshake is for Netconf over SSH and the only parameter I can see is
the port number, so this I-D cannot be used for anything else over
anything else; each combination of protocols will need a different port
number.

Tom Petch

</tp>


Thanks,
Kent