Subject: [Netconf] netconf server outgoing endpoints

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Jul 2014 11:56:51 +0200

Hi,

draft-ietf-netconf-server-model-01 uses this model for outgoing
connections to NETCONF client applications:

         +--rw call-home
            +--rw network-managers
               +--rw network-manager* [name]
                  +--rw name                  string
                  +--rw description?          string
                  +--rw endpoints
                  |  +--rw endpoint* [address]
                  |     +--rw address    inet:host
                  |     +--rw port?      inet:port-number
                  +--rw transport
                  |  +--rw ssh {ssh-call-home}?
                  |  |  +--rw host-keys
                  |  |     +--rw host-key* [name]
                  |  |        +--rw name    string
                  |  +--rw tls! {tls-call-home}?

Again, I think there are potential issues due to the indexing and to
support extensibility. An alternative solution may look like this:

   +--rw call-home
      +--rw application* [name]
         +--rw name         string
         +--rw endpoints* [name]
            +--rw name    string
            +--rw (transport)
               +--:(ssh) {ssh-call-home}?
               |  +--rw ssh
               |     +--rw address    inet:ip-host
               |     +--rw port?      inet:port-number
               |     +--rw host-key* [name]
               |         +--rw name    string
               +--:(tls) {tls-call-home}?
                  +--rw tls
                     +--rw address    inet:ip-host
                     +--rw port?      inet:port-number

The host-key I copied over from draft-ietf-netconf-server-model-01 but
I am not sure it is well enough defined to allow for interoperable
implementations. The relevant text is:

               list host-key {
                 key name;
                 min-elements 1;    // requires 'ssh' element?
                 ordered-by user;
                 leaf name {
                   type string;
                   mandatory true;
                   description
                     "The name of a host key the device should
                      advertise during the SSH key exchange.";
                 }
               }

Is it clear what a 'name of a host key' is up to the point that
different implementations do exactly the same thing?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 10 Jul 2014 02:37:50 +0000

Comments inline below:

>                     +--rw port?      inet:port-number

The use-case here is that a NMS managing a device may have more than one
address for availability reasons (e.g., clustering, disaster recovery,
hierarchical geographic distribution, etc.).   For that given application,
the transport used would be identical for all its endpoints.  The solution
proposed above is more flexible, allowing the transport to be configured
distinctly for each endpoint, but I can't see an NMS ever wanting to do
that.  Can anyone think of a reason, or should we do it just to be safe?

>different implementations do exactly the same thing?

This list of host-keys construct maps directly onto OpenSSH's sshd_config
file's "HostKey" value.  An example value would be
<name>ssh_hostkey.pem</name>.   The goal/assumption is that the host keys
have been configured somewhere else.  Perhaps we need to add configuring
SSH host-keys to ietf-system via another (or same) augmentation similar to
the ietf-system-tls-auth module, also defined in this draft?

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Jul 2014 14:21:37 +0200

> that.  Can anyone think of a reason, or should we do it just to be safe?

You can replicate the endpoints list into the ssh and tls containers
if you want to prevent this. My main point is that the endpoint list
should not be keyed by an address to allow for extensions (e.g. vrfs).

> <name>ssh_hostkey.pem</name>.   

But we need to make this general and not implementation specific. My
understanding of sshd_config's HostKey option is that it specifies
where a key is stored. So that means you would not verify a key but
only verify where some random key is stored. This is likely not what
you want. I guess what you wanted is likely a fingerprint of a host
key. It would be nice to be able to refer to something in the SSH
specifications.

> The goal/assumption is that the host keys

Well, in this case this makes this leaf a reference to something
undefined. Not sure this is useful.

/js