Some IPsec VPN client products implement SPD and packet filtering rules that do not precisely match the expected behavior as presented by the tests in FCS_IPSEC_EXT.1.1. Also, the typical VPN client running on a mobile device is designed only to initiate VPN connections with configured gateways and hence really only implements the IPSEC PROTECT function.  

The FCS_IPSEC_EXT.1.1 SFR and its Assurance Activities are modified as follows:

FCS_IPSEC_EXT.1.1 The [selection: TOE, TOE platform] shall implement the IPsec architecture as specified in RFC 4301. 

Application Note: RFC 4301 calls for an IPsec implementation to protect IP traffic through the use of a Security Policy Database (SPD).  The SPD is used to define how IP packets are to be handled: PROTECT the packet (e.g., encrypt the packet), BYPASS the IPsec services (e.g., no encryption), or DISCARD the packet (e.g., drop the packet). The SPD can be implemented in various ways, including router access control lists, firewall rulesets, a "traditional" SPD, etc. Regardless of the implementation details, there is a notion of a "rule" that a packet is "matched" against and a resulting action that takes place.

While there must be a means to order the rules, a general approach to ordering is not mandated, as long as the SPD can distinguish the IP packets and apply the rules accordingly. There may be multiple SPDs (one for each network interface), but this is not required.

A VPN gateway fully implements the IPsec capability and provides an administrative interface to establish and populate an SPD. A VPN client, on the other hand, may fully implement the IPsec functionality, or it may rely on the underlying platform to implement aspects, including the SPD. A VPN client is not required to provide an administrative interface to create or maintain an SPD. As an alternative, a client may provide an application, such as a VPN gateway, a means to establish and populate the SPD.

Assurance Activity:

TSS

The evaluator shall examine the TSS and determine that it describes how the IPsec capabilities are implemented and how a packet is processed, e.g., what takes place at the platform and what takes place within the client. The TSS will detail the relationship between the client and the underlying platform, including which aspects are implemented by the client, and those that are provided by the underlying platform. The TSS describes how the client interacts with the platforms network stack (e.g., does the client insert itself within the stack via kernel mods, does the client simply invoke APIs to gain access to network services).

If the SPD is implemented by the client, then the TSS describes how the SPD is implemented and the rules for processing both inbound and outbound packets in terms of the IPsec policy.  The TSS describes the rules that are available and the resulting actions available after matching a rule.  The TSS describes how those rules and actions form the SPD in terms of the BYPASS (e.g., no encryption), DISCARD (e.g., drop the packet), and PROTECT (e.g., encrypt the packet) actions defined in RFC 4301.

As noted in section 4.4.1 of RFC 4301, the processing of entries in the SPD is non-trivial and the evaluator shall determine that the description in the TSS is sufficient to determine which rules will be applied given the rule structure implemented by the TOE.  For example, if the TOE allows specification of ranges, conditional rules, etc., the evaluator shall determine that the description of rule processing (for both inbound and outbound packets) is sufficient to determine the action that will be applied, especially in the case where two different rules may apply.  This description shall cover both the initial packets (that is, no SA is established on the interface or for that particular packet) as well as packets that are part of an established SA. If the SPD is implemented by the underlying platform, then the TSS describes how the client interacts with the platform to establish and populate the SPD, including the identification of the platform's interfaces that are used by the client.

GUIDANCE

The evaluator shall examine the operational guidance to verify it describes how the SPD is created and configured. If there is an administrative interface to the client, then the guidance describes how the administrator specifies rules for processing a packet. The description includes all three cases - a rule that ensures packets are encrypted/decrypted, dropped, and allowing a packet to flow in plaintext. The evaluator shall determine that the description in the operational guidance is consistent with the description in the TSS, and that the level of detail in the operational guidance is sufficient to allow the administrator to set up the SPD in an unambiguous fashion. This includes a discussion of how ordering of rules impacts the processing of an IP packet.

If the client is configured by an application, such as the VPN gateway, then the operational guidance describes the client interface used by the application. The description contains information as to how the SPD is established and set up in an unambiguous fashion. The description includes what is configurable via the interface, how ordering of entries may be expressed, as well as the impacts that ordering of entries may have on the packet processing.

In either case, the evaluator ensures the description provided In the TSS is consistent with the capabilities and description provided in the operational guidance.

TEST

Given the degree of coupling between a VPN client and its underlying platform, it is expected that the client will be tested on each platform claimed in the ST. In cases where the platforms are simply different versions of the same operating system (provided by the same platform vendor), an equivalency argument may be made in lieu of testing on each version. The argument would have to demonstrate that the client interacts in exactly the same way with the versions of the OS - e.g., same APIs are used with the same parameters, the network stack is modified with the exactly the same kernel modules. The evaluator uses the operational guidance to configure the TOE and underlying platform. Depending on the implementation, the evaluator may be required to use a VPN gateway or some form of application to configure the client and platform. For Test 2, the evaluator is required to choose an application that allows for the configuration of the full set of capabilities of the VPN client (in conjunction with the platform). For example, if the client provides a robust interface that allows for specification of wildcards, subnets, etc., it is unacceptable for the evaluator to choose a VPN Gateway that only allows for specifying a single fully qualified IP addresses in the rule.

The evaluator performs the following tests:

Test 1: The evaluator shall configure the SPD such that there is a rule for dropping a packet, encrypting a packet, and allowing a packet to flow in plaintext. The selectors used in the construction of the rule shall be different such that the evaluator can generate a packet and send packets to the client with the appropriate fields (fields that are used by the rule - e.g., the IP addresses, TCP/UDP ports) in the packet header. The evaluator performs both positive and negative test cases for each type of rule. The evaluator observes via the audit trail, and packet captures that the TOE exhibited the expected behavior: appropriate packets were dropped, allowed through without modification, was encrypted by the IPsec implementation.

Test 2: The evaluator shall devise several tests that cover a variety of scenarios for packet processing.  These scenarios must exercise the range of possibilities for SPD entries and processing modes as outlined in the TSS and operational guidance.  Potential areas to cover include rules with overlapping ranges and conflicting entries, inbound and outbound packets, and packets that establish SAs as well as packets that belong to established SAs.  The evaluator shall verify, via the audit trail and packet captures, for each scenario that the expected behavior is exhibited, and is consistent with both the TSS and the operational guidance.

NDcPP  has adopted alternate test activities that represent a more current accepted approach to testing this requirement. In addition, the client may rely on the underlying platform to implement aspects of the IPSec capability, including the SPD.