24
Home VirtNP3GPP

4.2.3.3.5.2 VNF package and VNF image integrity

Home VirtNP3GPP18.2.0
33527-i00   33527-i01   33527-i10    33527-i20 33527-i30   33527-j00  
Test Name TC_VNF PACKAGE AND IMAGE_ INTEGRITY
Threat Reference

Clause 5.3.2.5.1 of the TR 33.927[2], "Software Tampering ";

Requirement Name

VNF package and VNF image integrity

Requirement Reference
Requirement Description
  1. VNF package and image shall contain integrity validation value (e.g. MAC).

  2. VNF package shall be integrity protected during on boarding.

Test Purpose
  1. To test whether the VNF package has been integrity protected or not.

  2. To test whether the VNF image has been integrity protected or not.

Pre-Conditions
  • The virtualized network product document describes information regarding integrity protection of VNF package and VNF images, including details of how the integrity check is carried out, who makes the digital signatures of VNF package, what evidence is created to prove that the integrity check has been executed and what the result of the check is, etc.

  • A valid VNF package and a not-valid VNF package (i.e. a tampered image in VNF package) are available.

  • A valid VNF image (i.e. a correct HASH value is attached) and a not-valid VNF image (i.e. an incorrect HASH value is attached, e.g. the VNF image can be tampered when the VNF image is sent from the NFVO to the VIM or when the VNF image is stored in the image repository) are available in the image repository of VIM.

  • There are NFVO and VIM, or simulated NFVO and VIM. The certificate or the public key which is used to verify the digital signature of VNF package and image has been pre-configured in the NFVO and VIM respectively.

Execution Steps

Execute the following steps:

  1. Review the documentation provided by the vendor describing how VNF package integrity is verified;

  2. During VNF package on boarding, the tester uploads a valid VNF package into a NFVO. The NFVO verifies the integrity of the VNF package by validating the digital signature of the VNF package using the pre-configured certificate or public key according to the documentation;

  3. During VNF package on boarding, the tester uploads a not-valid VNF package into a NFVO. The NFVO validates the digital signature of the VNF package using the pre-configured certificate or public key;

  4. During VNF instantiation, the VIM selects a VNF image with a correct integrity protection value from the image repository to instantiate the VNF image. The VIM validates the correctness of the integrity protection value using the pre-configured certificate or public key according to the documentation;

  5. During VNF instantiation, the VIM selects a VNF image with an incorrect integrity protection value from the image repository to instantiate the VNF image. The VIM validates the correctness of the integrity protection value using the pre-configured certificate or public key according to the documentation.

Expected Results
  1. The VNF package is successfully on boarded into the NFVO;

  2. The not-valid VNF package is not on boarded;

  3. The VNF image with a correct integrity protection value is instantiated by the VIM;

  4. The VNF image with an incorrect integrity protection value is not instantiated by the VIM.

Expected Format of Evidence

Snapshots containing the result of the VNF package on boarding and the VNF image instantiation.

PDFs 4aa5435e87394b3df64d7be159a0944f

4.2.3.3.5.2 VNF package and VNF image integrity

Home VirtNP3GPP19.0.0
33527-i00   33527-i01   33527-i10   33527-i20   33527-i30    33527-j00
Test Name
TC_VNF_PACKAGE_AND_IMAGE_INTEGRITY
Threat Reference

Clause 5.3.2.5.1 of the TR 33.927[2], "Software Tampering ";

Requirement Name

VNF package and VNF image integrity

Requirement Reference
Requirement Description
  1. VNF package and image shall contain integrity validation value (e.g. MAC).

  2. VNF package shall be integrity protected during on boarding.

Test Purpose
  1. To test whether the VNF package has been integrity protected or not.

  2. To test whether the VNF image has been integrity protected or not.

