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

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

Hi Kent,
Comments in-line.
Regards,
Ramkumar

From: Kent Watsen <[e-mail]>
Sent: Friday, November 16, 2018 4:02 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

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

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

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

> 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

Regards,
Kent