Re: [Netconf] Comments on draft-ietf-netconf-netconf-client-server

[Kent Watsen <[e-mail]>]

Hi Ramkumar,
 
>> Comment 1:
>> We are using the ‘ietf-netconf-server’ module for configuration of call home
>> parameters like netconf client endpoint IP/port, keys/certificates etc..  
>> For static configuration from northbound, this works fine.
>> 
>> Our use case is that the netconf client endpoint IP/port are learnt dynamically
>> through DHCP process inline with BBF TR301_Issue2.  These dynamically learnt
>> endpoints also need to be modelled in the yang.  These dynamic endpoints
>> should also support the configuration of keys/certificates.
> 
> I just read TR301 Issue2, which is similar to work I do both in and out of the IETF.
>
> What is your question specifically?  Is it how to configure the ietf-netconf-server
> data model given the PMA Offer message described in Section 16.5.2.2?  or is
> it how the PMA can configure these values after it establishes a NETCONF
> connection (via NETCONF Call Home) to the DPU after the discovery process
> completes?
>
> [Ram]  The DPU gets the PMA IP in the DHCP Offer message from DHCP server
> in option 125. The question is where to store these dynamically learnt IP
> addresses in the ietf-netconf-server data-model (the data-model seems to
> be pertaining to static user configuration)?

The dynamically learnt IP addresses would be stored in /ietf-netconf-server:\
netconf-server/call-home/netconf-client/endpoints/endpoint/tls/address.

I'm unsure what you mean by "static" configuration.  The data model regards
configuration in general, whether the configuration is set via, e.g., a
NETCONF client or a bootstrapping mechanism is immaterial.


>> Comment 2: The server keys/certificates/ca-certs are configurable per
>> endpoint per netconf-client. We understand pinned-ca-certs/ pinned-\
>> client-certs can be per endpoint. But for the device acting as the 
>> netconf server, we see only one set of keys/certificates
>> is enough and need not be per endpoint.
>
> As I understand TR301, the DPU will perform standard certificate path
> validation of the PMA’s end-entity certificate to a per-configured 
> trust-anchor certificate, presumably one provided by a public CA such
> as Verisign or Comodo, such as might be found in, e.g., /etc/ssl/certs.
> Thusly, these certs are, in effect, the “pinned-ca-certs” that would
> be used.  For absolute correctness, the DPU could auto-populate 
> /ietf-trust-anchors:pinned-certificates with these certs, or it could
> do “backend magic” to achieve the same result.
>
> [Ram]  We are in-line with you on the “pinned-ca-certs”.
> The comment is on the keys/certificate of the DPU i.e. ‘server-identity’. 
> As per the data-model, this is configurable per endpoint per netconf-client.
> Since the DPU is acting as netconf server, we use only one set of 
> keys/certificates and is not be per endpoint.
>
> Our view is that this set is applicable for all endpoints (both 
> statically configured and dynamically learnt scenarios).  Since it 
> is configurable per endpoint now, if the user configures one set 
> for each endpoint, which set shall the DPU use for the TLS authentication?
 
Thank you for the clarification.  As TR301 requires the use of an IDevID
certificate that, by definition, is preconfigured by the DPU's OEM, it is
expected to appear in /ietf-keystore:keystore/asymmetric-keys/asymmetric-key
(in <operational>, with "private-key" having the value "permanently-hidden").

Then /ietf-netconf-server:netconf-server/call-home/netconf-client/endpoints\
/endpoint/tls/server-identity/reference would point to it.   For instance,
the second example here [1] references the "ex-rsa-cert" certificate (and 
its associated private key).  [Note: "ex-rsa-cert", in this example, is 
NOT an IDevID cert]

But note that, per recent discussions, in order for the reference to be 
valid, a stub/copy of the asymmetric-key in the <operational> needs to 
be created in <intended>.  This is illustrated by the "tpm-protected-key2"
key listed in the first example here [2].  Note how this asymmetric-key
entry and its associated "builtin-idevid-cert2" cert contain just the 
"name" values, per the description of the /keystore/asymmetric-keys/\
asymmetric-key/name node:

       "An arbitrary name for the asymmetric key.  If the name
        matches the name of a key that exists independently in
        <operational> (i.e., a 'permanently-hidden' key), then
        the 'algorithm', 'public-key', and 'private-key' nodes
        MUST NOT be configured.";
     
[1] https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-08#section-4.2
[2] https://tools.ietf.org/html/draft-ietf-netconf-keystore-07#section-3.2




>> Comment 3: The description of ‘netconf-server/listen/endpoint/transport\
>> /ssh/address’ is mentioned as “The NETCONF server will listen on all
>> configured interfaces if no value is specified”.  When no value is
>> specified, we are unable to configure ‘ss:ssh-server-grouping’ parameters.
>
> Good catch, the mandatory true requires a value.  This was discussed on the list a
> while back with the result of wanting to instead have the address always specified,
> using INADDR_ANY or INADDR6_ANY when needed.  The description statement is
> wrong.  I have removed the 2nd sentence from the description statement in six
> locations in the four modules ietf-[netconf|restconf]-[client|server] in my local
> copy.
>
> BTW, you mention “listen” and “ssh” but, for TR301, it should be “call-home” and 
> “tls”, right?
> 
> [Ram] Yes, we use Call-Home over TLS for DPUs but we also support listen over
> SSH for some other platforms
 
Gotcha.  Everything written above regarding the TLS data model applies to 
the SSH data model though, with SSH, there is an option to use a standard
SSH pubkey as well as an X.509 certificate.  Depending on if your IDevID 
is stored in a TPM, you may find pubkey easier to implement.

Kent