Pre-Conditions
  • The virtualized network product document describes information that the VNF package and VNF images is integrity protected.

  • A valid VNF package and a not-valid VNF package (i.e. a tampered image in VNF package) are available.

  • A valid VNF image (i.e. a correct HASH value is attached) and a not-valid VNF image (i.e. an incorrect HASH value is attached, e.g. the VNF image can be tampered when the VNF image is sent from the NFVO to the VIM or when the VNF image is stored in the image repository) are available in the image repository of VIM.

  • There are NFVO and VIM, or simulated NFVO and VIM. The certificate or the public key which is used to verify the digital signature of VNF package and image has been pre-configured in the NFVO and VIM respectively.

NOTE: The NFVO and VIM may be renamed or collocated with other components in the simulated environment based on the various deployment options.

Execution Steps

Execute the following steps:

  1. Review the documentation provided by the vendor describing how VNF package integrity is verified;

  2. During VNF package on boarding, the tester uploads a valid VNF package into a NFVO. The NFVO verifies the integrity of the VNF package by validating the digital signature of the VNF package using the pre-configured certificate or public key according to the documentation;

  3. During VNF package on boarding, the tester uploads a not-valid VNF package into a NFVO. The NFVO validates the digital signature of the VNF package using the pre-configured certificate or public key;

  4. During VNF instantiation, the VIM selects a VNF image with a correct integrity protection value from the image repository to instantiate the VNF image. The VIM validates the correctness of the integrity protection value using the pre-configured certificate or public key according to the documentation;

  5. During VNF instantiation, the VIM selects a VNF image with an incorrect integrity protection value from the image repository to instantiate the VNF image. The VIM validates the correctness of the integrity protection value using the pre-configured certificate or public key according to the documentation.

Expected Results
  1. The VNF package is successfully verified;

  2. The verification of not-valid VNF package is failure. ;

  3. The VNF image with a correct integrity protection value is successfully verified;

  4. The verification of VNF image with an incorrect integrity protection value is failure. .

Expected Format of Evidence

Snapshots containing the result of the VNF package on boarding and the VNF image instantiation.

PDFs aa2dead51b76b7653eec847f9685f20e

4.2.7.1 Security functional requirements on GVNP lifecycle management

Home VirtNP3GPP18.2.0
33527-i00   33527-i01   33527-i10    33527-i20 33527-i30   33527-j00  
Test Name TC_LIFECYCLE MANAGEMENT SECURITY
Threat Reference

Threats on interface between 3GPP VNF and VNFM, in clause 5.3.2.3 of TR 33.927 [3].

Requirement Name

GVNP lifecycle management security

Requirement Reference
Requirement Description
  1. VNF shall authenticate VNFM when VNFM initiates a communication to VNF.

  2. VNF shall be able to establish securely protected connection with the VNFM.

  3. VNF shall check whether VNFM has been authorized when VNFM access VNF's API.

  4. VNF shall log VNFM's management operations for auditing.

Note: According to the definition in ETSI GS NFV 003 [6], VNFM is responsible for the lifecycle management of VNF. The lifecycle management of VNF is set of functions required to manage the instantiation, maintenance and termination of VNF. The GVNP of type 1 is 3GPP VNF. A 3GPP VNF lifecycle management begins when the 3GPP VNF is instantiated by a VNFM after the 3GPP VNF package is delivered to the operator and uploaded to NFVO. It is different terminology with the product lifecycle management process in clause 6 that includes set of functions required to manage first commercial introduction, update, minor release, major release, end of life.

Test Purpose
  1. To test the VNF authenticates VNFM when VNFM initiates a communication to VNF.

  2. To test the VNF establishes secure connection with the VNFM after successful authentication.

  3. To test the VNF check whether VNFM has been authorized when VNFM access to VNF's API.

  4. To check whether VNF logs the lifecycle management operations from VNFM.

Note: Void

Pre-Conditions

