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

From: t.petch <[email-masked]>
Date: Wed, 26 Jun 2013 10:44:05 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "t.petch" <[email-masked]>; "Jeffrey Hutzelman" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 25, 2013 11:06 PM
On 6/25/13 10:44 AM, "t.petch" <[email-masked]> wrote:
>It seems to me that call home needs a Signal, like an answerphone
>message (Please Call) and that that signal can be any PDU over any
>protocol but must specify the protocols to be used for the call -
>Netconf over SSH, SNMP over TLS, etc.
>
>Here the signal seems to be a 3-way handshake, in which case the
>destination port would have to differentiate between the protocol
>combinations and so this cannot be a generic mechanism.  The security
>consideration that then comes first to me is a DoS attack via the 3-way
>handshake, nothing to do with SAAG but rather TCPM territory.

I'm not following your analogy, but I agree that there is a DoS attack,
as
there is with any open TCP port, perhaps worse because it can start
expensive asymmetric key algs.  Of course, many people I know claim that
they'd rather see the app get DoS-ed over the device, since it can more
easily overcome such an event.

>It would seem from the I-D that whether the TCP connection is reused,
or
>whether the Netconf client fires up a fresh connection is unspecified;
I
>would assume the latter, to the regular port on the Netconf server.

We (Juniper) have also explored this - using SNMP Traps actually.  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.

<tp>

I am really confused.  If the device/netconf server will not allow
inbound SSH connections,  then I cannot see how your I-D can work.  It
has the device setting up a TCP connection on a port which signals to
the Netconf client/NMS to make an SSH connection to the Netconf
server/device - which cannot succeed because the devices are behind a
firewall which won't allow inbound SSH connections.

So as I understand the design it cannot meet what I understand to be the
requirements.

Tom Petch
</tp>
Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Jun 2013 12:08:52 +0200 (CEST)

Hi,

t.petch <[email-masked]> wrote:
> server/device

No, the device sets up the TCP connection, and then the SSH protocol
is run on this connection.

  o  The NETCONF client accepts an incoming TCP connection and
     immediately starts the SSH client protocol. 

This can probably be made more clear in the text...

/martin

---

From: t.petch <[email-masked]>
Date: Wed, 26 Jun 2013 14:09:00 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, June 26, 2013 11:08 AM

> This can probably be made more clear in the text...

Martin

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:-)

Tom Petch

---

From: Kent Watsen <[email-masked]>
Date: Wed, 26 Jun 2013 16:38:13 +0000

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

Thanks,
Kent

---

From: t.petch <[email-masked]>
Date: Wed, 26 Jun 2013 18:36:25 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "t.petch" <[email-masked]>; "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 26, 2013 5:38 PM

Hi Tom,

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Jun 2013 10:13:59 -0700

> Does it make sense now?   [Martin is right that this section of the draft
There are valid use-cases (e.g, SOHO) for wanting a manageable device
to connect to its manager from behind a firewall. IMO it's up to the
Security Area
to figure out how to do that, not NETCONF, but as long as the proper
reviewers
are found, that is not too important.

Does the client have to be pre-configured with all the keys of the servers
it will accept these connections from in advance?  How does the client
decide
to start an SSH session on the open connection or just drop it?

Thanks,
> Kent

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 28 Jun 2013 21:26:10 +0000

>filters SSH connections still cannot be accessed.  Is this an acceptable

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.

>anything else; each combination of protocols will need a different port

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

---

From: t.petch <[email-masked]>
Date: Sat, 29 Jun 2013 12:23:55 +0100

---- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "t.petch" <[email-masked]>; "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, June 28, 2013 10:26 PM

>filters SSH connections still cannot be accessed.  Is this an
acceptable

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.

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