IEEE 802.11 is part of the IEEE 802 set of LAN protocols, and specifies the set of media access control (MAC) and physical layer (PHY) protocols for implementing wireless local area network (WLAN) Wi-Fi computer communication in various frequencies, including but not limited to 2.4 GHz, 5 GHz, and 60 GHz frequency bands.
The present document provides an overview of NFV acceleration techniques and suggests a common architecture and abstraction layer, which allows deployment of various accelerators within the NFVI and facilitates interoperability between VNFs and accelerators. The present document also describes a set of use cases illustrating the usage of acceleration techniques in an NFV environment.
The present document defines a framework for use within ETSI NFV ISG to coordinate and promote public demonstrations of Proofs of Concept (PoC) illustrating key aspects of NFV.
The objective for the PoCs is to build commercial awareness and confidence and encourage development of an open ecosystem by integrating components from different players.
This framework outlines:
The present document defines the protocol and data model for the following interfaces used over the Ve-Vnfm reference point, in the form of RESTful Application Programming Interfaces (APIs) specifications:
The present document defines the access tokens and related metadata for RESTful protocols and data model for ETSI NFV management and orchestration (MANO) interfaces. It defines also the process for the token verification by the API Producer.
For this aim, the present document:
Trust, as defined in ETSI GR NFV-SEC 003, is an important component of security. One weakness of software as opposed to hardware, is that software can be copied in whole or in part. Trust that is rooted in software may be less reliable than trust rooted in hardware, quickly, easily, and any number of times. For the particular case of sensitive workloads that have to be trusted, only the highest assurance in the root of trust is considered acceptable, thus for the purposes of the present document the root of trust shall be provided in hardware.
There is, however, a concomitant concern that when a device is subject to black box testing, it is impossible to determine if the responses to interrogation come from hardware or software. To counter this, a NFVI vendor shall be able to provide evidence on demand that the root of trust is a hardware element. The means by which the vendor provides such evidence is not considered in the present document but should be mutually agreed between the vendor and operator.
A vendor shall be able to provide evidence on demand to authorized parties of the security claims for the root of trust. The means by which the vendor provides such evidence is not considered in the present document, but should be mutually agreed between the vendor and operator. An examples of 3rd a party assurance programme is Common Criteria (defined in ISO/IEC 15408).
The host system, acting as a black box (closed) environment, shall provide access to authorized external entities only to those capabilities identified in the authorization agreement.
In NFV network, network services and network functions can be deployed dynamically. The present document specifies functional and security requirements for automated, dynamic security policy management and security function lifecycle management, and Security Monitoring of NFV systems.
The main objectives of the present document are to:
Ultimate goal of this work: Scope of this activity is to study and investigate NFV security monitoring and management use cases and establish security requirements. The present document investigates passive and active monitoring of subscriber and management information flows, where subscriber information includes signalling and content.
Security Management and Monitoring are key components towards successful deployment of NFV. The requirements and results from the present document will act as catalyst towards rapid deployment of NFV.
Goals of the present document: The present document will recommend potential methodologies and placement of security visibility and control elements for fulfilling the requirements identified in the present document. The present document will be useful to VNF and VNFI providers, network operators and research community.
Non-goal: The present document does not address Lawful Intercept (LI). It may be applicable to performance and reliability monitoring for NFV systems.
Intended audience: VNF and NFVI providers, Network Operators, Service Providers, NFV Software Communities, SDOs (e.g. 3GPP, ETSI SC TC Cyber), Security experts and Researchers.
The present document provides the results of a simplified threat analysis for NFV-MANO functional blocks (NFVO, VNFM, VIM) and reference points Or-Vnfm, Vi-Vnfm, Or-Vi based on the guidance given in ETSI GS NFV-SEC 006.
The present document is structured such that clause 4 identifies the scope of the analysis, in the form of a target of evaluation, whilst the results of the threat analysis in the form of identified requirements that when implemented will counter or mitigate the threats are given in clause 5 of the present document. A summary is provided in clause 6 of the impact when the requirements are implemented. Threat analysis is a continual process and should be reviewed regularly.
The present document is designed to support Retained Data functionality. For the present document, "Retained Data functionality" is defined as situations in which CSPs, or their equivalent in NFV provisioning architectures, are performing the following tasks:
The present document is not a legal document. It does not define when or whether these tasks should take place, nor does it define what counts as an appropriate request or appropriate authority. The definition of what is or is not a "Communications Service Provider" (from the point of view of Retained Data) is out of scope. It is a pre-requisite to the present document that Retained Data functionality is in line with appropriate and relevant legislation on privacy and data protection.
The term "Data" in the present document is used to describe information which is collected, stored or queried as part of Retained Data functionality.
NOTE: In some jurisdictions, Retained Data may include "customer or subscriber data" (i.e. records with information about the customer (e.g. name, address) and their subscription) and "usage data" (i.e. records describing how the service was used). This note is included for background information but is not a definition.
The present document addresses multi-layer administration use cases and technical approaches, an issue identified in the Security Problem Statement, ETSI GS NFV-SEC 001. Multi-layer administration seeks to provide methods, capabilities, procedures and assurances - of various strengths based on requirements and available technologies and techniques - that safeguard Virtual Machines or Containers running on a virtualisation host ("hosted applications") - from interference (of various types) by the host system or platform ("hosting service”).
The scope of the present document is generally the system comprising the hosting service, associated hardware (including TPM, GPU, etc.), software and configuration, and the hosted application. Some requirements and measures outside this context are also considered, but not necessarily in equal depth.
The present document is a guide to developers of NFV related documents and applications in means to address the security aspects and regulatory concerns as they impact the security of deployed networks that conform with these documents and applications. The present document contains detailed descriptions of security concerns, attacks, as well as an overview of regulatory concerns and how they can be treated in system design to give the highest level of assurance that the resultant system is secure and complies with current regulation and best practice. The present document is intended for use by developers of NFV documents and the guidance is given in a manner that assists non-experts in security and regulation to prepare such documents.
In addition to the guidance and explanatory text the present document contains, in annex A, a pro forma template for use in ETSI ISG NFV documents to capture the security concerns and mitigations that apply.
The present document provides a problem statement on implementing LI in NFV and identifies the necessary capabilities to be provided in NFV to meet the requirements outlined for telecommunications capabilities in general in ETSI TS 101 331.
The present document identifies the challenges of providing LI in an NFV. The present document is intended to give guidance to the NFV community and to the wider LI community on the provision of LI in an NFV.