NOTE: If the interface between VNF and VNFM is not exposed and not accessible, execution steps 1-5 are not applicable. If the interface between VNF and VNFM is proprietary, the vendor provides as much and as detailed information on the interface implementation so that the tester is able to verify the interfaces security requirements.

  1. There is a VNFM (or simulated VNFM) in the test environment.

  2. The VNF vendor's document describes how VNF authenticates/authorizes VNFM. Execution Steps

Execute the following steps:

  1. The tester triggers the establishment of communication between the VNF and the VNFM.

  2. The tester captures the communication between the VNF and the VNFM using a tool (e.g. wireshark).

  3. The tester checks whether the VNF authenticates the VNFM or not according to the mechanism described in the vendor's document. For example, the VNF can use HTTPS to communicate with the VNFM, the VNF uses VNFM's certificate for authentication.

  4. The tester checks whether the VNF establishes secure connection with the VNFM after successful authentication. For example, a TLS connection is established after the VNF successfully authenticates the VNFM.

  5. The tester using the VNFM to access the VNF's API and checks whether the VNF authorizes the VNFM or not according to the mechanism described in the vendor's document. For example, VNF can use OAuth2.0 to authorize the VNFM. The VNF uses VNFM's token for authorization.

  6. The tester checks whether the VNF logs the operations from VNFM or not.

Execution Steps
Expected Results
  1. Secure communication is established between VNF and VNFM with integrity and confidentiality protection.

  2. The VNFM successfully accesses the VNF's API.

  3. The VNF logs the operations from VNFM.

Expected Format of Evidence
  1. Pcap traces contain the authentication and authorization processes.

  2. Screenshot contains the logs.

PDFs 61dd0e55c1d77b6e8ff1a28a5efbe6b0

4.2.7.1 Security functional requirements on GVNP lifecycle management

Home VirtNP3GPP19.0.0
33527-i00   33527-i01   33527-i10   33527-i20   33527-i30    33527-j00
Test Name
TC_LIFECYCLE_MANAGEMENT_SECURITY
Threat Reference

Threats on interface between 3GPP VNF and VNFM, in clause 5.3.2.3 of TR 33.927 [3].

Requirement Name

GVNP lifecycle management security

Requirement Reference
Requirement Description
  1. VNF shall authenticate VNFM when VNFM initiates a communication to VNF.

  2. VNF shall be able to establish securely protected connection with the VNFM.

  3. VNF shall check whether VNFM has been authorized when VNFM access VNF's API.

  4. VNF shall log VNFM's management operations for auditing.

Note: According to the definition in ETSI GS NFV 003 [6], VNFM is responsible for the lifecycle management of VNF. The lifecycle management of VNF is set of functions required to manage the instantiation, maintenance and termination of VNF. The GVNP of type 1 is 3GPP VNF. A 3GPP VNF lifecycle management begins when the 3GPP VNF is instantiated by a VNFM after the 3GPP VNF package is delivered to the operator and uploaded to NFVO. It is different terminology with the product lifecycle management process in clause 6 that includes set of functions required to manage first commercial introduction, update, minor release, major release, end of life.

Test Purpose
  1. To test the VNF authenticates VNFM when VNFM initiates a communication to VNF.

  2. To test the VNF establishes secure connection with the VNFM after successful authentication.

  3. To test the VNF check whether VNFM has been authorized when VNFM access to VNF's API.

  4. To check whether VNF logs the lifecycle management operations from VNFM.

Note: Void

Pre-Conditions

NOTE: If the interface between VNF and VNFM is not exposed and not accessible, execution steps 1-5 are not applicable. If the interface between VNF and VNFM is proprietary, the vendor provides as much and as detailed information on the interface implementation so that the tester is able to verify the interfaces security requirements.

  1. There is a VNFM (or simulated VNFM) in the test environment.

  2. The VNF vendor's document describes how VNF authenticates/authorizes VNFM. Execution Steps

