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

---- Original Message -----
From: "Kent Watsen" <[email protected]>
To: "t.petch" <[email protected]>; "Martin Bjorklund" <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Friday, June 28, 2013 10:26 PM
On 6/26/13 1:36 PM, "t.petch" <[email protected]> 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.

<tp>
OK, so it is limited to reverse SSH (as opposed to a generic call home)
and that is what the I-D says, so that is ok.

But ... I would like to see a note added that the server/device must be
prepared to receive any SSH PDU and act appropriately and not just
assume it is netconf.  I am wondering if there is a Security
Consideration in there somewhere but cannot put my finger on one.

Tom Petch

</tp>

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