Mesh use-case requirements

* Verdict: All traffic from all applications is routed through the VPN connection.

* Evidence: Packet capture showing traffic from multiple applications going through the VPN interface.

#### 5.2.5.5 MI-ROUT-4 Endpoint to endpoint encryption (### 5.6.N CON)

* **\[REQ-CON-gfouo]** The VPN traffic shall be encrypted between the VPN client and the designated endpoint with no possibility to decrypt and eavesdrop on traffic on any network device in between these endpoints.

> NOTE: In consumer or enterprise VPN scenarios which offer multiple VPN servers, the RDPS usually generates the VPN credentials and populates this to the respective VPN client. This allows the RDPS to eavesdrop on the VPN connection since it administers the VPN credentials. In a mesh scenario, the credentials have to be generated and maintained by the endpoint itself to ensure no intermediate party can eavesdrop on the connection.

[//]: # (### 6.6.N CON)

* Applicability: Mesh network

* Reference: TR-ROUT

* Requirement: **REQ-CON-gfouo**

* Objective: Prevent network observers from eavesdropping on VPN traffic

* Preparation: Attach a network package capture tool

* Activities: From a fresh installation of the client, start the VPN connection using the default configuration. Capture traffic on all interfaces. 

* Verdict: Private keys of the endpoint are not found in the network dump.

* Evidence: Packet capture showing traffic from one endpoint to another.

### XXX (## 5.7 INT Integrity)

#### XXX (### 5.7.1 INT Overview)

* **\[REQ-AAC-e5qbr]** The VPN client shall require the use of pre-shared secrets, certificates, or fingerprints to authenticate the identity of any cybersecurity-relevant node involved in the VPN connection and establish an initial secure connection.

**Guidance:** Some options may be: TLS certificates already installed on the platform, configuration files containing secrets, credentials provided as part of the product, fingerprints of keys that are distributed on a website or in accompanying documentation, along with instructions to the user on how to verify.

**Guidance:** Some options may be: TLS certificates already installed on the platform, configuration files containing secrets, credentials provided as part of the product or distributed remotely via an authenticated connection, fingerprints of keys that are distributed on a website or in accompanying documentation, along with instructions to the user on how to verify.

[//]: # (### 6.5.N AAC)

* Requirement: **REQ-AAC-q4p4w**

* Objective: Protect VPN connection from unauthorized use

* Preparation: Inspect, obtain or configure the session lifetime

* Activities: Obtain a session credential. After the configured session credential validity periode, attempt to conntect to the VPN server.

* Activities: Obtain a session credential. After the configured session credential validity period, attempt to connect to the VPN server.

* Verdict: Connection is rejected => PASS, otherwise FAIL

* Evidence: Log messages showing VPN connection establishment, authentication timeout or rejection, packet capture with timestamps synchronised with log messages

* Evidence: Log messages showing VPN connection establishment, authentication timeout or rejection, packet capture with timestamps synchronized with log messages

#### 5.2.8.5 MI-AUTH-4 Cloned credentials detection (### 5.5.N AAC)

* Verdict: 

* Evidence:

#### 5.2.8.8 MI-AUTH-7 Authorization of endpoints (### 5.5.N AAC)

* **\[REQ-AAC-jl2ol]** A node shall only allow connections from authorized endpoints.

> NOTE 1: Authorized endpoints are those that are explicitly authorized by the user, RDPS or VPN manufacturer to connect to the endpoint in question.

> NOTE 2: Examples where nodes require special authorization are (non-exhaustive list): dedicated IP, dedicated gateways or VPN servers, VPN servers offering additional features, or Mesh nodes.

[//]: # (### 6.5.N AAC)

* Reference: TR-AUTH

* Requirement: **REQ-AAC-jl2ol**

* Objective: Prevent unauthorized connections

* Preparation: Set up a node which requires selective authorization.

* Activities: As an unauthorized, but authenticated node attempt to connect to the node.

* Verdict: The unauthorized node is rejected => PASS, otherwise FAIL

* Evidence: Logs, screenshots of error message.

### 5.2.9 TR-DNSL: DNS leak prevention (## 5.6 CON Confidentiality)

#### 5.2.9.1 Requirement (### 5.6.1 CON Overview)

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (i).

#### 5.2.10.2 MI-EISO: No route between different endpoints (### 5.10.N IM)

#### 5.2.10.2 MI-EISO: No route between different endpoints by default (### 5.10.N IM)

* **\[REQ-IM-2wv8t]** The VPN shall by default not establish routes between different client endpoints.

[//]: # (### 6.10.N IM)

* Applicability: Mesh use-case 

* Reference: TR-EISO

* Requirement: **REQ-IM-2wv8t**

* Objective: Prevent unauthorized network access to endpoints

The VPN client shall not route traffic through the endpoint from sources/destinations other than the endpoint without the user's explicit informed consent, and such routing shall not be necessary for the use of any unrelated function.

#### 5.2.11.3 MI-TRAF-2: Route traffic from other sources disabled by default (### 5.10.N IM)

#### 5.2.11.3 MI-TRAF-2: Route traffic from other sources/destination disabled by default (### 5.10.N IM)

* **\[REQ-IM-mho3g]** The VPN client shall disable by default the capability for routing traffic from sources/destinations other than the endpoint through an endpoint.

* Verdict: No traffic originating from the VPN for sources/destinations other than the endpoint => PASS, otherwise FAIL

* Evidence: Packet capture with annotations of origin of packet

#### 5.2.11.4 MI-TRAF-3: Notify user if routing traffic from other sources (### 5.10.N IM)

#### 5.2.11.4 MI-TRAF-3: Notify user if routing traffic from other sources/destination (### 5.10.N IM)

* **\[REQ-IM-hxmi9]** The VPN client shall alert the user if the endpoint is allowing traffic from sources/destinations other than the endpoint to be routed through the endpoint.

* Verdict: User receives some alert or notification that clearly indicates forwarding is enabled => PASS, otherwise FAIL

* Evidence: Record of UI change

#### 5.2.11.5 MI-TRAF-4: No routing traffic from other sources if not necessary for services (### 5.10.N IM)

#### 5.2.11.5 MI-TRAF-4: No routing traffic from other sources/destination if not necessary for services (### 5.10.N IM)

* **\[REQ-IM-t4uam]** The VPN client shall not require routing of traffic from sources/destinations other than the endpoint to use services that do not require such routing.

[//]: # (### 6.10.N IM)

* Reference: TR-TRAF

* Requirement: **REQ-IM-t4uam**

* Objective: Prevent unauthorized network access to endpoints

* Verdict: All such services are documented, explanation is convincing => PASS, otherwise FAIL

* Evidence: Documentation of services

#### 5.2.11.6 MI-TRAF-5: Fine-grant access control (### 5.10.N IM)

* **\[REQ-IM-o22x0]** The VPN client shall support fine grant access control configuration to configure the permissions of authorized endpoints.

[//]: # (### 6.10.N IM)

* Applicability: Mesh use-case

* Reference: TR-TRAF

* Requirement: **REQ-IM-o22x0**

* Objective: Prevent excessive network access to endpoints

* Preparation: Create three mesh endpoints (endpoints A, endpoints B and endpoints C). Start the VPN client (endpoints A). On endpoint A allows traffic routing only from endpoint B.

* Activities: On endpoint C attempt to route traffic though endpoint A. Observe client behaviour.

* Verdict: Traffic routing is rejected on endpoint C => PASS, otherwise FAIL

* Evidence: Screenshots of error messages or logs.

### 5.2.12 TR-DMIN: Data minimization (## 5.8 DM Data minimisation)

[//]: # (Move all of 5.2.12 to 5.8.N DM)

#### 5.2.19.7 MI-DOST: Automatic traffic handling during denial-of-service attack (### 5.9.N AP)

* **\[REQ-AP-56l1z]** The product shall support multiple nodes which act as possible alternative fallbacks if a node becomes unreachable, unless the product relies on a single node or dedicated IP address.

* **\[REQ-AP-56l1z]** The product shall support multiple nodes which act as possible alternative fallbacks if a node becomes unreachable.

> NOTE 1: A product may relay on a single node or dedicated IP address if the production function requires such setup. Such instances could be a dedicated IP address assigned to one VPN server, a dedicated IP address assigned to a cluster of VPN servers, or a mesh node which usually doesn't have a fallback.

[//]: # (### 6.9.N AP)

* Applicability: Not for mesh nodes

* Applicability: Unless the product relies on a single node or dedicated IP address

* Requirement: **REQ-AP-56l1z**

* Reference: TR-AVAI

* Objective: Maintain service availability during denial-of-service attacks