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

From: [email-masked]
Date: Wed, 19 Jun 2013 01:00:54 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network Configuration Working Group of the IETF.

	Title           : Reverse Secure Shell (Reverse SSH)
	Author(s)       : Kent Watsen
	Filename        : draft-ietf-netconf-reverse-ssh-00.txt
	Pages           : 16
	Date            : 2013-06-18

Abstract:
   This memo presents a technique for a NETCONF server to initiate a SSH
   connection to a NETCONF client.  This is accomplished by the NETCONF
   client listening on IANA-assigned TCP port XXX and starting the SSH
   client protocol immediately after accepting a TCP connection on it.
   This role-reversal is necessary as the NETCONF server must also be
   the SSH Server, in order for the NETCONF client to open the IANA-
   assigned SSH subsystem "netconf".

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-reverse-ssh

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "ietfdbh" <[email-masked]>
Date: Wed, 19 Jun 2013 10:02:21 -0400

Hi Kent,

I think your draft needs to target two different audiences - the security
audience for SSH security considerations, and application designers that
want to use reverse-SSH, such as Netconf.

Few people are experts both in hmac and SSH, and in Netconf and YANG.
I think this would be better written as two separate drafts, with different
audiences in mind, even if each draft would be short.

David Harrington
[email-masked]
+1-603-828-1401
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Wednesday, June 19, 2013 4:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-netconf-reverse-ssh-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Network Configuration Working Group of the
IETF.

Abstract:

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 19 Jun 2013 16:40:49 +0200

Can anybody reach dbh via above email?

All my emails to him keep bouncing.
Yet, he is posting from that addess.

Bert

On 6/19/13 4:02 PM, ietfdbh wrote:
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Jun 2013 18:03:19 +0200

Hi Bert,

the address works, as far as I can tell:

Jun 19 18:00:21 trail postfix/smtp[528]: 61EEB5402F3: to=<[email-masked]>, relay=mx2.comcast.net[76.96.40.147]:25, delay=2.5, delays=0.07/0.02/1.4/0.99, dsn=2.0.0, status=sent (250 2.0.0 qG0K1l02J07cNv90BG0LsS mail accepted for delivery)

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "ietfdbh" <[email-masked]>
Date: Wed, 19 Jun 2013 21:19:58 +0200

For anyone who wishes to access/subscribe to the secsh mailing list,
See http://www.ietf.org/wg/concluded/secsh.html

Jeff, I assume that is the list you refer to??

David Harrington
[email-masked]
+1-603-828-1401

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Wednesday, June 19, 2013 7:22 PM
To: ietfdbh
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt

On Wed, 2013-06-19 at 10:02 -0400, ietfdbh wrote:
> Hi Kent,
> 
> I think your draft needs to target two different audiences - the 
> security audience for SSH security considerations, and application 
> designers that want to use reverse-SSH, such as Netconf.

This was discussed two years ago on the ietf-ssh mailing list, which is the appropriate forum for discussion of SSH extensions and protocol changes.  There was much discussion about what port number things should run on, but unfortunately relatively little discussion of the security aspects of running SSH "in reverse" like this.

I haven't read this recent document, but when this came up in 2011, I was concerned about the security aspects of running SSH "in reverse"
like this; it's really not designed for that.  I expressed concerns about the new hmac-* host key algorithms defined in that version, about the layering violations inherent in using them for negotiation, and commented that they don't really provide any operational advantage over using X.509 certificates or pre-shared RSA keys.  Those comments were never really addressed.

The SECSH WG concluded some time ago, but its mailing list is still somewhat active and regularly discusses SSH protocol extensions.  I would be very concerned if the NETCONF WG were to send the IESG an SSH protocol document without the involvement of that group.  I will note that the 2011 discussion included approaches that did not require this level of protocol change, or indeed any.  I'm fine with NETCONF not having chosen one of those approaches, but this really does need to involve people with SSH expertise.

-- Jeff

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Jun 2013 20:16:54 +0000

Hi David,

Thanks for your comments.

My suggestion for partitioning this draft is to extract the
hmac-* family of public host key algorithms into its own draft.
There is precedent for defining new public key algorithms in a
distinct draft given by RFC 6187.  However, this strategy would
retain the YANG module definition in the current draft and thus
doesn't address your stated concern.  That said, please consider:

  1. It is generally hoped that the design of any device
     feature (e.g. a routing protocol) includes a YANG module
     for how it can be managed.  Keeping the YANG module
     definition in this draft is consistent with that goal.

  2. The configuration model has no impact on the protocol
     and hence can be ignored by those who are only interested
     in the protocol/security aspects.  The draft almost says
     this itself in the first paragraph of section 6 (Device
     Configuration).

