Subject: [Netconf] Comments on draft-ietf-netconf-reverse-ssh-03.txt

From: Alan Luchuk <[email-masked]>
Date: Tue, 25 Mar 2014 11:17:57 -0400 (EDT)

Hello,

Here are comments on  draft-ietf-netconf-reverse-ssh-03.txt.  I know of
no serious technical issues with this draft.  These comments mostly 
identify typos, comment on wording, or seek clarification.  I hope the
comments are helpful; do what seems appropriate with them.

Regards,
--Alan

 ------------------------------------------------------------------------------
 Alan Luchuk               SNMP Research, Inc.          Voice:  +1 865 573 1434
 Senior Software Engineer  3001 Kimberlin Heights Road  FAX:    +1 865 573 9197
 luchuk at snmp.com        Knoxville, TN  37920-9716    http://www.snmp.com/
 ------------------------------------------------------------------------------

Typos
-----

The first batch of these have incorrect capitalization of "SSH Server".
I think "Server" should be "server" because in these specific cases,
"server" is not part of a section title and is not a proper noun.

Line 22:

s/the SSH Server, in order for/the SSH server, in order for/
          ^                            ^

Line 151:

s/the role of SSH Server is/the role of SSH server is/
              ^                             ^

Line 153:

s/opened on the SSH Server/opened on the SSH server/
                    ^                        ^

Line 213:

s/the SSH Server protocol/the SSH server protocol/
          ^                       ^

Line 348:

s/the SSH Server's host name/the SSH server's host name/
          ^                          ^

Line 264:

s/the mangement element can verify/the management system can verify/
        ^^      ^^^^^^^                  ^^^      ^^^^^^

Line 289:

s/the mangement system only/the management system only/
        ^^                        ^^^

Line 347:

s/host keys in locally cached/host keys in a locally cached/
                                           ^

Line 352:

s/Man-in-th-/Man-in-the-/
          ^^         ^^^

Section 2.1, Page 3, Second Paragraph:  (wording)
-------------------------------------------------

The second paragraph seems vague.  Would something along the lines of 
the following text be clearer and/or more specific?

   The reason for this restriction is that the SSH protocol is designed 
   to be initiated by a client connecting to a server.  SSH is designed 
   to resist a specific set of security threats in accordance with this 
   usage.  Because NETCONF requires that a client provide a username which
   the NETCONF server must authenticate before starting the NETCONF protocol, 
   in addition to the security provided by SSH, NETCONF's use of reverse 
   SSH is considered secure.  Reverse SSH MUST NOT be used for purposes 
   other than NETCONF because the general-purpose use of reverse SSH might 
   have security vulnerabilities that require a thorough security analysis
   to mitigate.

Section 4, Page 4:  (wording)
-----------------------------

The current text reads:

   o  The NETCONF server initiates a TCP connection to the NETCONF
      client on the IANA-assigned Reverse SSH port YYYY.

   o  The TCP connection is accepted and a TCP session is established.

Because the server and client roles are swapped during the initial TCP 
connection, would the following text help clarify the role reversal?

   o  The NETCONF server initiates a TCP connection to the NETCONF
      client which listens on the IANA-assigned Reverse SSH port YYYY.
             ^^^^^^^^^^^^^

   o  The NETCONF client accepts the TCP connection and a TCP session 
      is established.

Section 5, Page 5, First Paragraph:  (wording)
----------------------------------------------

The current text reads:

   "When the management system accepts a new incoming connection, it
    needs to authenticate the remote peer.  Ultimately, this entails
    identifying the peer and verifying its SSH host key.

    Due to Reverse SSH having the network element initiate the TCP
    connection,"

Because the server and client roles are swapped during the initial TCP 
connection, would the following text help clarify the role reversal?

   "When the management system (normally the NETCONF client) accepts 
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    a new incoming connection, it must authenticate the remote peer.  
    Ultimately, this entails identifying the peer and verifying its 
    SSH host key.

    Due to Reverse SSH having the network element (normally the NETCONF
                                                  ^^^^^^^^^^^^^^^^^^^^^
    server) initiate the TCP connection,"
    ^^^^^^^

