Editorial pass on clause 4

# 4 Product context

<mark>Editor’s Note: RDPS are explicitly identified in the product context. RDPS interfaces and trust boundaries are described in the product architecture overview. RDPS assumptions and constraints are reflected in the operational environment description. Where relevant, dependencies on third party cloud solutions are included in the distribution of security functions.</mark>

## 4.1 Product Functions

<mark>Editor’s Note: Product functions should be clearly defined and granular enough to inform decision-making regarding capability-based applicability of related security controls. The recommended structure for doing this is a hierarchical functional decomposition, wherein each larger functional capability is broken down into its constituent parts. This enables manufacturers to easily derive whether their product supports parts of or all of a specific function.</mark>

### 4.1.1 Overview

The VPN product is a collection of software running on different devices, contextually referred to as nodes. **Each element may have a different set of functionality** and may be more or less trusted than other elements. How the functionality and trust are distributed vary according to the architecture (see clause 4.4) and use case (see clause 4.6) of the VPN. For example, a VPN intended to protect the end user devices from surveillance would prefer an architecture that did not trust any node not controlled by that user.

### 4.1.2 Potential functions of a node

#### 4.1.2.1 Authentication

* Confirms identity and credentials of user, or verifies credentials with third-party identity provider.

* Establishes a tunnel between devices.

#### 4.1.2.2 Access control

<mark>Editor’s Note: If the product category consists of multiple distinct product types, the functions of each product type should be listed separately, possibly following an overall function list up with a mapping to product types.</mark>

* Determines end user devices, VPN servers, and exit nodes to which the user may direct traffic. 

<mark>Editor’s Note: Where a product contributes to the delivery of services as part of a system, these services do not constitute functionalities of the product. Identify the product’s role in the delivery of services.</mark>

#### 4.1.2.3 Traffic encryption

<mark>Editor’s Note: Configuration functionality is equally in scope.</mark>

* Hides the contents of traffic sent through the tunnel.

The VPN product is a collection of software running on different devices, contextually referred to as nodes. Each software element may have a different set of functionality and may be more or less trusted than other elements. How the functionality and trust are distributed vary according to the architecture and use case of the VPN. For example, a VPN intended to protect the end user devices from surveillance would prefer an architecture that did not trust any node not controlled by that user.

#### 4.1.2.4 Routing

Potential functions include:

* Obfuscates the source or destination address of traffic sent through the tunnel.

* Routes restricted-use network traffic in or out of specific nodes, or a public network like the internet.

* Authenticating client connections

* Hide the contents of traffic sent through the tunnel

* Determining to which exit nodes a clients may direct traffic towards

* Establishing a tunnel between devices, including end user devices, VPN servers, and exit nodes

* Obfuscating the source or destination address of traffic sent through the tunnel

* Routing restricted-use network traffic in or out of specific nodes

#### 4.1.2.5 Filtering

* Inspects packets to determine which traffic may transit through the node.

### 4.1.3 Potential roles of nodes

Roles of nodes in VPNs (a node can have some or all):

* Authorization: grant nodes access to the restricted use network

* Encryption: encrypt traffic within the confines of the restricted use network

* Encryption: encrypts traffic within the confines of the restricted use network

* Edge: uses a public network to communicate with the restricted use network

* Gateway: provides link between public network and restricted use network

* Router: forward traffic between nodes in the restricted use network

* Filter: select which traffic may transit this node in the restricted use network

* Relay: assist nodes in connecting to the restricted use network

* Router: forwards traffic between nodes in the restricted use network

* Filter: selects which traffic may transit this node in the restricted use network

* Relay: assists nodes in connecting to the restricted use network

During reasonably foreseeable use, VPN nodes may:

### 4.1.4 Capabilities of nodes

During normal operation, VPN nodes may:

* Authorize other nodes to use the restricted use network

* Request authorization to use the restricted network

### 4.2.1 Product overview

As a complete product, a Virtual Private Network includes, at minimum, VPN software capable of establishing a secure encrypted tunnel between two or more devices.