Another option would to extract the YANG module definition into
its own draft.  As you say, it would be very small, but at least
it would be focused.

And, of course, we could do both options - resulting in a total
of three distinct drafts.

Which of these options you think is best?

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Jun 2013 22:03:20 +0000

Hi Jeff,

You've touched on a lot of points.

First, yes, this was discussed a couple years ago.  I wanted this
submission to indicate it was a continuation of the previous I-D
draft-kwatsen-reverse-ssh-01.  That it doesn't is only because
I didn't see an option to indicate that during submission - I'll
check again...

The discussion from two years ago died because no common ground
could be reached.  It has resurfaced now because operators have
requested the NETCONF WG to define strategies for devices to
"call home" using both NETCONF's transports, SSH and TLS.  The
NETCONF WG has now chartered this work and I volunteered to pick
it up again.

>From a protocol perspective, the solution presented in this draft
is the same as presented in draft-kwatsen-reverse-ssh-01 with one
exception, it now requests an IANA-assigned port, instead of using
port 22, to be consistent with draft-ietf-netconf-rfc5539bis-03,
which makes the same request.

Regarding the security aspects of running SSH "in reverse", this
draft's Security Considerations section has been greatly expanded
to address this concern and I very much hope that the SAAG will
take it up now.  I also hope SAAG will consider the security
aspects of running TLS "in reverse", as one of my comments on
rfc5539bis-03 [1] was that doing so would enable the "client" to
defer sending its client-certificate until after receiving the
server's cert, consistent with draft-agl-tls-encryptedclientcerts
and draft-badra-tls-identity-protection.  Though both of these
drafts are now defunct, it seems that there's sufficient interest
in protecting the client's identity, which a TLS-based "call home"
could only leverage someday if it ran TLS "in reverse" as well.

Finally, regarding the HMAC-* family of public host key algorithms,
I think herein lies a good reason to extract them into a draft of
their own, as it would be a shame for them to distract from the
primary discussion of running SSH (and TLS) in reverse.

[1] http://www.ietf.org/mail-archive/web/netconf/current/msg08075.html

Thanks,
Kent

On 6/19/13 1:21 PM, "Jeffrey Hutzelman" <[email-masked]> wrote:

>>security
>This was discussed two years ago on the ietf-ssh mailing list, which is
>the appropriate forum for discussion of SSH extensions and protocol
>changes.  There was much discussion about what port number things should
>run on, but unfortunately relatively little discussion of the security
>aspects of running SSH "in reverse" like this.
>
>I haven't read this recent document, but when this came up in 2011, I
>was concerned about the security aspects of running SSH "in reverse"
>like this; it's really not designed for that.  I expressed concerns
>about the new hmac-* host key algorithms defined in that version, about
>the layering violations inherent in using them for negotiation, and
>commented that they don't really provide any operational advantage over
>using X.509 certificates or pre-shared RSA keys.  Those comments were
>never really addressed.
>
>
>The SECSH WG concluded some time ago, but its mailing list is still
>somewhat active and regularly discusses SSH protocol extensions.  I
>would be very concerned if the NETCONF WG were to send the IESG an SSH
>protocol document without the involvement of that group.  I will note
>that the 2011 discussion included approaches that did not require this
>level of protocol change, or indeed any.  I'm fine with NETCONF not
>having chosen one of those approaches, but this really does need to
>involve people with SSH expertise.
>
>-- Jeff
>
>
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Jun 2013 23:03:49 +0000

On 6/19/13 4:17 PM, "Mouse" <[email-masked]> wrote:

>My own reaction is that I think it does less violence to ssh's security
>properties for the netconf client to be the ssh server, with the
>"netconf" subsystem being special in that its protocol recognizes that
>the netconf roles are reversed from the ssh roles: the ssh server is
>the netconf client and vice versa.

The issue is that we very much want the managed-device to be the SSH
server.  Consider the following:

Regarding Transport protocol (RFC 4253):

   Devices can ship from their vendors with a TPM chip that embeds
   a private key and a certificate chain of trust to a vendor-specific
   CA.  This can be used as a trust-root for SSH, but only if it's the
   SSH server.

Regarding Authentication protocol (RFC 4252):

   Devices already support inbound SSH and have mechanisms to auth
   users (password, public key, PAM) and associate RBAC permissions.
   Maintaining the client/server roles independent of the transport
   connection's directionality preserves all this.

Regarding Connection protocol (RFC 4254):

   Only clients are allowed to open a "session" on the server
  (section-6.1), and running the "netconf" subsystem requires a
  "session".  

Thanks,
Kent

---

