...
The PNF package is expected to be a CSAR package.
...
PNF PACKAGE
...
SECURITY
The PNF package "shall" have a Licensing.term (file)
This is also still under discussion (driven from the standards)
This section will be updated with what is contained in the actual PNF package.
PNF PRE-ONBOARDING: VNF-SDK ENHANCEMENTS
VNF SDK is (optionally) responsible to validate the PNF package provided by the vendor.
VNF SDK can also be used (optionally) to create a PNF package.
Today, optionally, the VNF SDK is also able to provide
We expect the VNF SDK development to be able to reuse much of the functionality from VNF SDK, format delivery, processing are all the same except HEAT deployments templates are not used (as they do not apply to PNFs).
The VNF SDK will be used to VALIDATE the PNF Onboarding Package
It is possible for a user to bring in the PNF Onboarding Package (provided by a vendor) without the use of the PNF SDK tools.
Some of the NF artifacts are created by the SDC tool.
[INVESTIGATE] What are artifacts that SDC adds during the Onboarding process, looking at SDC supported artifact types, possibly VENDOR LICENSE and MODEL INVENTORY (are there others?)
PNF Package Security.
According to ETSI SOL004 v2.6.1 the onboarding package shall be signed. ETSI SOL004 provides two options:
Option 1 - One Digest for each components of the VNF package. The table of hashes is included in the manifest file, which is signed with the VNF provider private key. A signing certificate including the provider’s public key shall be included in the package.
Option 2 - The complete CSAR file shall be digitally signed with the provider private key. The provider delivers one zip file consisting of the CSAR file, a signature file and a certificate file that includes the VNF provider public key.
In Dublin release option 2 is going to be implemented in SDC.
- The VNF/PNF package authenticity and integrity is ensured by signing the CSAR file with the provider private key. The digital signature is stored in a separate file.
- The VNF/PNF provider shall also include an X.509 certificate in a separate file with extension .cert or, if the signature format allows it, in the signature file itself. The VNF/PNF provider creates a zip file consisting of the CSAR file, signature and certificate files. The signature and certificate files shall be siblings of the CSAR file with extensions .sm and .cert respectively.
- Only CMS signature file format is supported in this release.
- At pre-onboarding of the PNF/VNF package, VNFSDK tool could verify the signature of the complete CSAR package with the provider’s public key
- At onboarding of the PNF/VNF package, SDC could verify the signature of the complete CSAR package with the provider’s public key.
- At onboarding, SDC is expecting package file extension as following:
- Heat template: .zip
- TOSCA without package security: .csar
- TOSCA with package security (option 2): zip file consisting of the CSAR file, a signature file and a certificate file .
PNF PRE-ONBOARDING: VNF-SDK ENHANCEMENTS
VNF SDK is (optionally) responsible to validate the PNF package provided by the vendor.
VNF SDK can also be used (optionally) to create a PNF package.
Today, optionally, the VNF SDK is also able to provide
We expect the VNF SDK development to be able to reuse much of the functionality from VNF SDK, format delivery, processing are all the same except HEAT deployments templates are not used (as they do not apply to PNFs).
The VNF SDK will be used to VALIDATE the PNF Onboarding Package
It is possible for a user to bring in the PNF Onboarding Package (provided by a vendor) without the use of the PNF SDK tools.
Some of the NF artifacts are created by the SDC tool.
[INVESTIGATE] What are artifacts that SDC adds during the Onboarding process, looking at SDC supported artifact types, possibly VENDOR LICENSE and MODEL INVENTORY (are there others?)
| TASK | VNF SDK S/W FUNCTION - DESCRIPTION | Release Priority | |||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#1: MANIFEST FILE (VNF SDK) vs FILE CHECK (Test only) | Verifies the MANIFEST file (MainServiceTemplate.mf) and checks that the defined directories of the PNF package against the manifest file. for example the manifest file might say a files should exist: "Measurements: source: Artifacts/Deployment/Measurements/PM_Dictionary.yaml", the VNF SDK would check that the file PM_Dictionary.yaml exists in the actual PNF package. (Confirmed that VNF-SDK supports already Feb 14, 2019). Bogumil Zebek There are two repositories: Java, Python. (investigate) ASSOCIATED DEVELOPMENT:
| R4 HIGH | |||||||||||||||||||||||||||||||||||
#2: TOSCA MetaFile LICENSE Term File Exists Check (VNF SDK) (Test Only) | VNF SDK will check a License Term File Check in the PNF package. TOSCA meta file points to a License. Just a check that the file exists no content check at all. Note: Related requirements standards from ETSI IFA011, SOL004 ASSOCIATED DEVELOPMENT: | ||||||||||||||||||||||||||||||||||||
| TASK | VNF SDK S/W FUNCTION - DESCRIPTION | Release Priority | |||||||||||||||||||||||||||||||||||
#1: MANIFEST FILE (VNF SDK) vs FILE CHECK (Test only) | Verifies the MANIFEST file (MainServiceTemplate.mf) and checks that the defined directories of the PNF package against the manifest file. for example the manifest file might say a files should exist: "Measurements: source: Artifacts/Deployment/Measurements/PM_Dictionary.yaml", the VNF SDK would check that the file PM_Dictionary.yaml exists in the actual PNF package. (Confirmed that VNF-SDK supports already Feb 14, 2019). Bogumil Zebek There are two repositories: Java, Python. (investigate) ASSOCIATED DEVELOPMENT:
| R4 HIGH | |||||||||||||||||||||||||||||||||||
#2: TOSCA MetaFile LICENSE Term File Exists Check (VNF SDK) (Test Only) | VNF SDK will check a License Term File Check in the PNF package. TOSCA meta file points to a License. Just a check that the file exists no content check at all. Note: Related requirements standards from ETSI IFA011, SOL004 ASSOCIATED DEVELOPMENT: QUESTION is the file is not there will the process abort or is a warning given? (Already Supported, VNF-SDK already supports this confirmed Feb 14, 2019) | R4 HIGH | |||||||||||||||||||||||||||||||||||
#3: TOSCA MetaFile CERTIFICATE Check (VNF SDK) (Test Only) | (Test only) CERTIFICATE check. In the PNF package it is expected that there will be MainServiceTemplate.cert. This is mentioned in the TOSCA MetaFile. For example, in the TOSCA MetaFile, it could be mentioned "Entry-Certificate: Artifacts/resource-gnodeb-template.cert". And VNF SDK would check to make sure that the resource-gnodeb-template.cert file exists in the mentioned directory, the Artifacts in this case. VNF SDK does not look inside this file. (Needs Investigation) SOL004 has option 1 (signing each artifact individually / individual digest) and option 2 (sign entire package). It would be nice if VNF SDK supported both Option 1 and Option 2. (Needs Investigation) VNF-SDK option 1/2 support still needs investigation (as of Feb 18, 2019). Need to clarify how to do the test. ASSOCIATED DEVELOPMENT:
QUESTION is the file is not there will the process abort or is a warning given? | R4 HIGH | #4: SOL004 PNF TAGS | ||||||||||||||||||||||||||||||||||
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
R4
High
Following ETSI SOL004 Validation for Meta-Data file and Manufacturer file, this is the TOSCA.meta file that is part of the PNF Package. Both VNF SDK implementing only meta-data option, in the package there is a meta file. Check TOSCA.meta, while this file is not mandatory, when it is included that it follows the SOL004 standard (ETSI). We expect that "TOSCA-Meta-Version" and "CSAR-Version" and "Created by" are already supported, and new checks for "Entry definition, Entry-manifest, Entry-change-log, Entry-tests, Entry-certificates" would be new VNF SDK development work (needs to be verified).
VNF SDK does the check the TOSCA.meta file today, if a few keywords is there.
ASSOCIATED DEVELOPMENT:
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
R4
HIGH
Driven from SOL004: Option 1 (Supported in R4 Dublin): TOSCA.meta (exists) Meta-directory based, XML based approach. Option 2 (NOT support in R4 Dublin): CSAR without TOSCA.meta. Manifest (.mf) file that has everything (so the TOSCA.meta is redundant). Yaml-based approach.
The Public Key a key to open the package. SOL004 Option 1, 2 and use key to open the package - X.509 certificates public key, private key to sign the package and private key correspond to the private key of the package also delivered with the package. a package, a signature, and public key certificate delivered together. There may be more than one signature. Option 1 there is a digest for every file. All of those digests are listed in the manifest file. The manifest file is signed, one signature on the manifest. One signature and one key/pair & 1 certificate. Still optional to sign other files. The signature is a file beside. myimage.iso myimage.xyz but the same file/directory. Every file signed should have a signature files. CSAR file signed in a .sm file, package signature. The public key is signed can be signed by a root certificate.
An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate.
(investigate) if VNF-SDK would like to use AAF as the CA. Can AAF perform the CA functions.
To open the package need: (1) Public Key (to open the manifest file) (2) file input (3) certificate input. create a hash, the hash is verified against the signature. SHA-256
The descriptor. There is validation of the VNFD. PNF Descriptor: TOSCA descriptor, and validate the node type. Validation of TOSCA PNFD. Following TOSCA rules. Components required are there. (NEEDS INVESTIGATION)
VNFSDK check the VNFD based on VNF requirements.
ASSOCIATED DEVELOPMENT:
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
R4
HIGH
(Already Supported, VNF-SDK already supports this confirmed Feb 14, 2019)
R4
HIGH
#3: TOSCA MetaFile CERTIFICATE Check (VNF SDK)
(Test Only)
(Test only) CERTIFICATE check. In the PNF package it is expected that there will be MainServiceTemplate.cert. This is mentioned in the TOSCA MetaFile. For example, in the TOSCA MetaFile, it could be mentioned "Entry-Certificate: Artifacts/resource-gnodeb-template.cert". And VNF SDK would check to make sure that the resource-gnodeb-template.cert file exists in the mentioned directory, the Artifacts in this case. VNF SDK does not look inside this file.
(Needs Investigation) SOL004 has option 1 (signing each artifact individually / individual digest) and option 2 (sign entire package). It would be nice if VNF SDK supported both Option 1 and Option 2.
(Needs Investigation) VNF-SDK option 1/2 support still needs investigation (as of Feb 18, 2019). Need to clarify how to do the test.
ASSOCIATED DEVELOPMENT:
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
QUESTION is the file is not there will the process abort or is a warning given?
R4
HIGH
Check keywords. needs VNF SDK to check the PNF keywords. in the MainServiceTemplate.mf there are new tags:
- pnf_product_name pnf_provider_id,
- pnf_package_version,
- pnf_release_date_time
- non_mano_artifact_sets;
and the NON ETSI MANO artifact tags public tags. These public tags are under the "non_mano_artifact_sets". This would be NEW development in VNF SDK. An example Manifest file is shown in this diagram:
metadata:pnf_product_name: gNBpnf_provider_id: Ericssonpnf_package_version:1.0pnf_release_date_time:2018-12-03T08:44:00-05:00non_mano_artifact_sets:onap_ves_events:source: Artifacts/Deployment/Events/VES_registration.yamlonap_pm_dictionary:source: Artifacts/Deployment/Measurements/PM_Dictionary.yamlonap_yang_module:source: Artifacts/Deployment/Yang_module/Yang_module.yamlonap_others:source: Artifacts/Informational/scripts/install.shsource: Artifacts/Informational/user_guide.txtsource: Artifacts/Other/installation_guide.txtsource: Artifacts/Other/review_log.txt
which shows the use of some of these fields
#8: PNF PACKAGE TESTING
(Test Only)
Enhancement of Package Testing. A item to make sure that integration testing is performed and that VNF-SDK supports the functions as will be described in the Requirements work. Testing the package against the requirements (a user can enter a requirement#) VNF-RQTS project.
It would be ideal if the PNF Package used by the VNF-SDK work is shared by the rest of the PNF preonboarding/onboarding development & integration.
ASSOCIATED DEVELOPMENT:
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
R4
HIGH
R5 EL ALTO
LOW PRI
SDC license model check. Potential ARTIFACTS: Vendor license model & agreement, features. VNF can have >1 features, entitlement pool, license key pools, actual keys.
[Low Priority] PUSH TO R5 EL ALTO.
R5 EL ALTO
LOW PRI
the following diagram illustrates the VNF SDK work to check the new PNF tags in Task #4
The following diagram illustrates the VNF-SDK Task #5 check of the TOSCA Meta file Checks:
PNF ONBOARDING PACKAGE: PNF ONBOARDING PACKAGE LOADED
PNF Onboarding Package (vendor provided) is successfully loaded into ONAP.
In Dublin timeframe, the focus is the onboarding package mapping in the internal package and AID model.
DESIGN TIME ACTIVITIES: SDC ONBOARDING PACKAGE
SDC takes the Vendor provided package and adds some files or changes files and meta data according to SDC procedure.
The following is the SDC onboarding procedure
The following diagram is an example of the the proposed PNF package in Dublin
The following is the VSA csar generated from a onboarding PNF package
The following is the VF csar imported from a PNF VSP
The following is the service csar example with twp PNF and one VNF included
The following diagram shows the mapping from the Vendor-provided PNF onboarded package into the SDC Internal PNF Onboarding package.
For model info about the PNF onboarding package format and an example of the format refer to ONAP R4+ Onboarding PNF package format and PNF package mapping
DESIGN TIME ACTIVITIES: SDC ONBOARDING PACKAGE MAPPING INTO INTERNAL PACKAGE
SDC is used to map the Vendor provided onboarding package & PNF descriptor into the Internal Package & Internal (Platform) Data Model
DESIGN TIME ACTIVITIES: SDC ONBOARDING PACKAGE INTO SDC CATALOG
SDC Design Studio is then used to define a Service, and the output of that is a CSAR package which defines the Service.
Enhancements to SDC to take PNF Onboarding Package into the SDC Catalog
SDC distributes services
NF CSAR package includes the artifacts and information for the resources for a service.
There is one CSAR file which includes all of the definition for that service.
The work-flows are created by SDC DS.
DESIGN TIME ACTIVITIES: LICENSING MANAGEMENT & SCHEMA
DEFINITION: The licensing schema could vary and be dependent upon the service provider. Licensing schema is expected to be used to identify or authorize the existence a particular PNF into the network of the service provider. It might also be possible that multiple licenses are needed for different functions or authentication. It may also be important to provide a license during PNF Plug and Play. This implies that the Service Provider has defined a licensing schema or has licensing management software to manage licenses.
R4 DUBLIN: For Dublin, it is to be determined what will be done (maybe nothing). This is likely to be FUTURE work (El Alto and beyond)
Note: SDC adds files related to Licensing AFTER Onboarding.
Note: this might be able to refreshed yearly. And the file might be updated periodically. e.g. the xNF is properly orchestrated and then a year later the license expires. Artifacts associated w/ a xNF are static except the license file (or license certificate). License file renewal. Part of the recipe communicate w/ central license manager to obtain license to use for the xNF.
...
| R4 High | |||||||||||
| #5: VALIDATION FOR META DATA CHECK (ETSI SOL004) | Following ETSI SOL004 Validation for Meta-Data file and Manufacturer file, this is the TOSCA.meta file that is part of the PNF Package. Both VNF SDK implementing only meta-data option, in the package there is a meta file. Check TOSCA.meta, while this file is not mandatory, when it is included that it follows the SOL004 standard (ETSI). We expect that "TOSCA-Meta-Version" and "CSAR-Version" and "Created by" are already supported, and new checks for "Entry definition, Entry-manifest, Entry-change-log, Entry-tests, Entry-certificates" would be new VNF SDK development work (needs to be verified). VNF SDK does the check the TOSCA.meta file today, if a few keywords is there. ASSOCIATED DEVELOPMENT:
| R4 HIGH | ||||||||||
| #6: PACKAGE SECURITY | Driven from SOL004: Option 1 (Supported in R4 Dublin): TOSCA.meta (exists) Meta-directory based, XML based approach. Option 2 (NOT support in R4 Dublin): CSAR without TOSCA.meta. Manifest (.mf) file that has everything (so the TOSCA.meta is redundant). Yaml-based approach. The Public Key a key to open the package. SOL004 Option 1, 2 and use key to open the package - X.509 certificates public key, private key to sign the package and private key correspond to the private key of the package also delivered with the package. a package, a signature, and public key certificate delivered together. There may be more than one signature. Option 1 there is a digest for every file. All of those digests are listed in the manifest file. The manifest file is signed, one signature on the manifest. One signature and one key/pair & 1 certificate. Still optional to sign other files. The signature is a file beside. myimage.iso myimage.xyz but the same file/directory. Every file signed should have a signature files. CSAR file signed in a .sm file, package signature. The public key is signed can be signed by a root certificate. An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate. (investigate) if VNF-SDK would like to use AAF as the CA. Can AAF perform the CA functions. To open the package need: (1) Public Key (to open the manifest file) (2) file input (3) certificate input. create a hash, the hash is verified against the signature. SHA-256 | |||||||||||
| #7: PNF DESCRIPTOR | The descriptor. There is validation of the VNFD. PNF Descriptor: TOSCA descriptor, and validate the node type. Validation of TOSCA PNFD. Following TOSCA rules. Components required are there. (NEEDS INVESTIGATION) VNFSDK check the VNFD based on VNF requirements. ASSOCIATED DEVELOPMENT:
| R4 HIGH | ||||||||||
#8: PNF PACKAGE TESTING (Test Only) | Enhancement of Package Testing. A item to make sure that integration testing is performed and that VNF-SDK supports the functions as will be described in the Requirements work. Testing the package against the requirements (a user can enter a requirement#) VNF-RQTS project. It would be ideal if the PNF Package used by the VNF-SDK work is shared by the rest of the PNF preonboarding/onboarding development & integration. ASSOCIATED DEVELOPMENT:
| R4 HIGH | ||||||||||
| LOW PRIORITY / PUSHED TO R5 EL ALTO | ||||||||||||
| #F1: CREATE PACKAGE FUNCTION FOR PNF | The create package function creates the metadata files, and CSAR files. This needs to be modified to support SOL004. (NEEDS INVESTIGATION) [Low Priority] | R5 EL ALTO LOW PRI | ||||||||||
| #F2: TOSCA Metafile License Content Check | SDC license model check. Potential ARTIFACTS: Vendor license model & agreement, features. VNF can have >1 features, entitlement pool, license key pools, actual keys. [Low Priority] PUSH TO R5 EL ALTO. | R5 EL ALTO LOW PRI | ||||||||||
the following diagram illustrates the VNF SDK work to check the new PNF tags in Task #4
The following diagram illustrates the VNF-SDK Task #5 check of the TOSCA Meta file Checks:
PNF ONBOARDING PACKAGE: PNF ONBOARDING PACKAGE LOADED
PNF Onboarding Package (vendor provided) is successfully loaded into ONAP.
In Dublin timeframe, the focus is the onboarding package mapping in the internal package and AID model.
DESIGN TIME ACTIVITIES: SDC ONBOARDING PACKAGE
SDC takes the Vendor provided package and adds some files or changes files and meta data according to SDC procedure.
The following is the SDC onboarding procedure
The following diagram shows the mapping from the Vendor-provided PNF onboarded package into the SDC Internal PNF Onboarding package.
For model info about the PNF onboarding package format and an example of the format refer to ONAP R4+ Onboarding PNF package format and PNF package mapping
DESIGN TIME ACTIVITIES: SDC ONBOARDING PACKAGE MAPPING INTO INTERNAL PACKAGE
SDC is used to map the Vendor provided onboarding package & PNF descriptor into the Internal Package & Internal (Platform) Data Model
DESIGN TIME ACTIVITIES: SDC ONBOARDING PACKAGE INTO SDC CATALOG
SDC Design Studio is then used to define a Service, and the output of that is a CSAR package which defines the Service.
Enhancements to SDC to take PNF Onboarding Package into the SDC Catalog
SDC distributes services
NF CSAR package includes the artifacts and information for the resources for a service.
There is one CSAR file which includes all of the definition for that service.
The work-flows are created by SDC DS.
DESIGN TIME ACTIVITIES: LICENSING MANAGEMENT & SCHEMA
DEFINITION: The licensing schema could vary and be dependent upon the service provider. Licensing schema is expected to be used to identify or authorize the existence a particular PNF into the network of the service provider. It might also be possible that multiple licenses are needed for different functions or authentication. It may also be important to provide a license during PNF Plug and Play. This implies that the Service Provider has defined a licensing schema or has licensing management software to manage licenses.
R4 DUBLIN: For Dublin, it is to be determined what will be done (maybe nothing). This is likely to be FUTURE work (El Alto and beyond)
Note: SDC adds files related to Licensing AFTER Onboarding.
Note: this might be able to refreshed yearly. And the file might be updated periodically. e.g. the xNF is properly orchestrated and then a year later the license expires. Artifacts associated w/ a xNF are static except the license file (or license certificate). License file renewal. Part of the recipe communicate w/ central license manager to obtain license to use for the xNF.
Note: In ETSI SOL the license key is not part of the package. The PNF package has a license term file(describes the terms of the license).
Note: (Feb 4) Model team said "this is still a work in Progress for R4" - Potential ARTIFACTS: Vendor license model & agreement, features. VNF can have >1 features, entitlement pool, license key pools, actual keys.
Note: (Feb 4) Model team said "this is still a work in Progress for R4" - Potential ARTIFACTS: Vendor license model & agreement, features. VNF can have >1 features, entitlement pool, license key pools, actual keys.
PNF PACKAGE SECURITY
PNF Package Security.
According to ETSI SOL004 v2.5.1 the onboarding package shall be signed. ETSI SOL004 provides two options:
Option 1 - One Digest for each components of the VNF package. The table of hashes is included in the manifest file, which is signed with the VNF provider private key. A signing certificate including the provider’s public key shall be included in the package.
Option 2 - The complete CSAR file shall be digitally signed with the provider private key. The provider delivers one zip file consisting of the CSAR file, a signature file and a certificate file that includes the VNF provider public key.
In Dublin release option 2 is going to be implemented in SDC.
- The VNF/PNF package authenticity and integrity is ensured by signing the CSAR file with the provider private key. The digital signature is stored in a separate file.
- The VNF/PNF provider shall also include an X.509 certificate in a separate file with extension .cert or, if the signature format allows it, in the signature file itself. The VNF/PNF provider creates a zip file consisting of the CSAR file, signature and certificate files. The signature and certificate files shall be siblings of the CSAR file with extensions .sm and .cert respectively.
- No digest is required in the manifest file. But it is recommended to include individual signatures of the artifacts. the signatures of the artifacts are stored in separate files together with the artifacts using the same name and location as the artifact but with an extension .sm
- At pre-onboarding of the PNF/VNF package, VNFSDK tool could verify the signature of the complete CSAR package with the provider’s public key
- At onboarding of the PNF/VNF package, SDC could verify the signature of the complete CSAR package with the provider’s public key.
Reference info about X.509
An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate.
X.509 certificates act as secure identifiers, digital passports which contain information about the owner. The certificate is tied to a public key value which is associated with the identity contained in the certificate. This tells the application or server that the entity trying to access it is legitimate and known, and should be given access. The certificate contains information regarding the subject of a certificate (the owner) and the issuing certification authority (CA).
X.509 certificates include:
- Owner’s information or subject distinguished name (DN)
- Public key associated with the subject
- Version information
- Serial number of the certificate
- Another distinguished name identifying the issuer of the certificate (CA)
- Digital signature of the CA
- Information on the algorithm used to create the digital certificate
To ensure the validity of the certificate, it must be signed by a certification authority, which is a trusted node that confirms the integrity of the public key value contained in the certificate. The certificate is signed by the CA by adding a digital signature encoded with the CA’s private key. The CA has a declared public key which is known by all supporting applications and devices, who then validate a certificate by decoding the digital signature within the certificate using the CA’s public key.
PNF UI (User Interface)
Simulator.
PM/FM (UI) User Interface.
...