Execute the following steps:

  1. The tester triggers the establishment of communication between the VNF and the VNFM.

  2. The tester captures the communication between the VNF and the VNFM using a tool (e.g. wireshark).

  3. The tester checks whether the VNF authenticates the VNFM or not according to the mechanism described in the vendor's document. For example, the VNF can use HTTPS to communicate with the VNFM, the VNF uses VNFM's certificate for authentication.

  4. The tester checks whether the VNF establishes secure connection with the VNFM after successful authentication. For example, a TLS connection is established after the VNF successfully authenticates the VNFM.

  5. The tester using the VNFM to access the VNF's API and checks whether the VNF authorizes the VNFM or not according to the mechanism described in the vendor's document. For example, VNF can use OAuth2.0 to authorize the VNFM. The VNF uses VNFM's token for authorization.

  6. The tester checks whether the VNF logs the operations from VNFM or not.

Execution Steps
  1. The tester triggers the establishment of communication between the VNF and the VNFM.

  2. The tester captures the communication between the VNF and the VNFM using a tool (e.g. wireshark).

  3. The tester checks whether the VNF authenticates the VNFM or not according to the mechanism described in the vendor's document. For example, the VNF can use HTTPS to communicate with the VNFM, the VNF uses VNFM's certificate for authentication.

  4. The tester checks whether the VNF establishes secure connection with the VNFM after successful authentication. For example, a TLS connection is established after the VNF successfully authenticates the VNFM.

  5. The tester using the VNFM to access the VNF's API and checks whether the VNF authorizes the VNFM or not according to the mechanism described in the vendor's document. For example, VNF can use OAuth2.0 to authorize the VNFM. The VNF uses VNFM's token for authorization.

  6. The tester checks whether the VNF logs the operations from VNFM or not.

Expected Results
  1. Secure communication is established between VNF and VNFM with integrity and confidentiality protection.

  2. The VNFM successfully accesses the VNF's API.

  3. The VNF logs the operations from VNFM.

Expected Format of Evidence
  1. Pcap traces contain the authentication and authorization processes.

  2. Screenshot contains the logs.

PDFs 9fc632383147fbd7fc7f1394a3b49142

4.2.7.2 Security functional requirements on executive environment provision

Home VirtNP3GPP18.2.0
33527-i00   33527-i01   33527-i10    33527-i20 33527-i30   33527-j00  
Test Name TC_SECURE EXECUTIVE ENVIRONMENT PROVISION
Threat Reference

Threats on interface between 3GPP VNF and virtualisation layer, in clause 5.3.2.3 of TR 33.927 [3].

Requirement Name

secure executive environment provision

Requirement Reference
Requirement Description

The VNF shall support to compare the owned resource state with the parsed resource state from VNFD (VNF Description) by the VNFM. The VNF can query the parsed resource state by the VNFM from the OAM. The VNF shall send an alarm to the OAM if the two resource states are inconsistent. This comparing process can be triggered periodically by the VNF, or the administrator can manually trigger the VNF to perform the comparing process.

Test Purpose
  1. To test whether the VNF compares the owned resource state with the parsed resource state.

  2. To test whether the VNF send an alarm to the OAM if the two resource states are inconsistent.

Pre-Conditions

There are a VNF, a virtualization layer (or simulated virtualization layer), an OAM, a VNFM, a VIM (or simulated OAM, VNFM, VIM) on the test environment.

Execution Steps

Execute the following steps:

  1. The tester utilizes the virtualization layer to change the resource state of VNF (e.g. change vCPU size of the VNF).

  2. The tester uses the VNF to query the parsed resource state from the OAM.

  3. The tester uses the OAM to query the parsed resource state of the VNF from the VNFM and send the received resource state to the VNF.

  4. The tester checks whether the VNF sends an alarm to the OAM when the VNF receives the parsed resource state from the OAM and finds that the owned resource state and the parsed resource state are inconsistent.

Expected Results
  1. The VNF send an alarm to the OAM when the VNF receives the parsed resource state from the OAM and find that the owned resource state and the parsed resource state are inconsistent.
Expected Format of Evidence
  1. Screenshot contains the alarm on the OAM.