From: Mouse <[email-masked]>
Date: Wed, 19 Jun 2013 16:17:33 -0400 (EDT)

[Feel free to forward to lists - or anywhere else you think fit - if
you like; [email-masked] has decided it doesn't like me, sending broken
challenges in response to my list mail now.]

> There was [...] relatively little discussion of the security aspects
> of running SSH "in reverse" like this.

If the netconf subsystem is too standardized for that already, then I'd
suggest using a new subsystem name for the purpose.

Note that, for these purposes, a netconf client's ssh server need not
be prepared to act as a normal ssh server; it could, for example,
refuse all shell and exec requests.  It also need not accept
connections at all from other than the netconf server.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 19 Jun 2013 13:21:56 -0400

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 19 Jun 2013 15:37:50 -0400

> Jeff, I assume that is the list you refer to??

Yes, that's the group, and [email-masked] is/was the mailing list.
The IETF archives are still subscribed, last time I checked.

-- Jeff

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Jun 2013 07:43:49 +0200 (CEST)

Hi,

> the netconf client and vice versa.

Can you elaborate on the security concerns of the design in
draft-ietf-netconf-reverse-ssh?

/martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 24 Jun 2013 11:40:40 -0400

On Mon, 2013-06-24 at 10:41 -0400, Mouse wrote:

> My major point is that the initial claim
> 
> > the SSH Server, in order for the NETCONF client to open the
> > IANA-assigned SSH subsystem "netconf".
> 
> is wrong.  (Well, technically it's not wrong as worded, but it assumes
> something which does strike me as wrong: it assumes that the NETCONF
> client must be the one to initiate the subsystem open.)  That's what I
> was addressing in writing that it seems to me, from an ssh perspective,
> to be better to keep the ssh protocol as defined and let the netconf
> subsystem's protocol understand that the netconf server is the ssh
> client and vice versa.

I'm trying to stay out of this discussion for now, but I think you're
somehow missing a rather large and important point.

This isn't modifying SSH to be used this way all the time by this new
netconf thing they're designing.  Netconf already exists and already
runs over SSH.  The present work is about enabling the "call home" case,
where the device being managed connects to the user doing the managing,
rather than the other way around.

Back in 2006, the ISMS working group considered a "reverse SSH" approach
similar in concept to what is being discussed today.  We ended up
deciding against it, in part because of the security implications of a
protocol that is basically a device opening a connection and saying "Hi,
I am a server, please tell me your password".

> While only tengentially related, I also note
> 
>    o  The managed device may be deployed behind a firewall that doesn't
>       allow SSH access to the internal network.
> 
> If you are behind a firewall that doesn't allow ssh access, you should
> not be subverting that firewall by arranging to allow ssh access.  If
> the network administrator doesn't want you to do something, you should
> not be doing it, even if you can manage to end-run around the
> implementation of that intent.  While it's possible the restrictions do
> not actually express the admin's intent, it is not the device's place
> to make that decision.

No, we're generally talking about _managed network devices_.  They're
likely being deployed by the same person who set up the firewall.  And
the firewall rule is likely not "SSH is evil, no one should be allowed
to use SSH"; its probably "I don't want the entire Internet banging on
the SSH servers on my users' machines".  Using a reverse connection
allows the connection to be set up as an outgoing connection made by the
managed device to a known management system.  That's a much smaller
exposure than allowing incoming connections, even from a narrow set of
sources, and it aligns with the end-to-end principle by putting the
knowledge of where the trusted management system is in the managed
endpoint instead of in some "smart" device in the middle of the network.

-- Jeff

---

From: Joe Touch <[email-masked]>
Date: Mon, 24 Jun 2013 09:43:00 -0700

+1.

The primary reason for including SAAG in this was because they had 
already considered a similar directionality issue with SSH, not 
specifically because this service was asking for a new port.

IMO, the port considerations for SSH in general apply to NetConf over 
SSH as well.

Joe

---

From: Kent Watsen <[email-masked]>
Date: Mon, 24 Jun 2013 19:55:47 +0000

>I am a server, please tell me your password".

...after verifying the devices host key - we certainly wouldn't expect the
client to try logging into any server.  Further, we recommend the host-key
be a certificate containing the server's identity, though

When it was looked at before, did anyone find an attack?   - I can't think
of one that doesn't involve spoofing the device's private key, but all
bets are off already in that case

Thanks,
Kent

---

From: t.petch <[email-masked]>
Date: Tue, 25 Jun 2013 15:44:21 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>; "Mouse"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, June 24, 2013 8:55 PM
> bets are off already in that case

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.

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.

Tom Petch

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Jun 2013 22:06:58 +0000

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

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

Thanks,
Kent

---

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

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