Understanding the Common Criteria Evaluated Configuration

Understanding Common Criteria

Common Criteria for information technology is an international agreement signed by several countries that permits the evaluation of security products against a common set of standards. In the Common Criteria Recognition Arrangement (CCRA) at http://www.commoncriteriaportal.org/ccra/, the participants agree to mutually recognize evaluations of products performed in other countries. All evaluations are performed using a common methodology for information technology security evaluation.

For more information on Common Criteria, see http://www.commoncriteriaportal.org/.

Target of Evaluation (TOE) is a device or a system subjected to evaluation based on the Collaborative Protection Profile (cPP).

Security functionality tested for Common Criteria Evaluation

Protected Communications

The TOE provides an SSH server to support protected communications for administrators to establish secure management sessions and to connect to external syslog servers.

The TOE also supports IPsec connections to provide multi-site virtual private network (VPN) gateway functionality. The TOE requires that applications exchanging information with it are successfully authenticated prior to any exchange (i.e. applications connecting over SSH and IPsec). Telnet, File Transfer Protocol (FTP), and Secure Socket Layer (SSL) are out of scope.

The TOE includes cryptographic modules that provide the underlying cryptographic services, including key management and protection of stored keys, algorithms, random bit generation and crypto-administration. The cryptographic modules provide confidentiality and integrity services for authentication and for protecting communications with adjacent systems.

Administrator Authentication

Administrative users must provide unique identification and authentication data before any administrative access to the system is granted. Authentication data entered and stored on the TOE is protected. The TOE can be configured to terminate inactive user sessions and to present an access banner with warning messages prior to authentication.

Correct Operation

The TOE provides for both cryptographic and non-cryptographic self-tests and is capable of automated recovery from failure states.

Trusted Update

The administrator can initiate update of the TOE software. The integrity of any software updates is verified prior to installation of the updated software using digital signatures.

Audit

TOE auditable events are stored in the syslog files in the VM filesystem and can be sent to an external log server (via Netconf over SSH). Auditable events include start-up and shutdown of the audit functions, authentication events, service requests, IPS events, as well as the events listed in Table 14, Table 15, and Table 16 of the ST. Audit records include the date and time, event category, event type, username, and the outcome of the event (success or failure). Local (VM) syslog storage limits are configurable and are monitored. In the event of storage limits being reached, the oldest logs are overwritten.

Management

The TOE provides a Security Administrator role that is responsible for:

• The configuration and maintenance of cryptographic elements related to the establishment of secure connections to and from the evaluated product

• The regular review of all audit data

• Initiation of trusted update function

• Administration of VPN, IPS and Firewall functionality

• All administrative tasks (e.g., creating the security policy).

The devices are managed through a Command Line Interface (CLI). The CLI is accessible through local (serial) console connection or remote administrative (SSH) session.

The Security Administrator role includes the capability to manage all NFX services. Access to manage the device’s FreeBSD host can only be gained through the JCP.

Packet Filtering/Stateful Traffic Filtering

The TOE provides stateful network traffic filtering for IP-based (IPv4 as well as IPv6) traffic, based on examination of network packets and the application of information flow rules.

This functionality is common across all three NFX devices and involves no cryptographic operations in terms of processing.

Intrusion Prevention

The TOE can be configured to analyze IP-based (IPv4 as well as IPv6) network traffic forwarded to the TOE’s interfaces and detect violations of administratively-defined IPS policies. The TOE is capable of initiating a proactive response to terminate/interrupt an active potential threat, and to initiate a response in real time that would cause interruption of the suspicious traffic flow.

The IPS functionality is common across all three NFX devices and involves no cryptographic operations in terms of processing.

User Data Protection/Information Flow Control

The TOE is designed to forward IP-based (IPv4 as well as IPv6) network packets (i.e., information flows) from source network entities to destination network entities based on available routing information using Virtual Routers. This information is either provided directly by TOE users or indirectly from other network entities (outside the TOE) configured by the TOE users. The TOE has the capability to regulate the information flow across its interfaces; traffic filters can be set in accordance with the presumed identity of the source, the identity of the destination, the transport layer protocol, the source service identifier, and the destination service identifier (TCP or UDP port number).

Product Functionality not Included in the Scope of the Common Criteria Evaluation

The following product functionalities are disabled in the Common Criteria Evaluation configuration of the TOE:

• Use of telnet, since it violates the Trusted Path requirement set.

• Use of FTP, since it violates the Trusted Path requirement set.

• Use of SSL, including management via J-Web, JUNOScript and JUNOScope, since it violates the Trusted Path requirement set.

The following product functionalities are supported by the product but not covered by the Common Criteria evaluation and are hence expected to not be used when deployed in a CC configuration:

• Use of SNMP, since it violates the Trusted Path requirement set.

• Use of the Junos or Linux root account.

• Hosting additional VMs on the TOE physical platform.

• Use of routing protocols such as OSPF, BGP and RIP.

Supported Platforms

The NFX series comprises of three devices, each of which supports the following models for the features described in this document:

• NFX150

  • NFX150-C-S1

  • NFX150-S1

  • NFX150-S1E

• NFX250

  • NFX250-S1

  • NFX250-S1E

  • NFX250-S2

• NFX350

  • NFX350-S1

  • NFX350-S2

  • NFX350-S3

Initial Configuration

