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

From: "Dhanapal, Ramkumar (Nokia - IN/Chennai)" <[email-masked]>
Date: Fri, 9 Nov 2018 11:35:41 +0000

Hi Kent and All,
We have below comments on draft-ietf-netconf-netconf-client-server

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.

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.

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.

Request you to look into these comments and provide your feedback.

Regards,
Ramkumar

---

From: Kent Watsen <[email-masked]>
Date: Thu, 15 Nov 2018 22:32:03 +0000

[just back from travels]

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?

[BTW, please notify the editor about the typo in R-191: s/Identified/Identifying/.]

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

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.

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

Regards,
Kent

---

From: "Dhanapal, Ramkumar (Nokia - IN/Chennai)" <[email-masked]>
Date: Fri, 16 Nov 2018 10:51:39 +0000

Hi Kent,
Comments in-line.
Regards,
Ramkumar

From: Kent Watsen <[email-masked]>
Sent: Friday, November 16, 2018 4:02 AM
To: Dhanapal, Ramkumar (Nokia - IN/Chennai) <[email-masked]>; [email-masked]
Cc: Beauville, Yves (Nokia - BE/Antwerp) <[email-masked]>; Carey, Timothy (Nokia - US) <[email-masked]>
Subject: Re: Comments on draft-ietf-netconf-netconf-client-server

[just back from travels]

Hi Ramkumar,

[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)?
Regarding the typo in R-191, we will notify the author.

[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?

[Ram] Yes, we use Call-Home over TLS for DPUs but we also support listen over SSH for some other platforms

Regards,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Fri, 16 Nov 2018 18:34:31 +0000

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..  
>> 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.
> 
> [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
> 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.
>
 
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

---

From: "Dhanapal, Ramkumar (Nokia - IN/Chennai)" <[email-masked]>
Date: Tue, 20 Nov 2018 08:03:34 +0000

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 <[email-masked]> 
Sent: Saturday, November 17, 2018 12:05 AM
To: Dhanapal, Ramkumar (Nokia - IN/Chennai) <[email-masked]>; [email-masked]
Cc: Beauville, Yves (Nokia - BE/Antwerp) <[email-masked]>; Carey, Timothy (Nokia - US) <[email-masked]>
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..
>> 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.  
> 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.

>> netconf server, we see only one set of keys/certificates is enough 
>> and need not be per endpoint.
>
> 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:

>> Comment 3: The description of 
>> ‘netconf-server/listen/endpoint/transport\
> 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?
> 
 
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