As a complete product, a Virtual Private Network includes, at minimum, software capable of establishing a secure encrypted tunnel between two or more devices.

In consumer deployments, the most common state-of-the-art implementation is a product that provides a secure tunnel to one or more servers—usually managed by the manufacturer as “exit nodes”—which then route traffic to its originally intended destination, typically on a public network like the Internet.

In consumer deployments, the most common state-of-the-art implementation is a product that provides a secure tunnel to one or more servers—usually operated by the manufacturer as “exit nodes”—which then route traffic to its originally intended destination, typically on a public network like the Internet.

In enterprise wide area deployments, a common state-of-the-art implementation is a product with digital elements that provides a secure overlay network to one or more servers that enable routing of traffic between remote restricted-use enterprise networks.

VPNs also require management capabilities such as user and group management, access control, logging, and monitoring. For large enterprise use cases, these capabilities are usually provided as part of the product's local installation, whereas in consumer and small business use cases management capabilities are usually controlled by the manufacturer as part of the remote data processing aspect of the product. Mesh VPNs may use a fully peer-to-peer approach to management or a remote data processing approach.

The product consists of any client software installed as described above as well as any functionality that processes data on manufacturer-controlled infrastructure that is required for the product to operate as expected.

Some VPN products also provide management capabilities to network administrators: user and group management, access control, logging and monitoring.

### 4.2.2 Network topology and relationship between nodes

Virtual Private Networks can differ in topologies used to transmit data and distribute configuration. Two common distinct topologies are hub-and-spoke networks and mesh networks; in practice, networks can use more complex mixed topologies that fall somewhere in between the two extremes.

![Figure 4.3.1-1: A diagram illustrating an offsite device using a VPN client to encrypt traffic and send it through a public network, to a VPN server which decrypts the traffic](media/basic-consumer-vpn.png)

In a hub-and-spoke network, multiple clients connect to a single VPN server/gateway, which provides both management and routing capabilities to the clients.

**Figure 4.3.1-1: A diagram illustrating an offsite device using a VPN client to encrypt traffic and send it through a public network, to a VPN server which decrypts the traffic**

![A diagram illustrating a hub-and-spoke network.](./media/hubspoke.drawio.png)

### 4.2.2 VPN client

Figure { seq fig }: A diagram illustrating a hub-and-spoke network

For the purpose of the current document, a VPN client is a software application responsible for connecting a single end-point (such as a computing device or home router) to servers operating as exit nodes. A VPN client typically uses authentication credentials provided by the manufacturer or administrator and input by the user to establish secure tunnel(s) to an aforementioned exit node running VPN server software.

In a mesh network, clients and gateways establish direct tunnels between each other. A management server is used to authenticate VPN clients and gateways, and to configure them.

![A diagram illustrating a mesh network.](./media/mesh.drawio.png)

Figure { seq fig }: A diagram illustrating a mesh network

### 4.2.3 VPN client

For the purpose of the current document, a VPN client is a software application responsible for connecting a single end-point (such as a computing device or home router) to VPN servers, VPN gateways, or peer nodes. A VPN client typically uses authentication credentials provided by the manufacturer or administrator and input by the user to establish secure tunnel(s).