1. Refer the Understanding Management Interfaces section and accordingly establish physical and network connectivity for the console port, fxp0 management interface and other gigabit ethernet (ge) interfaces as required.

2. Access the device via console and login using the default root credentials i.e. username 'root' and no password. Follow the instructions in the Establishing Root Password Access section to set a root user password.

3. Configure the fxp0 management interface and assign it an IP address as follows:

   Repeat the same for the ge interfaces.

4. Add a default route for reachability to the fxp0 interface IP subnet:

5. Follow instructions in the following chapters to set up other functions and services:

   1. Configuring Roles and Authentication Methods

   2. Configuring Administrative Credentials and Privileges

   3. Configuring SSH and Console Connection

   4. Configuring the Remote Syslog Server

   5. Configuring Audit Log Options

During the initial setup, the local console port will have to be used to enable login service to the management port.

Vulnerability Advisory

The following CVEs are applicable when the TOE is deployed with BGP, OSPF/ISIS TE, or EVPN/VXLAN features enabled:

• CVE-2025-21598: Malformed BGP packets sent to a device configured with packet receive trace options enabled crashing the RPD.

• CVE-2024-47499: BGP update with specifically malformed AS PATH attribute sent in scenario where BGP Monitoring Protocol (BMP) is configured with rib-in pre-policy monitoring causing RPD crash and restart.

• CVE-2024-47491: BGP UPDATE with malformed path attribute causing RPD crash and restart, eventually creating a sustained DoS condition.

• CVE-2024-39555: Malformed BGP update message causing the session to reset, resulting in a Denial of Service (DoS).

• CVE-2024-39549: Malformed BGP Path attribute update causing memory leak in the Routing Protocol Daemon (rpd) leading to memory exhaustion and eventually DoS.

• CVE-2024-39541: Conflicting information (IP or ISO addresses) being added to Traffic Engineering (TE) database and subsequent operation attempts to process them causing RPD crash and restart.

• CVE-2024-39517: High volume of L2 packets in an EVPN/VXLAN scenario causing the Layer 2 Address Learning Daemon (l2ald) and rpd to exhaust CPU resources, causing a DoS condition.

• CVE-2023-4481: Continuous receipt of specific crafted BGP UPDATE messages over established BGP session causing BGP session tear down with UPDATE message error, resulting in DoS condition for impacted remote devices.

The BGP, OSPF/ISIS TE, EVPN, and VXLAN vulnerable functionalities are all out of Common Criteria scope and are disabled by default on the TOE in the evaluated configuration. To fully mitigate the above CVEs, it is highly recommended to keep them disabled. However, since this is configurable, if explicitly enabled, they can also be disabled as follows:

For BGP:

For OSPF/ISIS TE:

For EVPN:

For all configured routing instances of type evpn-vpws:

For all configured BGP peer groups:

For VXLAN:

For all interfaces configured with VXLAN encapsulation:

For all bridge domains:

However, if and only if the above features are necessary from an operational perspective, the administrator must implement the following to mitigate the mentioned vulnerabilities:

1. Enable BGP session authentication and Generalized TTL Security Mechanism (GTSM) to only allow trusted peers and counter BGP session hijack or injection at the following hierarchies.

   • [protocols bgp group authentication-key]

   • [protocols bgp group ttl]

2. Enable BGP error tolerance to counter malformed BGP UPDATE messages causing session reset at the following hierarchies.

   • [protocols bgp bgp-error-tolerance]

3. Apply BGP policy to filter prefixes and attributes, countering malformed attributes received from BGP peers at the following hierarchies.

   • [policy-options policy-statement]

   • [protocols bgp group import]

4. Apply CoPP (Control Plane Policing) to counter resource exhaustion from malformed BGP or EVPN packets at the following hierarchies.

   • [system ddos-protection protocols bgp]

   • [firewall filter]

   • [firewall policer]

   • [interfaces <name> unit <unit-no> family <family> filter]

5. Disable packet tracing options for BGP at the following hierarchies:

   • [delete protocols bgp traceoptions]

6. Configure the BGP pre-policy with the ‘exclude-non-feasible’ knob at the following hierarchies:

   • [protocols bgp ... bmp route-monitoring pre-policy exclude-non-feasible]

     or

   • [routing-options bmp ... route-monitoring pre-policy exclude-non-feasible] depending on where pre-policy is configured.

7. Apply Ethernet filtering and VLAN segmentation to counter malicious L2 EVPN/BGP/OSPF/ISIS traffic at the following hierarchies.

   • [firewall family ethernet-switching filter]

   • [interfaces unit family ethernet-switching filter]

   • [routing-instances]

8. Enforce IGP authentication to prevent unauthorized devices from forming adjacencies or injecting conflicting node information, at the following hierarchies:

   • [protocols ospf area <area ID> interface <interface name> authentication]

   • [protocols isis level <ISIS level no.> authentication-type]

   • [protocols isis level <ISIS level no.> authentication-key]

9. Only configure OSPF and ISIS on interfaces connected to trusted peers, disabling them on other interfaces at the following hierarchies, if explicitly enabled:

   • [delete protocols ospf area <area ID> interface <interface name>]

   • [delete protocols isis interface <interface name>]

10. Monitor system logs and analytics for anomalous behaviour.

Contact Juniper customer support by logging into https://supportportal.juniper.net/ for further guidance on setting up the recommended mitigation.