PDFs d475915204fc027f1ade961b7e5ad22f

4.2.7.2 Security functional requirements on executive environment provision

Home VirtNP3GPP19.0.0
33527-i00   33527-i01   33527-i10   33527-i20   33527-i30    33527-j00
Test Name
TC_SECURE_EXECUTIVE_ENVIRONMENT_PROVISION
Threat Reference

Threats on interface between 3GPP VNF and virtualisation layer, in clause 5.3.2.3 of TR 33.927 [3].

Requirement Name

secure executive environment provision

Requirement Reference
Requirement Description

The VNF shall support to compare the owned resource state with the parsed resource state from VNFD (VNF Description) by the VNFM. The VNF can query the parsed resource state by the VNFM from the OAM. The VNF shall send an alarm to the OAM if the two resource states are inconsistent. This comparing process can be triggered periodically by the VNF, or the administrator can manually trigger the VNF to perform the comparing process.

Test Purpose
  1. To test whether the VNF compares the owned resource state (e.g. scale) with the parsed resource state.

  2. To test whether the VNF send an alarm to the OAM if the two resource states are inconsistent.

Pre-Conditions

There are a VNF, a virtualization layer (or simulated virtualization layer), an OAM, a VNFM, a VIM (or simulated OAM, VNFM, VIM) on the test environment.

NOTE: This test case is applicable only for the scenario that the virtualization layer is able to change the resource state of VNF.

Execution Steps

Execute the following steps:

  1. The tester utilizes the virtualization layer to change the resource state of VNF (e.g. change vCPU size of the VNF).

  2. The tester uses the VNF to query the parsed resource state from the OAM.

  3. The tester uses the OAM to query the parsed resource state of the VNF from the VNFM and send the received resource state to the VNF.

  4. The tester checks whether the VNF sends an alarm to the OAM when the VNF receives the parsed resource state from the OAM and finds that the owned resource state and the parsed resource state are inconsistent.

Expected Results

The VNF send an alarm to the OAM when the VNF receives the parsed resource state from the OAM and find that the owned resource state and the parsed resource state are inconsistent.

Expected Format of Evidence

Screenshot contains the alarm on the OAM.

PDFs 12f5c18d0259855a9eca5c15acb392bd

4.2.7.3 Instantiating VNF from trusted VNF image

Home VirtNP3GPP18.2.0
33527-i01   33527-i10    33527-i20 33527-i30   33527-j00  
Test Name TC_INSTANTIATING VNF _ TRUSTED IMAGE
Threat Reference

TR 33.926 [7], Clause5.3.4.1, "Software Tampering ";

Requirement Name

Instantiating VNF from trusted VNF image

Requirement Reference
Requirement Description

A VNF shall be initiated from trusted images in a VNF package. The VNF image(s) shall be signed by an authorized party. The authorized party is trusted by the operators.

Test Purpose

To test whether the instantiating VNF from trusted VNF image.

Pre-Conditions
  • The virtualized network product document describes information regarding digital signature protection of VNF images, including details of how the signature check is carried out, who makes the digital signature of VNF image etc.

  • One VNF package included two trusted VNF images and the VNF package carries a correct digital signature of the VNF package.

  • Another VNF package included untrusted VNF image which carry wrong digital signature of VNF image and the VNF package carries a correct digital signature of the VNF package.

  • There are a NFVO, or a simulated NFVO. A certificate or public key which is used to verify the digital signature of VNF image has been pre-configured in the NFVO. This certificate is trusted by the operator. It means the digital signature of the VNF image is successfully verified by using the public key in the certificate trusted by the operator

Execution Steps

Execute the following steps:

  1. Review the documentation provided by the vendor describing how digital signature of the VNF image is verified;

  2. The tester uploads a VNF package included two trusted VNF images into a NFVO. The NFVO verifies the VNF images by validating each digital signature of the VNF image using the pre-configured certificate or the public key according to the documentation;

  3. The tester uploads another VNF package included un-trusted VNF image into NFVO. The NFVO verifies the VNF image(s) by validating each digital signature of the VNF image using the pre-configured certificate or the public key according to the documentation.

