Using the NETCONF Configuration Protocol over Secure SHell (SSH)
draft-ietf-netconf-ssh-06

The writeup alludes to IANA Considerations updates appearing in
the Notes to the RFC Editor, but they're not there - I suppose the
latest revision incorporated them?

I received the following comment by Ólafur Guðmundsson from the DNS review team:

- draft-ietf-netconf-ssh-05.txt                                                
                                                                                
I reviewed this document for content and protocol clarity.                      
The document is in good shape, I have two nits on the document neither          
is a show stoppers.                                                             
-       the document needs to be updated to refer the SSH RFC's that where      
        published after the ID was submitted.                                   
-       To avoid confusion the document may want to say that SSHv1 only         
        clients do not implement subsystem it is a v2 extension.

netconf-prot-12: I can imagine the XML data structures described in this document being used in various application-layer protocols that meet the requirements described in Section 2; however, I'm not sure that it would be reasonable or meaningful for all of those applications to support SSH per 2.4. Do I understand 2.4 to mean that all client and server implementations of NETCONF would have to support SSH (and the transport of NETCONF XML documents over SSH)?

The security considerations section of draft-ietf-netconf-ssh claims:
      If the NETCONF server provides remote shell access through insecure
      protocols, such as rsh or Telnet, care should be taken to prevent
      execution of the NETCONF program when strong user authentication or
      data privacy is not available.  Because it may be difficult or
      impossible in some operating environments to determine whether a
      shell command was accessed over a secure protocol such as SSH or an
      insecure protocol such as Telnet, it may be necessary to disable
      insecure shell access to the system to prevent insecure access to the
      NETCONF program.  

This recommendation seems out of scope for the ssh profile.  It also
seems wrong.  If these other insecure shells allow changing the
configuration of the device using a proprietary CLI, what harm is done
by allowing people to make the changes using netconf over these
transports.  This usage is not standardized, but I don't see that it
creates a new security exposure.  However claiming that installing or
enabling netconf should make other arbitrary changes like disabling
rsh or telnet is unreasonable from an operational standpoint.

While I'm being picky, I'll point out that telnet can be used in a
perfectly secure manner with the starttls option.  I'll admit this is
pure pendanticism on my part and comes from too many years maintaining
an encrypted telnet implementation.