You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Recommendation Scope:

The scope of this recommendation is to cover how ONAP achieves secure communication to the network functions.  The network functions could be VNFs, PNFs.  This includes:

  • Assumptions on cert management
  • Communication between the network function and DCAE
  • Communication between the network function and the controllers
  • SSH
  • Requirements on projects

Recommendation Status:

Draft

Assumptions:

May 17, 2018 Agreed to the following Assumptions:

  • ONAP CA is used to sign DCAE and NF end-entity certificates during development and testing.
  • For commercial deployment, it is expected that each Service Provider has its own CA/PKI and the Service Provider Root CA/Sub CA is used to sign DCAE and NF end-entity certificates.
  • 3GPP compliant NFs use CMPv2 for certificate management; such as enrollment, key renewal.

Recommendations:

May 17, 2018 Agreed to the following Recommendations:

  • ONAP shall not support username and password authentication for HTTPS; certificate authentication only.
  • ONAP components and NFs shall support TLS for security of HTTP connections.  Note:  Performance is no longer an issue and is not a valid excuse for not using TLS.
  • ONAP shall not support HTTP for communications between ONAP components or between NFs and ONAP components, except for NF certificate enrollment over CMPv2.  Note: CMPv2 uses HTTP and must be allowed for certificate enrollment.

May 21, 2018 Agreed to the following Recommendation:

  • ONAP components and NFs shall support at least 3 levels of certificate chaining; Root CA, Sub CA, End-entity.  Note:  This is already supported in ONAP.

May 24, 2018 Agreed to the following Recommendations:

  • When certificates are used, LDAPv3 shall be supported as the primary method of authorization of a NF in ONAP.

  • When certificates are used, HTTP shall be used as an alternative method of authorization of an NF when LDAP is not available.

  • LDAPv3 format or HTTP format shall be used to access file repositories of TLS certificates.

  • LDAPv3 and HTTP formats shall be supported for checking the revocation status of TLS certificates.

  • When SSH/SFTP is used, public key authentication shall be supported by NF to authenticate ONAP access; password authentication shall not be supported for SSH/SFTP access into the NF.

  • ONAP shall support both TLS and SSH as the transport protocol for NetConf.  

  • TLS shall be the preferred transport protocol for NetConf.

  • It shall be possible to specify the configuration management protocol supported by a NF at design time (NetConf/TLS, Netconf/SSH, Ansible/SSH or Chef/SSH).
  • If a configuration management protocol is not specified for a NF, ONAP shall try NetConf/TLS first as the default.

May 31, 2018 Agreed to the following Recommendations:

  • Suggestion on VNF integration, in a manner logically similar to legacy eNB/gNB autointegration (plug and play). Also discussion on VNF root of trust. PNF autointegration and root of trust are included as reference info. The suggestions are in line with ETSI and 3GPP.

Meeting Minutes:

May 31, 2018

May 24, 2018


May 21, 2018


May 17, 2018

  • No labels