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

["Dhanapal, Ramkumar (Nokia - IN/Chennai)" <[e-mail]>]

Hi Kent,
Thanks for your clarifications for comments 1 and 2.
It seems the draft yang model is aligned to the NMDA architecture (rfc8342).
We understood that our NETCONF server should be NMDA compliant and we shall work towards that.
Thanks for your support.
Regards,
Ramkumar

-----Original Message-----
From: Kent Watsen <[e-mail]> 
Sent: Saturday, November 17, 2018 12:05 AM
To: Dhanapal, Ramkumar (Nokia - IN/Chennai) <[e-mail]>; [e-mail]
Cc: Beauville, Yves (Nokia - BE/Antwerp) <[e-mail]>; Carey, Timothy (Nokia - US) <[e-mail]>
Subject: Re: Comments on draft-ietf-netconf-netconf-client-server

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