Note: The digital signature validation of the image is also described in clause 4.2.3.3.5.2 VNF package and VNF image integrity, but the two test cases have the different test purposes. This test case focuses on VNF image credibility, while clause 4.2.3.3.5.2 is concerned with VNF image integrity.

Expected Results
  1. In the step 2, the signatures of the VNF images are successfully validated and the VNF package is successfully on boarded into the NFVO;

  2. In the step 3, the signature of the un-trusted VNF image is failed to be validated and the VNF package is not on boarded into the NFVO;

Expected Format of Evidence

Snapshots containing the result of the VNF package on boarding.

PDFs 294cada30f38ce4d578f115beeb8b30f

4.2.7.3 Instantiating VNF from trusted VNF image

Home VirtNP3GPP19.0.0
33527-i01   33527-i10   33527-i20   33527-i30    33527-j00
Test Name
TC_INSTANTIATING_VNF_TRUSTED_IMAGE
Threat Reference

TR 33.926 [7], Clause5.3.4.1, "Software Tampering ";

Requirement Name

Instantiating VNF from trusted VNF image

Requirement Reference
Requirement Description

A VNF shall be initiated from trusted images in a VNF package. The VNF image(s) shall be signed by an authorized party. The authorized party is trusted by the operators.

Test Purpose

To test whether the instantiating VNF from trusted VNF image.

Pre-Conditions
  • The virtualized network product document describes information that the VNF images is integrity protected.

  • One VNF package included two trusted VNF images and the VNF package carries a correct digital signature of the VNF package.

  • Another VNF package included untrusted VNF image which carry wrong digital signature of VNF image and the VNF package carries a correct digital signature of the VNF package.

  • There are a NFVO, or a simulated NFVO. A certificate or public key which is used to verify the digital signature of VNF image has been pre-configured in the NFVO. This certificate is trusted by the operator. It means the digital signature of the VNF image is successfully verified by using the public key in the certificate trusted by the operator

NOTE: The NFVO and VIM may be renamed or collocated with other components in the simulated environment based on the various deployment options.

Execution Steps

Execute the following steps:

  1. Review the documentation provided by the vendor describing how digital signature of the VNF image is verified;

  2. The tester uploads a VNF package included two trusted VNF images into a NFVO. The NFVO verifies the VNF images by validating each digital signature of the VNF image using the pre-configured certificate or the public key according to the documentation;

  3. The tester uploads another VNF package included un-trusted VNF image into NFVO. The NFVO verifies the VNF image(s) by validating each digital signature of the VNF image using the pre-configured certificate or the public key according to the documentation.

Note: The digital signature validation of the image is also described in clause 4.2.3.3.5.2 VNF package and VNF image integrity, but the two test cases have the different test purposes. This test case focuses on VNF image credibility, while clause 4.2.3.3.5.2 is concerned with VNF image integrity.

Expected Results
  1. In the step 2, the signatures of the VNF images are successfully validated;

  2. In the step 3, the signature of the un-trusted VNF image is failed to be validated;

Expected Format of Evidence

Snapshots containing the result of the VNF package on boarding.

PDFs b2bb495c12b9b9ea8fc7c10f0f91bc1e

4.3.6.2 Separation of inter-VNF and intra-VNF traffic

Home VirtNP3GPP18.2.0
33527-i00   33527-i01   33527-i10    33527-i20 33527-i30   33527-j00  
Test Name TC_TRAFFIC_SEPARATION_INTER-VNF_INTRA-VNF
Threat Reference

Security threat caused by lack of GVNP traffic isolation in clause 5.3.2.7.15 of TR 33.927 [3]

Requirement Name

inter-VNF and intra-VNF Traffic Separation

