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

Compare with Current View Page History

« Previous Version 8 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.

Meeting Minutes:

May 24, 2018


May 21, 2018


May 17, 2018

  • No labels