Subject: [Netconf] draft-ietf-netconf-call-home-03.txt

From: Alan Luchuk <[email-masked]>
Date: Thu, 15 Jan 2015 12:02:04 -0500 (EST)

Hello,

Kent, thanks for your hard work on the call home and other drafts.

After carefully reading draft-ietf-netconf-call-home-03.txt here are 
a few comments.

Sections 2.1/3.1
----------------

After the establishment of the TCP connection:

-  The NETCONF/RESTCONF server _immediately_ starts the SSH-server or
   the TLS-server protocol;

-  The NETCONF/RESTCONF client _immediately_ starts the SSH-client or
   the TLS-client protocol;

Is it possible for a race condition to occur that might cause SSH or TLS
connection problems? 

Section 3.2
-----------

I think this section does a pretty good job of describing the issues, 
listing the alternatives, and the pros/cons of each alternative.  That 
said, I had to read this section several times very carefully.  I _think_ 
I understand what it is saying.  Does the following briefly summarize the
ideas?

After the TCP connection is established, the NETCONF/RESTCONF client has
two problems:

-  How can the NETCONF/RESTCONF client identify the NETCONF/RESTCONF server?
   (Which server is the client talking to?)

-  How can the NETCONF/RESTCONF client _be certain_ of the identity of the
   NETCONF/RESTCONF server it is talking to?

Possibilities:

-  The client can use IP address (from TCP source address of the TCP
   connection) to identify the server.

   -  In advance of the first connect, the client must know what server 
      is at what IP address.  This has limited use cases, so is not 
      recommended.

-  To identify the server, the client can use the host key or certificate 
   presented by the server.

   -  In advance of the first connect, the client must know which host
      key or certificate will be sent by which server.  From the host
      key or certificate, the client can be assured of the identity of
      the server.  This does not scale well, so is not recommended.

-  To identify the server, the client can use the server identity embedded 
   in the host key or presented by the server.

   -  In advance of the first connect, the client must know the trust
      anchor that signs the server's host key or certificate.  From
      the host key or certificate, the client can be assured of the 
      identity of the server.  

      The client only needs a single trust anchor to identify many 
      servers.  Each server host key is populated by the manufacturer 
      as part of the manufacturing process.  This solves the client's 
      scaling problem, and is the recommended mechanism.

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

---

From: Kent Watsen <[email-masked]>
Date: Fri, 16 Jan 2015 20:35:47 +0000

Hi Alan,

Thank you for your review!

Below are responses to your questions.

Thanks
Kent

>Sections 2.1/3.1

The "immediately" is meant to be interpreted more as "no more TPC data is
exchanged" than "without temporal delay".  There isn't a race condition
here.  Just like with a standard (not reversed) connection, the TCP stacks
will buffer the data until the SSH/TLS layers get initialized.  Do you
agree?

>Section 3.2

Yes

>      scaling problem, and is the recommended mechanism.

One small correction on the last case.  In advance of the first connect,
the client should (not must) also know the unique-identifer expected in
the server's certificate.  By example, an NMS should know the
serial-numbers for devices it expects to connect to it, in order to be
certain the devices are legitimate.

Otherwise, is this section still OK?

Thanks again,
Kent