Requirement Reference
Requirement Description

The network used for the communication between the VNFCIs of a VNF (intra-VNF traffic) and the network used for the communication between VNFs (inter-VNF traffic) shall be separated to prevent the security threats from the different networks affect each other.

Test Purpose

To test whether the traffics between inter-VNF traffic and intra-VNF traffic are separated.

Pre-Conditions
  1. There has a VNF instance on the test environment. This VNF instance has more than one VNFCI (VNF component Instance). The network between VNFCIs means intra-VNF network which is private network provided by vendor.

  2. The document which describes how to separate the inter-VNF traffic with the intra-VNF traffic has been provided by the vendor. For example, the different network segments are described in the document.

  3. Another VNF instance (or a simulated VNF instance) is on the test environment and can communicate with the tested VNF instance.

Execution Steps

Execute the following steps:

  1. The tester checks whether the inter-VNF traffic and intra-VNF traffic are separated according the document by the vendor. For example, the tester checks whether the different network segments used by inter-VNF traffic and intra-VNF traffic respectively.

  2. The tester checks whether a VNFCI refuses inter-VNF traffic on all intra-VNF interfaces. For example, the tester can send ping to all intra-VNF interfaces through an inter-VNF interface.

  3. The tester checks whether a VNFCI refuses intra-VNF traffic on all inter-VNF interfaces. For example, the tester can send ping to all inter-VNF interfaces through an intra-VNF interface.

Expected Results

In the step 1, the inter-VNF traffic and intra-VNF traffic are separated according the document by the vendor. In the step 2 and step 3, the VNFCI refuses traffic.

Expected Format of Evidence

A PASS or FAIL.

PDFs 84c8f1cf01482a03eb762d5da3adb76e

4.3.6.2 Separation of inter-VNF and intra-VNF traffic

Home VirtNP3GPP19.0.0
33527-i00   33527-i01   33527-i10   33527-i20   33527-i30    33527-j00
Test Name TC_TRAFFIC_SEPARATION_INTER-VNF_INTRA-VNF
Threat Reference

Security threat caused by lack of GVNP traffic isolation in clause 5.3.2.7.15 of TR 33.927 [3]

Requirement Name

inter-VNF and intra-VNF Traffic Separation

Requirement Reference
Requirement Description

The network used for the communication between the VNFCIs of a VNF (intra-VNF traffic) and the network used for the communication between VNFs (inter-VNF traffic) shall be separated to prevent the security threats from the different networks affect each other.

Test Purpose

To test whether the traffics between inter-VNF traffic and intra-VNF traffic are separated.

Pre-Conditions
  1. There has a VNF instance on the test environment. This VNF instance has more than one VNFCI (VNF component Instance). The network between VNFCIs means intra-VNF network which is private network provided by vendor.

  2. The document which describes how to separate the inter-VNF traffic with the intra-VNF traffic has been provided by the vendor. For example, the different network segments are described in the document.

  3. Another VNF instance (or a simulated VNF instance) is on the test environment and can communicate with the tested VNF instance.

Execution Steps

Execute the following steps:

  1. The tester checks whether the inter-VNF traffic and intra-VNF traffic are separated according the document by the vendor. For example, the tester checks whether the different network segments used by inter-VNF traffic and intra-VNF traffic respectively.

  2. The tester checks whether a VNFCI refuses inter-VNF traffic on all intra-VNF interfaces. For example, the tester can send ping to all intra-VNF interfaces through an inter-VNF interface.

  3. The tester checks whether a VNFCI refuses intra-VNF traffic on all inter-VNF interfaces. For example, the tester can send ping to all inter-VNF interfaces through an intra-VNF interface.

Expected Results

In the step 1, the inter-VNF traffic and intra-VNF traffic are separated according the document by the vendor. In the step 2 and step 3, the VNFCI refuses traffic.

Expected Format of Evidence

A PASS or FAIL.

PDFs 6d358b453ac013f829c5983abd9ced71