Copyright Juniper, 2022 Version 1.0 Page 1 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Juniper Networks MX2010 and MX2020 3D Universal Edge
Routers with REMX2K-X8-64G and RE-MX2000-1800X4-S
Routing Engines, MPC9E with MIC-MACSEC-MRATE
Firmware: Junos OS 20.3X75
Non-Proprietary FIPS 140-2 Cryptographic Module Security
Policy
Document Version: 1.0
Date: January 03, 2022
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, California 94089
USA
408.745.2000
1.888 JUNIPER
www.juniper.net
Copyright Juniper, 2022 Version 1.0 Page 2 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Contents
1 Introduction ..........................................................................................................................................4
Hardware and Physical CryptographicBoundary ..........................................................................7
1.2 Modes of Operation....................................................................................................................10
1.2.1 FIPS ApprovedMode..................................................................................................................10
1.2.2 Non-ApprovedMode .................................................................................................................11
1.3 Zeroization ........................................................................................................................................11
2 Cryptographic Functionality ................................................................................................................13
2.1 Allowed Algorithms and Protocols....................................................................................................13
2.2 DisallowedAlgorithms and Protocols................................................................................................16
2.3 Critical Security Parameters ..............................................................................................................17
3 Roles, Authentication and Services .....................................................................................................19
3.1 Roles and Authentication of Operators to Roles................................................................................19
3.2 Authentication Methods .............................................................................................................19
3.3 Approved and Allowed Services..................................................................................................20
3.4 Non-Approved Services...............................................................................................................22
4 Self-tests..............................................................................................................................................24
5 Physical Security Policy........................................................................................................................26
6 Security Rules and Guidance...............................................................................................................27
6.1 Cryptographic-Officer Guidance .................................................................................................28
6.1.1 Installing the FIPS-Approved firmware image ...........................................................................28
6.1.2 Enabling FIPS-Approved Mode of Operation......................................................................29
6.1.3 Placing the Module in a Non-Approved Mode of Operation..............................................30
6.2 User Guidance.............................................................................................................................30
7 References and Definitions .................................................................................................................31
Copyright Juniper, 2022 Version 1.0 Page 3 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
List of Tables
Table 1 – Cryptographic Module Hardware Configurations.........................................................................5
Table 2 – Security Level of Security Requirements.......................................................................................5
Table 3 – Ports and Interfaces ......................................................................................................................9
Table 4 – Kernel Approved Cryptographic Functions .................................................................................13
Table 5 – LibMD Approved Cryptographic Functions .................................................................................13
Table 6 – OpenSSL Approved Cryptographic Functions..............................................................................13
Table 7 – QuickSec Approved Cryptographic Functions.............................................................................15
Table 8 – MACSec Approved Cryptographic Functions ..............................................................................15
Table 9 – MIC-MACSEC-MRATE (BCM82391 Chip) ....................................................................................16
Table 10 – Entropy......................................................................................................................................16
Table 11 – Protocols Allowed in FIPS Mode................................................................................................16
Table 12 – Critical Security Parameters (CSPs) ...........................................................................................17
Table 13 – Public Keys.................................................................................................................................18
Table 14 – Authenticated Services in FIPS Standard and Reduced Throughput Modes ............................20
Table 15 – Authenticated Services in FIPS Recovery Mode........................................................................20
Table 16 – Unauthenticated Services in FIPS Standard and Reduced Throughput Modes ........................21
Table 17 – CSP Access Rights within Services .............................................................................................21
Table 18 – Non-Approved Authenticated Services in FIPS Standard and Reduced Throughput Modes....22
List of Figures
Figure 1 – Physical Cryptographic Boundary (Left to Right: MX2010 and MX2020) ....................................7
Figure 2 – Routing Engine (REMX2K-X8-64G-S)............................................................................................8
Figure 3 – Routing Engine (RE-MX2000-1800X4-S).......................................................................................8
Figure 4 – MPC9E MACsec Line Card............................................................................................................8
Figure 5 – MIC-MACSEC-MRATE ...................................................................................................................9
Copyright Juniper, 2022 Version 1.0 Page 4 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
1 Introduction
This is a non-proprietary Cryptographic Module Security Policy for the Juniper Networks
MX2010 and MX2020 3D Universal Edge Routers with REMX2K-X8-64G-S and RE-MX2000-
1800X4-S Routing Engines, MPC9E with MIC-MACSEC-MRATE. The MX series provides
dedicated high-performance processing for flows and sessions and integrates advanced
security capabilities that protect the network infrastructure as well as user data.
This FIPS 140-2 validation includes the following MX series router models: the MX2010 and
MX2020. The FIPS validated version of firmware is Junos OS 20.3X75.
The cryptographic boundary for this MX Series is defined as follows for the validation:
• the outer edge of the chassis includes the Routing Engine (RE), MPC9E MACSec Line Card
with the MIC-MACSEC-MRATE, Switch Control Board (SFB), slot covers in the following
configurations:
o For MX2010 (2 available RE slots, 10 additional slots): 1 SFB, 1 RE (REMX2K-X8-64G-S
and RE-MX2000-1800X4-S) and at least 1 MIC-MACSEC-MRATE (inserted in the MPC9E
MACSec Line Card). All empty module bays must have a slot cover installed for proper
cooling air circulation.
o For MX2020 (2 available RE slots, 20 additional slots): 1 SFB, 1 RE (REMX2K-X8-
64G-S and RE-MX2000-1800X4-S) and at least 1 MIC-MACSEC-MRATE (inserted in
the MPC9E MACSec Line Card). All empty module bays must have a slot cover
installed for proper cooling air circulation.
o includes the inverse three-dimensional space where non-crypto-relevant line cards fit,
with the backplane port serving as the physical interface.
• excluding the power distribution module on the rear of the device.
The cryptographic modules provide for an encrypted connection, using SSH, between
the management station and the module. The cryptographic modules also provide for
an encrypted connection, using MACSec, between devices. All other data input or
output from the modules are considered plaintext for this FIPS 140-2 validation.
The cryptographic modules are defined as multiple-chip standalone modules that
execute Junos OS 20.3X75 firmware on any of the Juniper Networks MX 3D Universal
Edge Routers listed in Table 1 below.
Copyright Juniper, 2022 Version 1.0 Page 5 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Table 1 – Cryptographic Module Hardware Configurations
Chassis PN Power PN SCB PN RE PN MACSec Card PN
MX2010
MX2000-PSM-AC
MX2000-PSM-DC
MX2000-SFB3-S
REMX2K-X8-64G-S
and
RE-MX2000-
1800X4-S
MIC-MACSEC-
MRATE inserted
into MPC9E
MX2020
MX2000-PSM-AC
MX2000-PSM-DC
MX2000-SFB-S
REMX2K-X8-64G-S
and
RE-MX2000-
1800X4-S
MIC-MACSEC-
MRATE inserted
into MPC9E
The modules are designed to meet FIPS 140-2 Level 1 overall:
Table 2 – Security Level of Security Requirements
Area Description Level
1 Module Specification 1
2 Ports and Interfaces 1
3
Roles, Services, and
Authentication
3
4 Finite State Model 1
5 Physical Security 1
6 Operational Environment N/A
7 Key Management 1
8 EMI/EMC 1
9 Self-test 1
Copyright Juniper, 2022 Version 1.0 Page 6 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Area Description Level
10 Design Assurance 3
11 Mitigation of Other Attacks N/A
Overall 1
The modules have a limited operational environment as per the FIPS 140-2 definitions. They
include a firmware load service to support necessary updates. Any firmware versions other
than Junos OS 20.3X75, loaded into the modules are out of the scope of this validation and
require a separate FIPS 140-2 validation.
The modules do not implement any mitigations of other attacks as defined by FIPS 140-2.
Copyright Juniper, 2022 Version 1.0 Page 7 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Hardware and Physical CryptographicBoundary
The cryptographic modules’ operational environment is a limited operational environment.
The images below depict the physical boundary of the modules, including the Routing Engine, the
MPC9E MACsec Line Card with MIC-MACSEC-MRATE and SFB. The boundary excludes the non-
crypto-relevant line cards included in the figure. The modules exclude the power supplies from
the requirements of FIPS 140-2. The power supplies do not contain any security relevant
components and cannot affect the security of the module.
Figure 1 – Physical Cryptographic Boundary (Left to Right: MX2010 and MX2020)
Copyright Juniper, 2022 Version 1.0 Page 8 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Figure 2 – Routing Engine (REMX2K-X8-64G-S)
1— Auxiliary port (AUX) 2—CONSOLE port
3— Management port (MGMT) 4— ONLINE/OFFLINE button
5—USB ports 6— RESET button
7— XGE-0 and XGE-1 ports 8— EXTCLK0 and EXTCLK1 ports
Figure 3 – Routing Engine (RE-MX2000-1800X4-S)
1— Auxiliary port (AUX) 2—CONSOLE port
3— Management port (MGMT) 4— USB port
5—RESET button 6— ONLINE/OFFLINE button
7— LINK 8— EXTCLK0 and EXTCLK1 ports
9— GPS, and BITS 10— XGE-0 and XGE-1 ports
11— ONLINE, MASTER, and OK/FAIL LEDs
Figure 4 – MPC9E MACsec Line Card
Copyright Juniper, 2022 Version 1.0 Page 9 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Figure 5 – MIC-MACSEC-MRATE
The MIC-MACSEC-MRATE has Twelve Gigabit Ethernet QSFP+ ports, each of which can be
configured as a 40-Gigabit Ethernet port or as four 10-Gigabit Ethernet ports (by using a
breakout cable).
When used in MPC9E:
• Eight ports out of the total twelve ports support 100-Gigabit Ethernet speed
• Maximum aggregate port capacity across ports 0 through 5 should not exceed 400 Gbps
• Maximum aggregate port capacity across ports 6 through 11 should not exceed 400 Gbps
Table 3 – Ports and Interfaces
Port Device (# of ports) Description Logical Interface Type
Ethernet
MX2010/MX2020:
Management port
(RE1800 (1), REMX2K-
X8-64G (1)),
MPC9E with MIC-
MACSEC-MRATE
interfaces: 40-Gigabit
Ethernet QSFP+ ports
(12)
LAN
Communications/Remote
management
Control in, Data in, Data
out, Status out
Serial
MX2010/MX2020
(RE1800 (1), REMX2K-
X8-64G (1))
Console serial port
Control in, Data in, Data out
Status out
USB
MX2010 (RE1800 (1),
REMX2K-X8-64G (2)),
MX2020 (RE1800 (1),
REMX2K-X8-64G (2))
USB port - load Junos
image
Control in, Data in
Power
MX2010 (chassis (9)),
MX2020 (chassis (18))
Power connector Power
LEDs
MX2010 (chassis (41),
MX2020 (chassis (60)),
MIC-MACSEC-
MRATE (18), RE1800
(11), REMX2K-X8-64G
(14)
Status indicator lighting Status out
Copyright Juniper, 2022 Version 1.0 Page 10 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Reset Button
MX2010/MX2020
(RE1800 (1), REMX2K-
X8-64G (1))
Reset Control in
Online/Offline
Button
MX2010/MX2020
(REMX2K-X8-64G (1),
chassis (2)
Online/Offline Control in
Chassis Cluster
Control
MX2010/MX2020
Disabled N/A
Aux
MX2010/MX2020
(RE1800 (1), REMX2K-
X8-64G (1))
Disabled N/A
Backplane
MX2010 (chassis (2)),
MX2020 (chassis (4))
Line card backplane
interface
Control in, Data in, Status
out, Data out
1.2 Modes of Operation
The module supports three FIPS Approved modes of operation and a non-Approved mode of
operation. The module must always be zeroized when switching between any FIPS Approved
mode of operation and the non-Approved mode of operation and vice versa.
1.2.1 FIPS Approved Mode
The hardware versions contained in Table 1, with Junos OS 20.3X75 installed, contain three
FIPS-Approved modes of operation and a non-Approved mode of operation. The Junos OS
20.3X75 firmware image must be installed on the device. The module is configured during
initialization to operate in an approved mode or a non-approved mode.
The Crypto-Officer places the module in an Approved mode of operation by following the
instructions in cryptographic officer guidance (section 6.1).
The Crypto-Officer can verify that the cryptographic module is in an Approved mode by
observing the console prompt and running the “show version” command. When operating
in FIPS mode, the prompt will read “<user>@<device name>:fips#” (e.g. crypto-
officer@mx2010:fips#). The “show version” command will allow the Crypto-Officer to verify
that the validated firmware version is running on the module. The Crypto-Officer can also
use the “show system fips level” command to determine if the module is operating in FIPS
mode.
The module supports three Approved modes of operation. The three modes are identified as
“FIPS Standard Mode”, “FIPS Reduced Throughput Mode” and “FIPS Recovery Mode.”
The FIPS Standard Mode is entered when the module is configured for FIPS mode and
successfully passes all the power on self-tests (POST) in both the routing engine (RE) and in
each MIC-MACSEC-MRATE installed in the chassis of the module (the maximum number of MIC-
Copyright Juniper, 2022 Version 1.0 Page 11 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
MACSEC-MRATE that can be installed in each MPC9E line card is 2 and thus in the module
chassis is 20 in case of the MX2010 and 40 in case of the MX2020 modules). The FIPS Standard
Mode supports the approved and allowed algorithms, functions and protocols identified in
Table 4 – 11. The services available in this mode are described in Tables 14 and 16.
The FIPS Reduced Throughput mode is automatically selected by the module at power-up when
all the power on self-tests (POST) in the routing engine (RE) pass successfully, at least one MIC-
MACSEC-MRATE in the module chassis passes all self-tests, and at least one MIC-MACSEC-
MRATE in the module chassis fails one or more of its self-tests. In this mode, the module offers
reduced throughput MACsec services. The FIPS Reduced Throughput Mode supports the
approved and allowed algorithms, functions and protocols identified in Table 4 – 11. The
services available in this mode are described in Tables 14 and 16.
The FIPS Recovery Mode is automatically selected when the module is configured for FIPS
mode, at power-up, when one or more of the POST fails for each MIC-MACSEC-MRATE, and all
of the RE POST pass successfully. In the FIPS Recovery Mode, the module does not allow
MACsec services and shuts down all data ports on each MIC-MACSEC-MRATE. The module
supports the OpenSSL, LibMD and Kernel algorithms in Table 4-6; the algorithms in Table 10,
and the SSH protocol in Table 11 when in the FIPS Recovery mode. The services available in the
Recovery mode are described in Table 15 and Table 17.
1.2.2 Non-Approved Mode
The cryptographic module supports a non-Approved mode of operation. When operated in the
non- Approved mode of operation, the module supports the algorithms identified in Section 2.2
as well as the algorithms supported in the Approved mode of operation.
The Crypto-Officer can place the module into a non-approved mode of operation by following
the instructions in the cryptographic officer guidance (section 6.1).
1.3 Zeroization
The cryptographic module provides a non-Approved mode of operation in which non-
Approved cryptographic algorithms are supported. When transitioning between the non-
Approved mode of operation and the FIPS-Approved mode of operation, or vice-versa, the
cryptographic officer shall zeroize all keys and CSPs.
Zeroization completely erases all configuration information on the router. The Crypto Officer
initiates the zeroization process by entering the “request vmhost zeroize no-forwarding” or
“request system zeroize” operational command from the CLI after enabling FIPS mode when
using the REMX2K-X8-64G or the RE-S-1800 routing engine respectively. Use of this command
is restricted to the Crypto Officer.
Copyright Juniper, 2022 Version 1.0 Page 12 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Use of the zeroize command is restricted to the Cryptographic Officer. The cryptographic
officer shall perform zeroization in the following situations:
1. Before FIPS Operation: To prepare the device for operation as a FIPS cryptographic
module by erasing all CSPs and other user-created data on a device before its operation
as a FIPS cryptographic module.
2. Before non-FIPS Operation: To conduct erasure of all CSPs and other user-created data
on a device in preparation for repurposing the device for non-FIPS operation.
CAUTION: Perform system zeroization with care. After the zeroization process is complete,
no data is left on the Routing Engine. The device is returned to the factory default state,
without any configured users or configuration files.
To zeroize the device:
1. From the CLI, enter
When using the REMX2K-X8-64G-S Routing Engine:
crypto-officer@device> request vmhost zeroize no-forwarding
warning: System will be rebooted and may not boot without configuration
Erase all data, including configuration and log files? [yes, no] (no)
When using the RE-MX2000-1800X4-S Routing Engine:
crypto-officer@device> request system zeroize
warning: System will be rebooted and may not boot without configuration
Erase all data, including configuration and log files? [yes, no] (no)
2. To initiate the zeroization process, type yes at the prompt:
Erase all data, including configuration and log files? [yes, no] (no)
yes
3. When the system finishes rebooting the system will be in a factory default state.
Note: The Cryptographic Officer must retain control of the module while zeroization is in process.
Copyright Juniper, 2022 Version 1.0 Page 13 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
2 Cryptographic Functionality
2.1 Allowed Algorithms and Protocols
The module implements the FIPS Approved and Non-Approved but Allowed cryptographic
functions listed in Tables 4, 5, 6, 7, 8, 9 and 10 below. Table 11 summarizes the high-level protocol
algorithm support. There are some algorithm modes that were tested but not implemented by
the module. Only the algorithms, modes, and key sizes that are implemented by the module are
shown in this/these table(s).
Table 4 – Kernel Approved Cryptographic Functions
CAVP
Cert.
Algorit
hm Standard Mode Description Functions
#A2283 DRBG SP800-90A HMAC SHA-256 Random Bit Generation
#A2283 HMAC PUB 198
SHA-1
Key size: 160 bits, λ =
96
Message
Authentication, DRBG
Primitive
SHA-256
Key size: 256 bits, λ =
128, 256
#A2283 SHS PUB 180-4
SHA-1
SHA-256
SHA-384
SHA-512
Message Digest
Generation
Table 5 – LibMD Approved Cryptographic Functions
CAVP
Cert.
Algorit
hm Standard Mode Description Functions
#A2284 HMAC
PUB 198
SHA-1
Key size: 160 bits, λ =
96 Message
Authentication
SHA-256
Key size: 256 bits,
λ = 128, 256
#A2284 SHS PUB 180-4
SHA-1
SHA-256
SHA-512
Message Digest
Generation
Table 6 – OpenSSL Approved Cryptographic Functions
CAVP
Cert.
Algorith
m
Standard Mode Description Functions
#A2286 AES1 PUB 197-
38A
CBC, CTR,
ECB
Key Sizes: 128, 192,
256
Encrypt, Decrypt
1
The AES-ECB mode was used for testing the AES-CTR mode.
Copyright Juniper, 2022 Version 1.0 Page 14 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
CAVP
Cert.
Algorith
m
Standard Mode Description Functions
N/A2 CKG
SSH-PUB
133
Section 6.1
Section 6.2
A generated seed
used in asymmetric
key generation
using an
unmodified DRBG
output
#A2286 KAS-SSC
SP 800-
56Arev3
ECC DH
P-256 (SHA 256)
P-384 (SHA 384)
P-521 (SHA 512)
Key Agreement
Scheme – Shared
Secret
Computation
#A2286 CVL SP 800-135 SSH SHA 1, 256, 384, 512 Key Derivation
N/A KAS
SP 800-
56Arev3
ECC DH and
SSH KDF
Key Agreement
Scheme – Shared
Secret
Computation per
SP 800-56Arev3
and Key Derivation
per SP 800-135.
#A2286 DRBG SP 800-90A HMAC SHA-256
Random Number
Generation
#A2286 ECDSA PUB 186-4
P-256 (SHA 256)
P-384 (SHA 384)
P-521 (SHA 512)
SigGen, KeyGen,
SigVer, PKV
#A2286 HMAC PUB 198
SHA-1
Key size: 160 bits, λ =
160
Message
Authentication
SHA-224
Key size: 224 bits, λ =
192
SHA-512
Key size: 512 bits, λ =
512
SHA-256
Key size: 256, bits, λ =
256
Message
Authentication,
DRBG Primitive
N/A KTS
AES Cert. #A2286 (CBC and CTR
modes) and HMAC Cert. #A2286
key establishment
methodology
provides between
128 and 256 bits of
encryption strength
2
Vendor Affirmed
Copyright Juniper, 2022 Version 1.0 Page 15 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
CAVP
Cert.
Algorith
m
Standard Mode Description Functions
#A2286 RSA PUB 186-4
n=2048 (SHA 256, 512)
n=3072 (SHA 256, 512)
n=4096 (SHA 256, 512)
KeyGen, SigGen,
SigVer
#A2286 SHS PUB 180-4
SHA-1
SHA-256
SHA-384
SHA-512
Message Digest
Generation,
KDF Primitive
SHA-224
Message Digest
Generation
Table 7 – QuickSec Approved Cryptographic Functions
CAVP
Cert.
Algorith
m Standard
Mode Description Functions
#A2287 HMAC PUB 198
SHA-256 Key size: 256, bits, λ =
256
#A2287 SHS SP800- 180-4 SHA-256
Message Digest
Generation,
KDF Primitive
#A2287 DRBG SP800-90A HMAC SHA-256
Random Bit
Generation
Table 8 – MACSec Approved Cryptographic Functions
CAVP
Cert.
Algorit
hm Standard
Mode Description Functions
#A2285 AES
SP 800- 197-
38A
ECB, CBC Key Sizes: 128, 256 AES CMAC
SP 800-38D CMAC Key Sizes: 128,256
Key Derivation SP
800-108: Used to
generate MACsec
keys
SP 800-35F KW Key Size: 128
Key Wrapping for
MACsec keys
#A2285 KBKDF SP 800-108 Counter
CMAC AES128
CMAC AES256
KDF for MACsec
keys
N/A KTS AES #A2285
Key Wrapping, key
establishment
methodology
Copyright Juniper, 2022 Version 1.0 Page 16 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
provides 128 bits of
encryption strength
Table 9 – MIC-MACSEC-MRATE (BCM82391 Chip)
CAVP
Cert.
Algorithm
Standard
Mode Description Functions
4545 AES
SP 800-38D GCM Key Sizes: 128,256
Key Derivation SP
800-108: Used to
generate MACsec
keys
Table 10 – Entropy
Algorithm Caveat Use
SP 800-90B ENT (NP)
The module generates a minimum of
256 bits of entropy for key
generation.
Seeding the DRBG
Table 11 – Protocols Implemented in FIPS Mode
Protocol Key Exchange Auth Cipher Integrity
MACsec
MKA
MACsec Key Agreement Shared secret
AES-GCM-128
AES-GCM-256
HMAC-SHA-
256
SSHv2
EC Diffie-Hellman P-256, P-384, P-
521
RSA 2048,
4096
ECDSA P-256
AES CBC
128/192/256
AES CTR
128/192/256
HMAC-SHA-1
HMAC-SHA-
256
HMAC-SHA-
512
No part of these protocols, other than the KDF, have been tested by the CAVP and CMVP.
The MACsec and SSH algorithms allow independent selection of key exchange,
authentication, cipher, and integrity. In Table 11 above, each column of options for a given
protocol is independent and may be used in any viable combination.
The modules can take on the role of Peer or Authenticator in reference to the MACsec
protocol. The AES GCM IV construction is performed in compliance with IEEE 802.1AE and
its amendments.
2.2 Disallowed Algorithms and Protocols
These algorithms and protocols are non-Approved algorithms and protocols that are
disabled when the module is operated in an Approved mode of operation. The algorithms
Copyright Juniper, 2022 Version 1.0 Page 17 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
are available as part of the SSH connect service when the module is operated in the non-
Approved mode.
Algorithms
• RSA with key size less than 2048
• ECDSA with ed25519 curve
• ECDH with ed25519 curve
• ARCFOUR
• Blowfish
• CAST
• DSA (SigGen, SigVer; non-compliant)
• HMAC-MD5
• HMAC-RIPEMD160
• UMAC
Protocols
• Finger
• ftp
• rlogin
• telnet
• tftp
• xnm-clear-text
2.3 Critical Security Parameters
All CSPs and public keys used by the module are described in this section. The CSPs in Table 12
are used in the FIPS Standard and FIPS Reduced Throughput Modes. The FIPS Recovery Mode
uses a subset of the CSPs found in Table 12. The MACsec CSPs are not available for use in FIPS
Recovery Mode of operation.
Table 12 – Critical Security Parameters (CSPs)
Name Description and usage
DRBG_Seed Seed material used to seed or reseed the DRBG
DRBG_State Values V and Key which comprise the HMAC_DRBG state
Entropy Input
String
256 bits entropy (min) input used to instantiate the DRBG
ECDH Shared
Secret
The Diffie-Hellman shared secret used in EC Diffie-Hellman (ECDH) exchange. Created
per the EC Diffie-Hellman protocol. Provides between 128-256 bits of security.
Copyright Juniper, 2022 Version 1.0 Page 18 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
SSH PHK
SSH Private host key. 1st time SSH is configured, the keys are generated. ECDSA P-256.
RSA 2048, 4096
Used to identify the host.
SSH ECDH Ephemeral EC Diffie-Hellman private key used in SSH. ECDH P-256, P-384, or P-521
SSH-SEKs
SSH Session Keys: SSH Session Encryption Key: AES (128,192,256); SSH Session Integrity
Key: HMAC.
MACsec CAK
User-configured PSK entered when MACsec using static connectivity association key
(CAK) security mode is enabled (32 characters).
MACsec CKN User-configured PSK used to identify the CAK (64 characters).
MACsec SAK Security Association Key used to encrypt/decrypt traffic for a given session. Derived
from CAK using KDF SP 800-108. (128-bit AES).
MACsec KEK Key Encryption Key used to transmit SAK to other members of a MACSec connectivity
association. Derived from CAK using KDF SP 800-108. (128-bit AES).
MACsec ICK Integrity Check Key used to verify the integrity and authenticity of MPDUs. Derived
from CAK using KDF SP 800-108. (128/256-bit CMAC).
HMAC Key The LibMD HMAC keys: message digest for hashing password and critical function test.
User Password Passwords used to authenticate Users to the module.
CO Password Passwords used to authenticate COs to the module.
Table 13 – Public Keys
Name D Description and usage
SSH-PUB SSH Public Host Key used to identify the host. ECDSA P-256. RSA 2048, 4096.
SSH-ECDH-
PUB
Ephemeral EC Diffie-Hellman public key used in SSH key establishment. ECDH P-256, P-
384, or
P-521
Auth-User
Pub
User Authentication Public Keys. Used to authenticate users to the module. ECDSA P-
256, P-
384, or P-521; RSA 2048, 4096
Auth-CO Pub
CO Authentication Public Keys. Used to authenticate CO to the module. ECDSA P-256, P-
384,
or P-521; RSA 2048, 4096
Root CA
ECDSA P-256 X.509 Certificate; Used to verify the validity of the Juniper
Package CA at software load and also at runtime for integrity.
Package CA
ECDSA P-256 X.509 Certificate; Used to verify the validity the Juniper Image at
software load and also at runtime for integrity.
Copyright Juniper, 2022 Version 1.0 Page 19 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
3 Roles, Authentication and Services
3.1 Roles and Authentication of Operators to Roles
The module supports two roles: Cryptographic Officer (CO) and User. The module supports
concurrent operators but does not support a maintenance role and/or bypass capability. The
module enforces the separation of roles using identity-based operator authentication.
The Cryptographic Officer role configures and monitors the module via a console or SSH
connection. As root or super-user, the Cryptographic Officer has permission to view and edit
secrets within the module.
The User role monitors the router via the console or SSH. The User role cannot
change the configuration.
3.2 Authentication Methods
The module implements two forms of Identity-Based authentication, Username and password
over the Console and SSH as well as Username and ECDSA or RSA public key over SSH.
Password authentication: The module enforces 10-character passwords (at minimum) chosen
from the 96 human readable ASCII characters. The maximum password length is 20-characters.
Thus, the probability of a successful random attempt is 1/(96^10), which is less than 1/1 million.
The module enforces a timed access mechanism as follows: For the first two failed attempts
(assuming 0 time to process), no timed access is enforced. Upon the third attempt, the module
enforces a 5-second delay. Each failed attempt thereafter results in an additional 5-second
delay above the previous (e.g. 4th failed attempt = 10-second delay, 5th failed attempt = 15-
second delay, 6th failed attempt = 20-second delay, 7th failed attempt = 25-second delay).
This leads to a maximum of 7 possible attempts in a one-minute period for each getty. The best
approach for the attacker would be to disconnect after 4 failed attempts and wait for a new
getty to be spawned. This would allow the attacker to perform roughly 9.6 attempts per minute
(576 attempts per hour/60 mins); this would be rounded down to 9 per minute, because there
is no such thing as 0.6 attempts. The probability of a success with multiple consecutive
attempts in a one-minute period is 9/(96^10), which is less than 1/100,000.
ECDSA signature verification: SSH public-key authentication. The module supports ECDSA (P-
256, P-384, and P-521), which has a minimum equivalent computational resistance to attack of
either 2128 , 2192 or 2256 depending on the curve. Thus, the probability of a successful
random attempt is 1/ (2128), which is less than 1/1,000,000. Configurable SSH connection
establishment rate limits the number of connection attempts, and thus failed authentication
attempts in a one-minute period to a maximum of 15,000 attempts. The probability of a success
with multiple consecutive attempts in a one-minute period is 15,000/(2128), which is less than
1/100,000.
RSA signature verification: SSH public-key authentication. The module supports RSA (2048,
4096), which has a minimum equivalent computational resistance to attack of 2112 (2048).
Copyright Juniper, 2022 Version 1.0 Page 20 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Thus, the probability of a successful random attempt is 1/ (2112), which is less than
1/1,000,000. Configurable SSH connection establishment rate limits the number of connection
attempts, and thus failed authentication attempts in a one-minute period to a maximum of
15,000 attempts. The probability of a success with multiple consecutive attempts in a one-
minute period is 15,000/ (2112), which is less than 1/100,000.
3.3 Approved and Allowed Services
All services implemented by the module are listed in the tables below. Table 17 lists the
access to CSPs by each service.
Table 14 – Authenticated Services in FIPS Standard and Reduced Throughput Modes
Service Description CO User
Configure security
Security relevant configuration x
Configure Non-security relevant configuration x
Secure Traffic MACsec encrypted transfer of data x
Status Show status x x
Zeroize Destroy all CSPs x
SSH connect
Initiate SSH connection for SSH monitoring and
control (CLI)
x x
MACsec connect Initiate MACsec connection x
Console access Console monitoring and control (CLI) x x
Remote reset Software initiated reset, performs self-tests on
demand.
x
Load Image Verification and loading of a validated firmware
image into the router.
x
Table 15 – Authenticated Services in FIPS Recovery Mode
Service Description CO User
Configure security
Security relevant configuration
x
Configure Non-security relevant configuration x
Status Show status x x
Zeroize Destroy all CSPs x
SSH connect
Initiate SSH connection for SSH monitoring and
control (CLI)
x x
Console access Console monitoring and control (CLI) x x
Remote reset Software initiated reset, performs self-tests on
demand.
x
Copyright Juniper, 2022 Version 1.0 Page 21 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Load Image Verification and loading of a validated firmware
image into the router.
x
Table 16 – Unauthenticated Services in FIPS Standard and Reduced Throughput Modes
Service D Description
Local reset Hardware reset or power cycle
Traffic Traffic requiring no cryptographic services (e.g., OSPF, BGP)
LED Status Basic
Table 17 – CSP Access Rights within Services
Service
CSPs
DRBG_Seed
DRBG_State
Entropy
Input
String
ECDH
Shared
Secret
SSH
PHK
SSH
ECDH
SSH-SEK
MACsec
SAK
MACsec
CAK
MACsec
CKN
MACsec
KEK
MACsec
ICK
HMAC
Key
CO-PW
User-PW
Configur
e
security
-- E --
GW
R
GW
R
-- --
GW
R
W
R
W
R
G
W
G
W
G W W
Configur
e
-- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Secure
traffic
-- -- -- -- -- -- -- E -- -- E -- -- -- --
Status -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Zeroize Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z
SSH
connect
-- E -- E E GE GE -- -- -- -- -- -- E E
MACsec
connect
-- E -- -- -- -- -- GE -- -- GE GE -- -- --
Console
access
-- -- -- -- -- -- -- -- -- -- -- -- -- E E
Remote
reset
GE
Z
GZ GZ Z -- Z Z Z -- -- -- Z -- -- --
Load
Image
-- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Local
reset
GE
Z
GZ GZ Z -- Z Z Z -- -- -- Z -- -- --
Traffic -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
G = Generate: The module generates the CSP
R = Read: The CSP is read from the module (e.g. the CSP is output)
Copyright Juniper, 2022 Version 1.0 Page 22 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
E = Execute: The module executes using the CSP
W = Write: The CSP is updated or written to the module (persistent
storage) Z = Zeroize: The module zeroizes the CSP.
3.4 Non-Approved Services
The following services are available in the non-Approved mode of operation. The security
functions provided by the non-Approved services are identical to the Approved counterparts
with the exception of SSH Connect (non-compliant). SSH Connect (non-compliant) supports the
security functions identified in Section 2.2 and the SSHv2 row of Table 11.
Table 18 – Non-Approved Authenticated Services in FIPS Standard and Reduced Throughput Modes
Service Description CO User
Configure security
(non-compliant) Security relevant configuration x
Configure (non-compliant)
(non-compliant)
Non-security relevant configuration x
Secure Traffic (non-
compliant)
MACsec encrypted transfer of data x
Status
(non-compliant)
Show status x x
Zeroize
(non-compliant)
Destroy all CSPs x
SSH connect
(non-compliant)
Initiate SSH connection for SSH monitoring and
control (CLI)
x x
MACsec connect (non-
compliant)
Initiate MACsec connection x
Console access
(non-compliant)
Console monitoring and control (CLI) x x
Remote reset
(non-compliant)
Software initiated reset, performs self-tests on
demand
x
Load Image
(non-compliant)
Verification and loading of a validated firmware
image into the router.
x
Table 19 – Non-Approved Authenticated Services in FIPS Recovery Mode
Service Description CO User
Configure security
(non-compliant) Security relevant configuration x
Configure
(non-compliant)
Non-security relevant configuration x
Status
(non-compliant)
Show status x x
Zeroize
(non-compliant)
Destroy all CSPs x
Copyright Juniper, 2022 Version 1.0 Page 23 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Service Description CO User
SSH connect
(non-compliant)
Initiate SSH connection for SSH
monitoring and
control (CLI)
x x
Console access
(non-compliant)
Console monitoring and control (CLI) x x
Remote reset
(non-compliant)
Software initiated reset, performs self-
tests on demand
x
Load Image
(non-compliant)
Verification and loading of a validated
firmware image into the router.
x
Table 20 – Non-Approved Unauthenticated Services
Service D Description
Local reset Hardware reset or power cycle
Traffic Traffic requiring no cryptographic services (e.g., OSPF, BGP)
LED Status Basic
Copyright Juniper, 2022 Version 1.0 Page 24 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
4 Self-tests
Each time the module is powered up it tests that the cryptographic algorithms still
operate correctly, and that sensitive data have not been damaged. Power-up self–
tests are available on demand by power cycling the module (Remote reset service).
On power up or reset, the module performs the self-tests described below. All KATs must be
completed successfully prior to any other use of cryptography by the module in the FIPS
Standard and Reduced Throughput Modes of operation. If any one of the Routing Engine
KATs fails, the module enters the Error state. If all the RE KATs pass and at least one MPC9E
MACSEC line cards (with the MIC-MACSEC-MRATE) in the module chassis passes all of its self-
tests, and at least one MPC9E MACSEC line cards (with the MIC-MACSEC-MRATE) in the
module chassis fails one or more of its self-tests, the module selects the FIPS Reduced
Throughput Mode of operation and the module offers reduced throughput MACsec services.
If all the RE KATs pass and each of the MPC9E line cards in the module chassis fails one or
more of its KATs, the module selects the FIPS Recovery Mode of operation and all MPC9E
algorithms are prevented from being used.
The module performs the following power-up self-tests:
Routing Engine (RE)
• Firmware Integrity check: using ECDSA P-256 with SHA-256
• Kernel KATs
o SP 800-90A HMAC DRBG KAT
▪ Health-tests initialize, re-seed, and generate
o HMAC-SHA-1 KAT
o HMAC-SHA-256 KAT
o SHA-384 KAT
o SHA-512 KAT
• OpenSSL KATs
o AES-CBC (128/192/256) Encrypt KAT
o AES-CBC (128/192/256) Decrypt KAT
o SP 800-90A HMAC DRBG KAT
▪ Health-tests initialize, re-seed, and generate
o ECDSA P-256 Sign/Verify PCT
o HMAC-SHA-1 KAT
o HMAC-SHA-224 KAT
o HMAC-SHA-256 KAT
o HMAC-SHA-512 KAT
o KAS-ECC KAT
o KDF-SSH KAT
o RSA 2048 w/ SHA-256 Sign KAT
o RSA 2048 w/ SHA-256 Verify KAT
Copyright Juniper, 2022 Version 1.0 Page 25 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
o SHA-384 KAT
• LibMD KATs
o HMAC SHA-1
o HMAC SHA-256
o SHA-512
• QuickSec KATs
o SP 800-90A HMAC DRBG KAT
▪ Health-tests initialize, re-seed, and generate
o HMAC-SHA-256 KAT
• MacSec KATs
o AES128-CMAC KAT
o AES256-CMAC KAT
o AES-ECB (128/256) Encrypt KAT
o AES-ECB (128/256) Decrypt KAT
o AES-KEYWRAP KAT
o KBKDF KAT
MPC9E with MIC-MACSEC-MRATE (BCM82391 Chip)
o AES GCM KAT
• Critical Function Test
o The cryptographic module performs a verification of a limited operational environment,
and verification of optional non-critical packages.
The module also performs the following conditional self-tests:
• Continuous Tests per SP 800-90B: Adaptive Proportion Test (APT) and Repetition Count Test (RCT).
• Pairwise consistency test when generating ECDSA, and RSA key pairs.
• Firmware Load Test (ECDSA signature verification).
Copyright Juniper, 2022 Version 1.0 Page 26 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
5 Physical Security Policy
The modules physical embodiment is that of a multi-chip standalone device that meets Level 1
Physical Security requirements. The module is completely enclosed in a rectangular nickel or
clear zinc coated, cold rolled steel, plated steel and brushed aluminium enclosure. The module
enclosure is made of production grade materials. There are no ventilation holes, gaps, slits,
cracks, slots, or crevices that would allow for any sort of observation of any component
contained within the cryptographic boundary.
Copyright Juniper, 2022 Version 1.0 Page 27 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
6 Security Rules and Guidance
The module design corresponds to the security rules below. The term shall in this context
specifically refers to a requirement for correct usage of the module in the Approved
mode; all other statements indicate a security rule implemented by the module.
1. The module clears previous authentications on power cycle.
2. When the module has not been placed in a valid role, the operator does not have access to
any cryptographic services.
3. Power up self-tests do not require any operator action.
4. Data output is inhibited during key generation, self-tests, zeroization, and error states.
5. Status information does not contain CSPs or sensitive data that if misused
could lead to a compromise of the module.
6. There are no restrictions on which keys or CSPs are zeroized by the zeroization service.
7. The module does not support a maintenance interface or role.
8. The module does not support manual key entry.
9. The module does not output intermediate key values.
10. The module requires two independent internal actions to be performed prior to
outputting plaintext CSPs.
11. The cryptographic officer shall verify that the firmware image to be loaded on the module
is a FIPS validated image. If any non-validated firmware image is loaded the module will
no longer be a FIPS validated module.
12. The cryptographic officer shall retain control of the module while zeroization is in process.
13. If the module loses power and then it is restored, then a new key shall be established for
use with the AES GCM encryption/decryption processes.
14. Virtual Chassis is not supported in FIPS mode and shall not be configured on the modules.
15. RSA key generated shall only be 2048 bits or greater.
16. The module shall only be used with CMVP FIPS 140-2 validation modules when supporting
the MACsec protocol for providing Peer, Authenticator functionality.
17. The link between the Peer and Authenticator, used in the MACsec communication, shall be
secure to prevent the possibility for an attacker to introduce foreign equipment into the
local area network.
Copyright Juniper, 2022 Version 1.0 Page 28 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
6.1 Cryptographic-Officer Guidance
The cryptographic officer must check to verify the firmware image on the router is the FIPS
140-2 validated image. If the image is the FIPS 140-2 validated image, then proceed to section
6.1.2.
6.1.1 Installing the FIPS-Approved firmware image
Download the validated firmware image from the
https://www.juniper.net/support/downloads/junos.html. Log in to the Juniper Networks
authentication system using the username (generally your e-mail address) and password
supplied by Juniper Networks representatives. Select the validated firmware image. Download
the firmware image to a local host or to an internal software distribution site.
Connect to the console port on the device from your management device and log in to the
Junos OS CLI. Copy the firmware package to the device to the /var/tmp/ directory. Install the
new package on the device:
When using the REMX2K-X8-64G-S Routing Engine:
user@device> request vmhost software add /var/tmp/package.tgz.
When using the RE-MX2000-1800X4-S Routing Engine:
user@device> request system software add /var/tmp/package.tgz
NOTE: If you need to terminate the installation, do not reboot your device; instead, finish the
installation and then issue the request system software delete package.tgz command, where
package.tgz is, for example, junos-vmhost-install-mx-x86-64-20.3X75.8.tgz. This is your last
chance to stop the installation.
Reboot the device to load the installation and start the new firmware image:
When using the REMX2K-X8-64G-S Routing Engine:
user@device> request vmhost reboot
When using the RE-MX2000-1800X4-S Routing Engine:
user@device> request system reboot
After the reboot has completed, log in and use the show version command to verify that the new
version of the firmware is successfully installed.
Also install the fips-mode package and jpfe-fips package needed for Routing Engine KATS and
for Line card KATS. The following are the commands used for installing these packages:
user@device >request system software add optional://fips-mode.tgz
user@device >request system software add optional://jpfe-fips.tgz
Copyright Juniper, 2022 Version 1.0 Page 29 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
6.1.2 Enabling FIPS-Approved Mode of Operation
The cryptographic officer is responsible for initializing the module in a FIPS-Approved mode of
operation. The FIPS-Approved mode of operation is not automatically enabled. The cryptographic
officer shall place the module in the FIPS-Approved mode by first zeroizing the device to delete all keys
and CSPs. The zeroizing instructions are in section 1.3 of this document. Next, the cryptographic officer
shall follow the steps found in the Junos OS FIPS Evaluated Configuration Guide for MX2010 and
MX2020 Devices, Release 20.3X75 document Chapters 3 & 7 to place the module into a FIPS-Approved
mode of operation. The steps from the aforementioned document are repeated below:
To enable FIPS mode in Junos OS on the device:
1. Zeroize the device as explained in Section 1.3.
2. Login to the device as root, set the root-authentication password and configure the crypto-
officer credentials. Login to the device using the crypto-officer credentials and enter
configuration mode:
crypto-officer@device> edit
Entering configuration mode
[edit]
crypto-officer@device#
3. Enable FIPS mode on the device by setting the FIPS level to 1, and verify the level:
[edit]
crypto-officer@device # set system fips chassis level 1
[edit]
crypto-officer@device # show system fips
chassis level 1;
4. Commit the configuration
[edit ]
crypto-officer@device# commit
configuration check succeeds
Generating RSA key /etc/ssh/fips_ssh_host_key
Generating RSA2 key /etc/ssh/fips_ssh_host_rsa_key
Generating ECDSA key /etc/ssh/fips_ssh_host_ecdsa_key
[edit]
'system'
reboot is required to transition to FIPS level 1
commit complete
5. Reboot the device:
Copyright Juniper, 2022 Version 1.0 Page 30 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
When using the REMX2K-X8-64G-S Routing Engine:
[edit]
crypto-officer@device# run request vmhost reboot
Reboot the system ? [yes,no] (no) yes
When using the RE-MX2000-1800X4-S Routing Engine:
[edit]
crypto-officer@device# run request system reboot
Reboot the system ? [yes,no] (no) yes
During the reboot, the device runs Known Answer Tests (KATS). It returns a login
prompt:
crypto-officer@device:fips>
6. After the reboot has completed, log in and use the show version command to verify the
firmware version is the validated version.
crypto-officer@device:fips> show version
6.1.3 Placing the Module in a Non-Approved Mode of Operation
As cryptographic officer, the operator needs to disable the FIPS-Approved mode of operation
on the device to return it to a non-Approved mode of operation. To disable FIPS-Approved
mode on the device, the router must be zeroized. Follow the steps found in section 1.3 to zeroize
the router.
6.2 User Guidance
The user should verify that the module is operating in the desired mode of operation (FIPS-Approved
mode or non-Approved mode) by observing the command prompt when logged into the device. If the
string “:fips” is present, then the router is operating in a FIPS-Approved mode. Otherwise, it is
operating in a non-Approved mode.
All FIPS users, including the Crypto Officer, must observe security guidelines at all times.
All FIPS users must:
• Keep all passwords confidential.
• Store devices and documentation in a secure area.
• Deploy devices in secure areas.
• Check audit files periodically.
• Conform to all other FIPS 140-2 security rules.
• Follow these guidelines:
• Users are trusted.
• Users abide by all security guidelines.
• Users do not deliberately compromise security.
• Users behave responsibly at all times.
Copyright Juniper, 2022 Version 1.0 Page 31 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
7 References and Definitions
The following standards are referred to in this Security Policy.
Table 21 – References
Abbreviation Full Specification Name
[FIPS140-2] Security Requirements for Cryptographic Modules, May 25, 2001
[SP800-
131Ar2]
Transitions: Recommendation for Transitioning the Use of Cryptographic
Algorithms and Key Lengths, January 2011
[IG] Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module
Validation
Program
Table 22 – Acronyms and Definitions
Acronym Definition
AES Advanced Encryption Standard
CAK Connectivity Association Key
CKN Connectivity Association Key Name
DH Diffie-Hellman
DSA Digital Signature Algorithm
ECDH Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
EMC Electromagnetic Compatibility
FIPS Federal Information Processing Standard
HMAC Keyed-Hash Message Authentication Code
ICV Integrity Check Value (i.e. Tag)
ICK Integrity Check Key
KEK Key Encrypting Key
MACsec Media Access Control Security
MD5 Message Digest 5
RE Routing Engine
RSA Public-key encryption technology developed by RSA Data Security, Inc.
SCB Switch Control Board
SHA Secure Hash Algorithms
SSH Secure Shell
Copyright Juniper, 2022 Version 1.0 Page 32 of 32`
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Table 23 – Datasheet
Model Title URL
MX2010/
MX2020
MX2000 UNIVERSAL ROUTING
PLATFORMS
https://www.juniper.net/content/dam/www/assets/
datasheets/us/en/routers/mx2000-universal-routing-
platforms-datasheet.pdf