After establishing a tunnel, the VPN client changes configuration of the host device operating system to facilitate connections to the private network—this can include changes to DNS configuration, firewall rules, routing table, etc. This configuration is tailored to the end-user, and may be based on a combination of local user or administrator preferences and policies configured by the VPN manufacturer. A VPN client could have an option to perform traffic validation prior to sending the data through the established secure tunnel [\[i.13\]](#_ref_i.13).

### 4.2.3 VPN server, VPN gateway

### 4.2.4 VPN server, VPN gateway

#### 4.2.3.1 Server & gateway responsibilities

#### 4.2.4.1 Server & gateway responsibilities

While [clause 4.1](#41-product-functions) establishes that any node within a VPN network may dynamically fulfill various operational roles, the terms “VPN server” and “VPN gateway” are used to describe nodes primarily dedicated to aggregation, routing, and access control.

A **VPN server** is responsible for maintaining secure tunnels between multiple VPN clients and the traffic destinations the clients are requesting. It typically enforces centralized authentication, authorization, and traffic filtering policies. In decentralized or mesh VPN architectures, a “server” is not necessarily a dedicated, centralized appliance; rather, it is a logical role that any authorized peer node can assume to route traffic or act as an exit node for other peers.

A **VPN gateway** specifically fulfills the gateway role, acting as the secure bridge between the restricted-use VPN network and external networks, such as a private corporate intranet or the public internet.

A **VPN gateway** specifically fulfills the gateway role, acting as the secure bridge between the restricted-use VPN network and external networks, such as a private corporate intranet or a public network like the internet.

#### 4.2.4.2 Server & gateway remote data processing

When VPNs are reliant on servers, gateways, or “exit nodes” operated by the manufacturer, those operations make up an important part of the product architecture. They typically serve the same functions as any other server or gateway, but remain entirely under the control of the manufacturer instead of being deployed on their customers’ infrastructure. Due to the fact that a VPN is unable to function without this manner of data processing, it is held to the same requirements as any other VPN server or gateway, in addition to the requirements laid out in Annex R.

#### 4.2.3.2 Server & gateway remote data processing

### 4.2.5 Management server

When VPNs are reliant on exit nodes operated by the manufacturer, those exit nodes make up an important part of the product architecture. They typically serve the same functions as any other server or gateway, but remain entirely under the control of the manufacturer instead of being deployed on their customers' infrastructure. Due to the fact that a VPN is unable to function without this manner of data processing, it is held to the same requirements as any other VPN server or gateway, in addition to the requirements laid out in Annex R.

A VPN management server provides a way for network administrators to control configuration and membership of their network and is necessary for the product to operate as expected. This can include:

* Identity and authentication: management of users and groups, authentication credentials.

* Access control: policies that permit or deny certain traffic within the network.

* Monitoring and logging: configuration logs, network logs, telemetry used for troubleshooting.

The management server typically maintains configuration of the whole network and provides configuration to individual clients as they connect (authentication, address assignment, routes, etc). In VPNs using a hub-and-spoke topology, management server is often implemented as part of the VPN server. For consumer and small-business use cases as described in 4.6, this server is considered remote data processing and fully controlled by the manufacturer. Mesh networks may use a management server operated by the manufacturer as part of their remote data processing solution, or may handle all management in a peer-to-peer fashion.

## 4.3 Operational Environment

<mark>Editor’s Note: This clause should describe the conditions under which products of a particular type in the category are used as well as detailing possible systems in which they are integrated, including network context, integration environment, and physical surroundings, including the external conditions affecting RDPS.</mark>

<mark>Editor’s Note: Human factors of the operational environment are to be discussed in other clauses.</mark>

### 4.3.1 General description

### 4.3.2 Hardware environment

[//]: # (TODO general environment description)

(previously ### 4.4.1)

### 4.3.2 Hardware environment

The physical environment a VPN product may be deployed in affects the applicable risks and enables potential risk transfers. VPN products may be deployed in various different environments such as different physical devices as well as different physical networks.

### 4.3.3 Software environment

(previously ### 4.4.2)

VPNs can be expected to operate in a network environment alongside other Important products such as Identity and Access Management Systems, Network Interfaces, Routers, Firewalls, and SIEM systems. Manufacturers are expected to harden VPN attack surfaces against potential attack vectors from compromised PwDEs, but in particular those considered Important and Critical. See [clause 4.5](#45-users) for further information about the relationship between VPNs and related software.

A VPN requires an existing physical or virtual network whose resources it can use. The underlying network provides the functions necessary to connect to at least one node of the VPN.

### 4.3.4 Connectivity aspects

<mark>Leave the choice of the most appropriate header language to the rapporteur for each vertical.</mark>

[//]: # (TODO operational environment connectivity/RDPS)

## 4.4 Distribution of Security Functions