Section 5, Page 6, First Paragraph:  (clarification)
----------------------------------------------------

The current text reads:

   "However, configuring distinct host keys on the management system
   doesn't scale well, which is an important consideration to a network
   management system.  A more scalable strategy is to have the network
   element's host key signed by a common trusted key, such as a
   certificate authority.  Thus, the mangement system only needs to
   trust a single public key, which vouches for the authenticity of the
   various network element public keys."

Please help me understand this.  The way this paragraph is written, it
is not clear to me why "signing each network element's host key with a 
common trusted key" scales better than "configuring distinct host keys 
on the management system".

In either of these two situations, it seems like an administrator must
do work for each network element.  In one case, it is configuring host
keys, in another, it is signing each network element's host key.  If
anything, it seems like signing a host key for each network element 
requires _more_ work for each network element, so it seems like this 
would scale less well.

What am I missing here?

Section 7, Page 7, Third Paragraph:  (wording)
----------------------------------------------

In a few places in the third paragraph, and possibly in other places
in the document, would changing "needs to" to lowercase "must", or 
lowercase "should", make the document a little more concise?  Example:

   "Note that since the SSH server would have to be configured to know 
    which IP address it needs to connect to," 
                        ^^^^^^^^

to:

   "Note that since the SSH server would have to be configured to know 
    which IP address it should connect to," 
                        ^^^^^^

---

From: Kent Watsen <[email-masked]>
Date: Thu, 27 Mar 2014 16:02:06 +0000

Hi Alan,

Awesome comments - thanks!

I applied all fixes mentioned below to my working copy of what will be
-04, so you'll have to wait until then to see the diff.  The reason I'm
not posting -04 now is because I'm still trying to work out an issue with
Applicability Statement and with the port's name.

Below are my detailed responses.

Cheers,
Kent

>Typos

I fixed all the issues you found.

>Section 2.1, Page 3, Second Paragraph:  (wording)

I forwarded this comment to Steve Hanna, who wrote the Applicability
Statement.  At first I was just going to ask if he was OK with the
proposed text, but then I started thinking that I didn't agree with it.
That is, I think that the SSH protocol does require mutual authentication
and that NETCONF's requirement that it be possible to derive a "username"
from the transport doesn't change that.  I'm still OK limiting Reverse SSH
to just NETCONF, but I want the reason to be accurate.  I'm now waiting
for a response from Steve on this.

>Section 4, Page 4:  (wording)

I'm not sure about this change since these bullet-points are preceded by
the line "From the NETCONF server's perspective:".  The intent is to only
explain the NETCONF-server's perspective, and to let the next section
provide the client's perspective.   Currently, neither section references
the remote peer, so that its text remains squarely focused on its side of
the connection.  What do you think?

>Section 5, Page 5, First Paragraph:  (wording)

I changed the wording to be more clear, but did it another way, please let
me know if you think it's OK!

>Section 5, Page 6, First Paragraph:  (clarification)

Very good question.  Of course it comes down to how the device's "entity
certificates", as they are called, is distributed.  In the best case, as
described in the zero-touch draft, the device would ship from factory with
a built-in entity-certificate, signed by a trust-chain to its vendor's
well-known trust anchor.  In this case, there is no additional effort
needed, the management system only needs to trust the vendor's certificate
for its well-known trust anchor.  For cases where the device doesn't ship
from factory with an entity-certificate, introducing PKI is still
advantageous as it decouples the management-system from direct
involvement, such that it could be outsourced to some 3rd-party.  Makes
sense?  What update would you like to see in the draft?

>Section 7, Page 7, Third Paragraph:  (wording)

I changed "needs to" to "is to" for this cited location and another I
found.

Thanks again,
Kent