public openconfig/system: add tls-profile-name leaf

This was discussed in: https://github.com/openconfig/public/issues/1050 where it seemed that the /system/grpc-servers/grpc-server/config/certificate_id leaf from https://github.com/brianneville/oc-public/blob/7d21dfc82acb9e39ee8b23a05ba3f5101f33b196/release/models/system/openconfig-system-grpc.yang#L162 had effectively been hijacked/repurposed to provide this utility. The leaf added here is explicitly to allow for configuration of the ssl-profile-id of a gRPC server.

Change Scope

This change adds the following:

  /oc-sys:system/oc-sys-grpc:grpc-servers/oc-sys-grpc:grpc-server/oc-sys-grpc:config:
    +--rw tls-profile-name?   string
 
  /oc-sys:system/oc-sys-grpc:grpc-servers/oc-sys-grpc:grpc-server/oc-sys-grpc:state:
    +--ro tls-profile-name?   string

This change is backward-compatible, as it is adding a new leaf.

Platform Implementations

Arista SSL profile support: https://www.arista.com/en/um-eos/eos-control-plane-security#xx1004880
Cisco trustpoint support: https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/101x/programmability/cisco-nexus-9000-series-nx-os-programmability-guide-release-101x/m-n9k-gnmi-grpc-network-management-interface-101x.html#Cisco_Reference.dita_27eb229d-a636-4b17-a29b-a0d67f48e5cf

(As this is a new leaf it is not supported by any vendor yet)

Mar 07 '24 17:03 brianneville

Fixes https://github.com/openconfig/public/issues/1050

Mar 07 '24 18:03 dplore

/gcbrun

Mar 07 '24 18:03 dplore

No major YANG version changes in commit 00a6bd80504db55d67074390346beae9bcdbf8da

Mar 07 '24 18:03 OpenConfigBot

IMO this shouldn't be in gnsi model (and i would prefer to get away from ssl in the naming; in my opinion, it is better to use tls)

gNSI is just one interface to create a tls profile. An implementation may not support gNSI, but still provide an ability to configure tls-profiles (e.g. via cli) that can be used with grpc-servers.

Also, together with the introduction of the new leaf, we should deprecate the old one.

Mar 07 '24 18:03 LimeHat

in my opinion, it is better to use tls)

+1

@brianneville the link to TOI is not public

Mar 07 '24 18:03 hellt

IMO this shouldn't be in gnsi model

ack, this does have general purpose since we can configure this from both CLI or gNSI, so moved it to openconfig system grpc model to be more broadly available.

(and i would prefer to get away from ssl in the naming; in my opinion, it is better to use tls)

Hmm I'm a bit on the fence about this - hence the last few commits :).

There isn't any existing concept of a "TLS profile" which we are trying to align to, while the concept of an SSL profile identified by an ssl-profile-id already exists in Certz, and making this association would be helpful for operators who do use Certz for provisioning, as it would give a clear way to set ssl-profile-id for a server.

Are there any downsides to using ssl-profile-id here for operators who are not using Certz? For operators who don't care about Certz, I feel that moving this leaf out of openconfig-gnsi-certz and giving it a generic description should be enough to distinguish it from being necessarily related to Certz.

Also, together with the introduction of the new leaf, we should deprecate the old one.

done

the link to TOI is not public

ah apologies - I'll check for a public link edit: updated link to be for SSL profile config, as this leaf is not entirely gNSI specific anymore after being moved out of openconfig-gnsi-certz

Mar 11 '24 13:03 brianneville

/gcbrun

Mar 13 '24 16:03 wenovus

There isn't any existing concept of a "TLS profile" which we are trying to align to, while the concept of an SSL profile identified by an ssl-profile-id already exists in Certz, and making this association would be helpful for operators who do use Certz for provisioning, as it would give a clear way to set ssl-profile-id for a server. Are there any downsides to using ssl-profile-id here for operators who are not using Certz?

FWIW I'd replace SSL with TLS across the board if we get a chance to do that :) This is mostly about the semantics. SSL is a deprecated protocol (rfc7568), replaced by TLS. Thus the profiles are not used with SSL in any current implementation.

Mar 15 '24 06:03 LimeHat

+1 on using tls instead of ssl for new leafs, don't grow the technical debt.

Mar 15 '24 06:03 dplore

renamed leaf in latest patch

Mar 21 '24 12:03 brianneville

/gcbrun

Mar 21 '24 16:03 dplore

/gcbrun

Apr 03 '24 18:04 wenovus

Reviewed in May 14, 2024 OC operators call. Marcus volunteered to review.

May 14 '24 16:05 dplore

A few comments as I think some restructuring should be revisited wrt. transport security for gRPC endpoints in general and as it relates to potential restructuring within: https://github.com/openconfig/public/pull/1096

We can rid ourselves of the SSL vs. TLS nomenclature debate by nesting security related configuration/state under a child container. Today, we have transport-security (boolean) and certificate-id (string) sitting at the root of ./config. There are still gaps with only these attributes and suggest better categorization first.
If we nest and restructure to something like where transport-security is now a container, we can introduce an enable (boolean) along side with other sibling leafs - for the profile reference this can merely be generalized to a profile
In addition, a profile today is a string value that needs to correspond to an object provisioned over another interface so thus no YANG relationship. gNSI is likely to not be the only interface as the barrier of entry for everyone is raised and we now breach the boundaries of creating too soft of relationships. Other methods could be relational schema that could very well come in natively into OC models or as mutual exclusive augments or a soft relation to another model set such as native (much like the gNSI reference). The latter is a bigger question in general as it is a problem stmt across all modeling and references. For the prior, if we anticipate possible OpenConfig YANG schema to eventually also define profiles then we can start with a single member union where one is a well documented string and in the future, a potential leafref can be added.
As far as gaps, other than a reference to enablement/disablement + a profile, other necessary items to toggle other TLS related parameters are warranted (hot-reloading behavior, request types, etc..) - https://github.com/grpc/grpc/blob/master/include/grpc/grpc_security_constants.h#L79-L126

May 14 '24 18:05 earies