Subject: [Netconf] server-model issue with specifying which keys/certs a server instance use

From: Kent Watsen <[email-masked]>
Date: Thu, 23 Oct 2014 22:26:28 +0000

In order to resolve the host-key "name" issue (issue #4), the plan
discussed during this week's virtual meeting was to introduce a couple
config=false lists for the server's host-keys and certs, something like
this:

   +--rw netconf-server
      +--rw listen
      | ...
      +--rw call-home
      |  ...
      +--rw ssh
      |  +--rw host-keys
      |     +--ro host-key* [name]
      |        +--ro name                 string
      |        +--ro format-identifier    string
      |        +--ro data                 binary
      |        +--ro fingerprint          string
      +--rw tls
         +--rw certificates
         |  +--ro certificate* [name]
         |     +--ro name    string
         |     +--ro data    binary
         |  ...

and then the have specific listen/call-home configurations use a leafref
to identify which one(s) they wanted to use.   For instance:

              leaf host-key {
                type leafref {
                  path "/netconf-server/ssh/host-keys/host-key/name";
                }
              }

But this doesn't work because the path is not part of the accessible tree:

    error: the path for host-key is config but refers to a non-config
    leaf name defined at ../ietf-netconf-server.yang:109

OK, but what to do now?   One option is to define a full-on configuration
model for both TLS and SSH, which would then enable the leafref to work.
But I'm hesitant to do this though, because it seems like a huge
(potentially out of scope) addition and it looks complicated, so I'm
looking for options - anyone?

As a recap, the reason why we want to configure which hostkeys are
advertised is call-home SHOULD *only* advertise an X.509 key, whereas
listen SHOULD advertise the common set of keys (rsa, dsa, etc.).

One simplification would be to have a single setting for all "listen"
instances and a separate single instance for "call home" instances.   But
this simplification doesn't resolve the issue above of how to
identify/reference which key(s) should be used...

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Oct 2014 15:33:39 -0700

> looking for options - anyone?
IMO do not use a leafref.  Let's not keep expanding the scope of
this work or it will never get done. Write a description-stmt that
explains the constraints. It should be OK to change a type-stmt
from "foo" to "leafref to leaf with type foo" in a module update.
So we just have to get the data type correct.

> identify/reference which key(s) should be used...

Andy

>
>
>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Oct 2014 09:17:14 +0200

> So we just have to get the data type correct.

A data model to manage certificates and host keys would surely be
useful but this is big project on its own and I agree that we should
not try to solve it here. So all we can do is probably refer to a
certificate or host key by name and leave the details how these
credentials are configured undefined for now. The only assumption we
would make is that a future data model to manage certificates and host
keys identifies certificates and host keys by a name.

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