Add syslog TLS

[dplore]

Change Scope

• Add support for syslog over TLS
• This change is backwards compatible

Tree view

We are at /system/logging

module: openconfig-system
[... snip ...]
         |  |  +--rw remote-servers
         |  |  |  +--rw remote-server* [host]
         |  |  |     +--rw host         -> ../config/host
         |  |  |     +--rw config
         |  |  |     |  +--rw host?               oc-inet:host
         |  |  |     |  +--rw source-address?     oc-inet:ip-address
         |  |  |     |  +--rw network-instance?   oc-ni:network-instance-ref
         |  |  |     |  +--rw remote-port?        oc-inet:port-number
         |  |  |     |  +--rw host?                 oc-inet:host
         |  |  |     |  +--rw source-address?       oc-inet:ip-address
         |  |  |     |  +--rw network-instance?     oc-ni:network-instance-ref
         |  |  |     |  +--rw remote-port?          oc-inet:port-number
+        |  |  |     |  +--rw transport-security?   boolean
+        |  |  |     |  +--rw tls-profile-id?       string
         |  |  |     +--ro state
         |  |  |     |  +--ro host?               oc-inet:host
         |  |  |     |  +--ro source-address?     oc-inet:ip-address
         |  |  |     |  +--ro network-instance?   oc-ni:network-instance-ref
         |  |  |     |  +--ro remote-port?        oc-inet:port-number
         |  |  |     |  +--ro host?                 oc-inet:host
         |  |  |     |  +--ro source-address?       oc-inet:ip-address
         |  |  |     |  +--ro network-instance?     oc-ni:network-instance-ref
         |  |  |     |  +--ro remote-port?          oc-inet:port-number
+        |  |  |     |  +--ro transport-security?   boolean
+        |  |  |     |  +--ro tls-profile-id?       string

Platform Implementations

• Arista EOS support syslog over TLS

configure
	management security
		ssl profile MYPROFILE
			trust certificate MYPROFILE-ca.crt
     logging host 10.1.1.1 6514 protocol tls ssl-profile MYPROFILE

• Juniper JunOS supports syslog over TLS

 set security pki ca-profile myprofile ca-identity test
 set security pki ca-profile myprofile revocation-check disable
 
 set system syslog host 10.1.1.1 port 6514
 set system syslog host 10.1.1.1 transport tls
 set system syslog host 10.1.1.1 any any
 set system syslog host 10.1.1.1 tlsdetails trusted-ca-group abc ca-profiles myprofile
 set system syslog host 10.1.1.1 source-address 192.168.10.10

• Cisco supports syslog over TLS

Router(config)#logging tls-server TEST
Router(config-logging-tls-peer)#severity debugging
Router(config-logging-tls-peer)#trustpoint mytlsprofile
Router(config-logging-tls-peer)#address ipv4 10.1.1.1
Router(config-logging-tls-peer)#commit

[OpenConfigBot]

No major YANG version changes in commit 6fc0264

[earies]

It seems we are likely at a point where it makes sense to define a common structure that is imported/used across all services that have the option for TLS (or stage as such to slow transition previous definitions while using the new structure going fwd)

If we look across the model-set today, we have a variation in definition/behavior. Some reference to profiles (SSL/TLS nomenclature mixed), some reference to certificates, defaults and description differences.

Outside of that and a bit outside of this PR but related:

For the tie to gNSI, we already have a nomenclature mismatch that should be reconciled (should normalize everything to TLS and firm up the relationship). In addition are references towards gNOI cert services as well as gNSI cert services

Unfortunately anything outside of these services then is undefined behavior and ymmv for anyone not intending to use gNSI. Since there is no OC YANG schema covering the configuration of profiles, it is loosely implied to just match up this string with some native definition in the implementation (config or otherwise)

[dplore]

Hi Ebben, thanks for the thoughtful feedback. You are not wrong! The OC data models have not ever tried to define how to install and manage certificates. In practice, managing certs is "out-of-band" of gnmi. CLI and ssh, scp, gnsi.certz or some other magic needs to be used to get a certificate on a device and name those certs so that OC can reference them. I see this as an area for improvement, but not blocking this PR.

Thanks for pointing out the gnoi.Certificate service. We just removed it as that approach was never implemented (to my knowledge) and is obsoleted by gnsi.

I support moving to TLS nomenclature. My opinion is we should introduce new TLS entities named with TLS only. For the SSL things, we should create equivalent entities with TLS nomenclature and deprecate (but not delete) the SSL names.

[dplore]

Set last call to Sep 12, 2024