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

[Kent Watsen <kwatsen%juniper.net@localhost>]

On 6/26/13 1:36 PM, "t.petch" <ietfc%btconnect.com@localhost> wrote:

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

I would think so - this is what Juniper has been doing for almost a decade
now and I've never heard this raised as an issue before.



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


By "generic", the draft is trying to say that the solution applied to
solve this problem can equally well be applied to other protocols that use
SSH for their transport.

That said, I'll just add that the port number does not have to be bound to
how the application might use the SSH connection.  For instance, when a
Junos device connects to our management server, yes, it knows it can open
the "netconf" subsystem, but it also knows all the other subsystems it can
start...and it does!  For instance, it will open additional SSH channels
for SFTP, notifications, packet captures, etc.  It would've been easier if
SSH defined a subsystem-discovery mechanism, but we worked around that too.

Thanks,
Kent