query regarding 'certificate-id' for openflow connection

[pullururajasekhar]

Hi Team,

openflow yang (https://github.com/openconfig/public/blob/master/release/models/openflow/openconfig-openflow.yang) has a leaf 'certificate-id' inside the open-flow controller connection grouping to be used for TLS connection between open-flow agent and controller.

Agent requires its own certificate signed by a root-ca to provide its identity to the open-flow controller. Agent also needs the root-ca that was used in the certificate-chain to sign the controller to validate the open-flow controller.

There are two certificates involved here. What does the 'certificate-id' indicate here? Does it indicate the agent's own certificate or the controller's ca certificate? If it indicates the agent's own certificate, should the yang also incorporate the ability to specify the certificate-id (remote) to be used for validating the openflow controller TLS request?

Thanks & Regards

[aashaikh]

@samribeiro maybe you want to comment on the usage model here?

[samribeiro]

@pullururajasekhar the certificate-id stated in the OpenFlow model is the Certificate the OpenFlow agent presents to the Controller. The CA used to validate the Controller Certificate must be part of the Target's CA bundle. This bundle is used to validate the Controller Certificate in all OpenFlow connections.

[pullururajasekhar]

@samribeiro Is there a yang-model for the Target's CA bundle and the certificate-id? It's typical to assume that the OpenFlow agent uses SSL library for TLS certificate authentication, that requires both Agent's Certificate and Controller Certificate for authenticating each other. It's logical to not keep the agent and controller certificate configuration separate. What should be the controller certificate the agent should use when only the agent's certificate was configured and the controller certificate wasn't configured yet (through the Target's CA bundle)? That could leave open to different implementation behaviors from different vendors. Does it make sense to configure both certificates together and avoid that?

[samribeiro]

@pullururajasekhar,

I would not go as far as asserting "its typical to assume..". - The SSL library for TLS certificate authentication accepts a pool of Root CA certificates to validate the peer, both on Client and Server sides.

I would also not go as far as asserting that it is logical to to keep both certificates configuration together. There are use cases where that is not the norm. The logic is subjective to the scope.

I agree with you that there should be less ambiguity in order to avoid different implementations. However I am not seeing where the ambiguity lies in this particular example. The Target must use its bundle of CAs. If these were not configured then they should have been configured. The side effect is that authentication fails which is the preferred outcome since the context is a secure connection.

There is a gNOI cert management service that provides support for managing certificates. That same service allows to optionally install a bundle of CA certificates. In the meantime, a gNOI service that allows dedicated management of the bundle of CA certificates is in the works.

Regarding the OpenFlow model, we can clarify in the model documentation that the shared bundle of CA certificates in the Target must be used to authenticate the Peer. Or we open the discussion for itemizing the pros and cons for a dedicated CA bundle per connection versus a shared CA bundle for all connections, and then make a decision based on those.

[pullururajasekhar]

@samribeiro

Agree with you on the use case on configuration with a pool of RootCA.

Few more questions:

1. Does openconfig have a yang model for certificate bundle configuration? And does gNOI (new to me) use these models to push certificates onto the target device?

2. If there is no yang model, 2.1) how should an operator push these certificates on to the target device when he/she is not using gNOI service? 2.2) If openflow openconfig yang model can specify the minimum required parameters (like controller-ip, port and transport type(TCP)) that is needed to establish the TCP connection to openflow controller successfully, why not specify the minimum required parameters for TLS (local certificate and remote certificate along with ip/port and transport type) in yang model to establish TLS connection successfully? Why should we have few parameters configured via Yang? And a few by different means? I think the openconfig openflow yang model must be self contained at-least in this aspect to include the remote certificate configuration (if not one certificate-id, probably it can include the name of the certificate pool?). You can dis-agree.

[pullururajasekhar]

Hi @samribeiro , do you have any update on the latest comment?

Thanks & Regards, Rajasekhar

[samribeiro]

Hi @pullururajasekhar,

1.) AFAIK, there is no YANG model for Certificate Management. Certificate Management contains complexities that make it more convenient to exist as a gNOI Service. gNOI does not use YANG.

2.1) Use the gNOI Certificate Management Service.

2.2) I wholesomely agree with you that conceptually, yang models should be self contained and not require external configuration dependencies. In the OpenFlow model for instance, how do you suggest we configure a X.509 Certificate that is signed both by the Target and the Client in order to fulfill established security practices?

[pullururajasekhar]

Hi @samribeiro

Thanks for the quick reply.

1) My understanding and expectation on openconfig is that it provides a vendor neutral data model which is sufficient enough to configure any networking device without having to depend on external services (like gNOI here). If a networking protocol needs configuration of certificates, I would tend to think to have a yang model for configuration of certificates. This is just my view.

2.2) I am not sure if I understand your question correctly. But, I will try to respond from what I have understood. Irrespective of the way the certificates are configured (like gNOI today (or) through a yang model may be in future?), for now, we can have a leaf to specify the controller-certificate-id for validating the controller by the openflow-agent under grouping openflow-connections-config in yang model (placed next to the leaf certificate-id) . Like the existing agent's local certificate-id, this can be a string, that way vendor can chose to differ in the implementation but have a common mechanism and behavior across vendors.

Let me know your thoughts.

[samribeiro]

Hi @pullururajasekha,

We seem to have gone full circle in this discussion. Can you itemizing the benefits for having a dedicated CA bundle per connection versus a shared CA bundle for all connections?

[pullururajasekhar]

Hi @samribeiro

It's not about the benefits. Theoretically open-flow protocol allows multiple controller configuration (from different machines), and each of them can have a different CA (not saying they can cannot share the same CA), but the model shouldn't restrict or assume to use shared CA.

Even if the proposal is to use shared CA for all the connections, the model should allow configuration of that shared remote CA name to authenticate the controller(s) by the agent using a leaf under controllers container. I hope you don't dis-agree to this.

[samribeiro]

Hi @pullururajasekha,

CA bundle == multiple CA Certificates

It was never a proposal the use of one CA certificate for all connections. The OpenFlow model assumes that the Target has a bundle of CA certificates installed. That bundle is used by all OpenFlow connections. It is possible and expected that individual connections use different CA certificates from that CA bundle. The SSL library seeks to validate the connection with at least one CA certificate from that bundle.

[pullururajasekhar]

@samribeiro Ok, but why not allow specifying that CA bundle from the yang model itself? I am not asking for a model for bundle CA here (which may be configured using external service like gNOI), but just allow to specify a reference to that bundle CA from the yang model.

[samribeiro]

Hi @pullururajasekha, This is what I was seeking to understand from you. Why should this model specify a CA bundle, when most use cases with certificates schemes have a shared CA bundle model. I.e.: your computer.

Adding a leaf to the model is easy, what I am looking for is a justification to do it.

[pullururajasekhar]

Hi @samribeiro

What's the justification to specify the agent's certificate-id leaf in the yang model when the certificate itself is pushed from an external service? Why not use that external service itself to specify the agent's certificate-id to be used?

I am an operator, and I only use openconfig to configure/manage/operate the switch, I neither use CLIs nor any external software/services. As an operator, how am I supposed to know what are the list of certificate-id's installed on the switch when there is no yang model to push/get them? If there is no way to figure out the list of certificate-id's installed on the switch, how would an operator specify the agent's certificate-id in the yang model?

[samribeiro]

Hi @pullururajasekha, There are details in Certificate management that make it complex for attempting to use Yang models to install them. Also curious, how do you upgrade your switch?

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.