Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

IPsec Overview

Understanding Junos VPN Site Secure

Junos VPN Site Secure is a suite of IPsec features supported on multiservices line cards (MS-DPC, MS-MPC, and MS-MIC), and was referred to as IPsec services in Junos releases earlier than 13.2. In Junos OS Release 13.2 and later, the term IPsec features is used exclusively to refer to the IPsec implementation on Adaptive Services and Encryption Services PICs. This topic provides you an overview of Junos VPN Site Secure, and has the following sections:

IPsec

The IPsec architecture provides a security suite for the IP version 4 (IPv4) and IP version 6 (IPv6) network layers. The suite provides such functionality as authentication of origin, data integrity, confidentiality, replay protection, and nonrepudiation of source. In addition to IPsec, the Junos OS also supports the Internet Key Exchange (IKE), which defines mechanisms for key generation and exchange, and manages security associations (SAs).

IPsec also defines a security association and key management framework that can be used with any network-layer protocol. The SA specifies what protection policy to apply to traffic between two IP-layer entities. IPsec provides secure tunnels between two peers.

Security Associations

To use IPsec security services, you create SAs between hosts. An SA is a simplex connection that enables two hosts to communicate with each other securely by means of IPsec. There are two types of SAs:

  • Manual SAs require no negotiation; all values, including the keys, are static and specified in the configuration. Manual SAs statically define the security parameter index (SPI) values, algorithms, and keys to be used, and require matching configurations on both ends of the tunnel. Each peer must have the same configured options for communication to take place.

  • Dynamic SAs require additional configuration. With dynamic SAs, you configure IKE first and then the SA. IKE creates dynamic security associations; it negotiates SAs for IPsec. The IKE configuration defines the algorithms and keys used to establish the secure IKE connection with the peer security gateway. This connection is then used to dynamically agree upon keys and other data used by the dynamic IPsec SA. The IKE SA is negotiated first and then used to protect the negotiations that determine the dynamic IPsec SAs.

IKE

IKE is a key management protocol that creates dynamic SAs; it negotiates SAs for IPsec. An IKE configuration defines the algorithms and keys used to establish a secure connection with a peer security gateway.

IKE performs the following tasks:

  • Negotiates and manages IKE and IPsec parameters.

  • Authenticates secure key exchange.

  • Provides mutual peer authentication by means of shared secrets (not passwords) and public keys.

  • Provides identity protection (in main mode).

Two versions of the IKE protocol (IKEv1 and IKEv2) are supported now. IKE negotiates security attributes and establishes shared secrets to form the bidirectional IKE SA. In IKE, inbound and outbound IPsec SAs are established and the IKE SA secures the exchanges. Starting with Junos OS Release 11.4, both IKEv1 and IKEv2 are supported by default on all M Series, MX Series, and T Series routers. IKE also generates keying material, provides Perfect Forward Secrecy, and exchanges identities.

Starting in Junos OS Release 18.2R1, you can configure an MX Series router with MS-MPCs or MS-MICs to act only as an IKE responder. In this responder-only mode, the MX Series router does not initiate IKE negotiations, it only responds to IKE negotiations initiated by the peer gateway. This might be required when inter-operating with other vendor’s equipment, such as Cisco devices. Because the MX Series does not support the protocol and port values in the traffic selector, it cannot initiate an IPsec tunnel to another vendor’s peer gateway that expects these values. By configuring the response-only mode on the MX Series, the MX can accept the traffic selector in the IKE negotiation initiated from the peer gateway.

Starting in Junos OS Release 18.2R1, you can configure the MX Series router with MS-MPCs or MS-MICs to send only the end-entity certificate for certificate-based IKE authentication instead of the full certificate chain. This avoids IKE fragmentation.

Starting with Junos OS Release 19.1R1, distinguished name support is added to the IKE identification (IKE ID) that is used for validation of VPN peer devices during IKE negotiation. The IKE ID received by an MX Series router from a remote peer can be an IPv4 or an IPv6 address, a hostname, a fully qualified domain name (FQDN), or a distinguished name (DN). The IKE ID sent by the remote peer needs to match what is expected by the MX Series router. Otherwise, IKE ID validation fails and the VPN is not established.

Non-Support for NAT-T

Before Junos OS Release 17.4R1, Network Address Translation-Traversal (NAT-T) is not supported for the Junos VPN Site Secure suite of IPsec features on the MX Series routers, and you must disable NAT-T on the MX Series router to avoid running unsupported NAT-T (see Disabling NAT-T on MX Series Routers for Handling NAT with IPsec-Protected Packets). NAT-T is a method for getting around IP address translation issues encountered when data protected by IPsec passes through a NAT device for address translation.

Comparison of IPsec on ES PICs and Junos VPN Site Secure on Multiservices LIne Cards

Table 1 compares the top-level configuration of IPsec features on the ES PIC interfaces, and IPsec on the Adaptive Services PICs and Junos VPN Site Secure on Multiservices Line Cards .

Table 1: Statement Equivalents for ES and AS Interfaces

ES PIC Configuration

AS and MultiServices Line Cards Configuration

 
[edit security ipsec]
proposal {...}

[edit services ipsec-vpn ipsec]
proposal {...}

[edit security ipsec]
policy {...}

[edit services ipsec-vpn ipsec]
policy {...}

[edit security ipsec]
security-association sa-dynamic {...}

[edit services ipsec-vpn rule rule-name]
term term-name match-conditions {...}
then dynamic {...}]

[edit security ipsec]
security-association sa-manual {...}

[edit services ipsec-vpn rule rule-name]
term term-name match-conditions {...}
then manual {...}]

[edit security ike]
proposal {...}

[edit services ipsec-vpn ike]
proposal {...}

[edit security ike]
policy {...}

[edit services ipsec-vpn ike]
policy {...}

Not available

 
[edit services ipsec-vpn]
rule-set {...}

Not available

 
[edit services ipsec-vpn]
service-set {...}

[edit interfaces es-fpc/pic/port]
tunnel source address

[edit services ipsec-vpn service-set set-name ipsec-vpn local-gateway address]

[edit interfaces es-fpc/pic/port]
tunnel destination address

[edit services ipsec-vpn rule rule-name]
remote-gateway address
Note:

Although many of the same statements and properties are valid on both platforms (MultiServices and ES), the configurations are not interchangeable. You must commit a complete configuration for the PIC type that is installed in your router.

Authentication Algorithms

Authentication is the process of verifying the identity of the sender. Authentication algorithms use a shared key to verify the authenticity of the IPsec devices. The Junos OS uses the following authentication algorithms:

  • Message Digest 5 (MD5) uses a one-way hash function to convert a message of arbitrary length to a fixed-length message digest of 128 bits. Because of the conversion process, it is mathematically infeasible to calculate the original message by computing it backwards from the resulting message digest. Likewise, a change to a single character in the message will cause it to generate a very different message digest number.

    To verify that the message has not been tampered with, the Junos OS compares the calculated message digest against a message digest that is decrypted with a shared key. The Junos OS uses the MD5 hashed message authentication code (HMAC) variant that provides an additional level of hashing. MD5 can be used with authentication header (AH), Encapsulating Security Payload (ESP), and Internet Key Exchange (IKE).

  • Secure Hash Algorithm 1 (SHA-1) uses a stronger algorithm than MD5. SHA-1 takes a message of less than 264 bits in length and produces a 160-bit message digest. The large message digest ensures that the data has not been changed and that it originates from the correct source. The Junos OS uses the SHA-1 HMAC variant that provides an additional level of hashing. SHA-1 can be used with AH, ESP, and IKE.

  • SHA-256, SHA-384, and SHA-512 (sometimes grouped under the name SHA-2) are variants of SHA-1 and use longer message digests. The Junos OS supports the SHA-256 version of SHA-2, which can process all versions of Advanced Encryption Standard (AES), Data Encryption Standard (DES), and Triple DES (3DES) encryption.

Encryption Algorithms

Encryption encodes data into a secure format so that it cannot be deciphered by unauthorized users. Like authentication algorithms, a shared key is used with encryption algorithms to verify the authenticity of the IPsec devices. The Junos OS uses the following encryption algorithms:

  • Data Encryption Standard cipher-block chaining (DES-CBC) is a symmetric secret-key block algorithm. DES uses a key size of 64 bits, where 8 bits are used for error detection and the remaining 56 bits provide encryption. DES performs a series of simple logical operations on the shared key, including permutations and substitutions. CBC takes the first block of 64 bits of output from DES, combines this block with the second block, feeds this back into the DES algorithm, and repeats this process for all subsequent blocks.

  • Triple DES-CBC (3DES-CBC) is an encryption algorithm that is similar to DES-CBC, but provides a much stronger encryption result because it uses three keys for 168-bit (3 x 56-bit) encryption. 3DES works by using the first key to encrypt the blocks, the second key to decrypt the blocks, and the third key to re-encrypt the blocks.

  • Advanced Encryption Standard (AES) is a next-generation encryption method based on the Rijndael algorithm developed by Belgian cryptographers Dr. Joan Daemen and Dr. Vincent Rijmen. It uses a 128-bit block and three different key sizes (128, 192, and 256 bits). Depending on the key size, the algorithm performs a series of computations (10, 12, or 14 rounds) that include byte substitution, column mixing, row shifting, and key addition. The use of AES in conjunction with IPsec is defined in RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec.

  • Starting In Junos OS Release 17.3R1, Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) is supported for MS-MPCs and MS-MICs. However, in Junos FIPS mode, AES-GCM is not supported in Junos OS Release 17.3R1. Starting in Junos OS Release 17.4R1, AES-GCM is supported in Junos FIPS mode. AES-GCM is an authenticated encryption algorithm designed to provide both authentication and privacy. AES-GCM uses universal hashing over a binary Galois field to provide authenticated encryption and allows authenticated encryption at data rates of tens of Gbps.

See Also

IPsec Protocols

IPsec protocols determine the type of authentication and encryption applied to packets that are secured by the router. The Junos OS supports the following IPsec protocols:

  • AH—Defined in RFC 2402, AH provides connectionless integrity and data origin authentication for IPv4 and IPv6 packets. It also provides protection against replays. AH authenticates as much of the IP header as possible, as well as the upper-level protocol data. However, some IP header fields might change in transit. Because the value of these fields might not be predictable by the sender, they cannot be protected by AH. In an IP header, AH can be identified with a value of 51 in the Protocol field of an IPv4 packet and the Next Header field of an IPv6 packet. An example of the IPsec protection offered by AH is shown in Figure 1.

    Note:

    AH is not supported on the T Series, M120, and M320 routers.

Figure 1: AH ProtocolAH Protocol

 

  • ESP—Defined in RFC 2406, ESP can provide encryption and limited traffic flow confidentiality, or connectionless integrity, data origin authentication, and an anti-replay service. In an IP header, ESP can be identified a value of 50 in the Protocol field of an IPv4 packet and the Next Header field of an IPv6 packet. An example of the IPsec protection offered by ESP is shown in Figure 2.

Figure 2: ESP ProtocolESP Protocol

  • Bundle—When you compare AH with ESP, there are some benefits and shortcomings in both protocols. ESP provides a decent level of authentication and encryption, but does so only for part of the IP packet. Conversely, although AH does not provide encryption, it does provide authentication for the entire IP packet. Because of this, the Junos OS offers a third form of IPsec protocol called a protocol bundle. The bundle option offers a hybrid combination of AH authentication with ESP encryption.

See Also

IPsec Multipath Forwarding with UDP Encapsulation

IPsec provides secure tunnels between two peers, and IPsec encapsulated packets have IP headers that contain tunnel endpoint IPs that do not change. This results in the selection of a single forwarding path between the peers, as shown in Figure 3. When IPsec traffic is flowing between data centers with thousands of hosts, this single path selection limits the throughput.

Figure 3: IPsec with One Forwarding PathIPsec with One Forwarding Path

You can overcome this problem by enabling UDP encapsulation of the IPsec packets, which appends a UDP header after the ESP header, as shown in Figure 4. This provides Layer 3 and 4 information to the intermediate routers, and the IPsec packets are forwarded over multiple paths, as shown in Figure 5. You enable UDP encapsulation for the service set.

Figure 4: Appended UDP HeaderAppended UDP Header
Figure 5: IPsec with Multiple Forwarding PathsIPsec with Multiple Forwarding Paths

You can configure the UDP destination port or use the default value of 4565. You cannot configure 4500 as the destination port because it is a well-known port for NAT traversals.

Junos OS generates the source UDP port through a hash function that operates on the following data:

  • Source IP address

  • Destination IP address

  • Transport protocol

  • Transport source port

  • Transport destination port

  • A random number

Only the last two bytes of the resulting hash are used, so the internal IP header details are hidden.

When NAT-T is detected, only NAT-T UDP encapsulation occurs, not the UDP encapsulation for IPsec packets.

See Also

Supported IPsec and IKE Standards

On routers equipped with one or more MS-MPCs, MS-MICs, or DPCs, the Canada and U.S. version of Junos OS substantially supports the following RFCs, which define standards for IP Security (IPsec) and Internet Key Exchange (IKE).

  • RFC 2085, HMAC-MD5 IP Authentication with Replay Prevention

  • RFC 2401, Security Architecture for the Internet Protocol (obsoleted by RFC 4301)

  • RFC 2402, IP Authentication Header (obsoleted by RFC 4302)

  • RFC 2403, The Use of HMAC-MD5-96 within ESP and AH

  • RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH (obsoleted by RFC 4305)

  • RFC 2405, The ESP DES-CBC Cipher Algorithm With Explicit IV

  • RFC 2406, IP Encapsulating Security Payload (ESP) (obsoleted by RFC 4303 and RFC 4305)

  • RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP (obsoleted by RFC 4306)

  • RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP) (obsoleted by RFC 4306)

  • RFC 2409, The Internet Key Exchange (IKE) (obsoleted by RFC 4306)

  • RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec

  • RFC 2451, The ESP CBC-Mode Cipher Algorithms

  • RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP

  • RFC 3193, Securing L2TP using IPsec

  • RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

  • RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec

  • RFC 3948, UDP Encapsulation of IPsec ESP Packets

  • RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)

  • RFC 4210, Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)

  • RFC 4211, Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)

  • RFC 4301, Security Architecture for the Internet Protocol

  • RFC 4302, IP Authentication Header

  • RFC 4303, IP Encapsulating Security Payload (ESP)

  • RFC 4305, Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

  • RFC 4306, Internet Key Exchange (IKEv2) Protocol

  • RFC 4307, Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)

  • RFC 4308, Cryptographic Suites for IPsec

    Only Suite VPN-A is supported in Junos OS.

  • RFC 4754, IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)

  • RFC 4835, Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

  • RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2) (obsoleted by RFC 7296)

  • RFC 7296, Internet Key Exchange Protocol Version 2 (IKEv2)

  • RFC 7427, Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)

  • RFC 7634, ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec

  • RFC 8200, Internet Protocol, Version 6 (IPv6) Specification

Junos OS partially supports the following RFCs for IPsec and IKE:

  • RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)

  • RFC 5114, Additional Diffie-Hellman Groups for Use with IETF Standards

  • RFC 5903, Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2

The following RFCs and Internet draft do not define standards, but provide information about IPsec, IKE, and related technologies. The IETF classifies them as “Informational.”

  • RFC 2104, HMAC: Keyed-Hashing for Message Authentication

  • RFC 2412, The OAKLEY Key Determination Protocol

  • RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers

  • Internet draft draft-eastlake-sha2-02.txt, US Secure Hash Algorithms (SHA and HMAC-SHA) (expires July 2006)

See Also

IPSec Terms and Acronyms

Triple Data Encryption Standard (3DES)

An enhanced DES algorithm that provides 168-bit encryption by processing data three times with three different keys.

Adaptive Services PIC

A next-generation Physical Interface Card (PIC) that provides IPsec services and other services, such as Network Address Translation (NAT) and stateful firewall, on M Series and T Series platforms.

Advanced Encryption Standard (AES)

A next-generation encryption method that is based on the Rijndael algorithm and uses a 128-bit block, three different key sizes (128, 192, and 256 bits), and multiple rounds of processing to encrypt data.

authentication header (AH)

A component of the IPsec protocol used to verify that the contents of a packet have not changed (data integrity), and to validate the identity of the sender (data source authentication). For more information about AH, see RFC 2402.

certificate authority (CA)

A trusted third-party organization that generates, enrolls, validates, and revokes digital certificates. The CA guarantees the identity of a user and issues public and private keys for message encryption and decryption.

certificate revocation list (CRL)

A list of digital certificates that have been invalidated before their expiration date, including the reasons for their revocation and the names of the entities that have issued them. A CRL prevents usage of digital certificates and signatures that have been compromised.

cipher block chaining (CBC)

A cryptographic method that encrypts blocks of ciphertext by using the encryption result of one block to encrypt the next block. Upon decryption, the validity of each block of ciphertext depends on the validity of all the preceding ciphertext blocks. For more information on how to use CBC with DES and ESP to provide confidentiality, see RFC 2405.

Data Encryption Standard (DES)

An encryption algorithm that encrypts and decrypts packet data by processing the data with a single shared key. DES operates in increments of 64-bit blocks and provides 56-bit encryption.

digital certificate

Electronic file that uses private and public key technology to verify the identity of a certificate creator and distribute keys to peers.

ES PIC

A PIC that provides first-generation encryption services and software support for IPsec on M Series and T Series platforms.

Encapsulating Security Payload (ESP)

A component of the IPsec protocol used to encrypt data in an IPv4 or IPv6 packet, provide data integrity, and ensure data source authentication. For more information about ESP, see RFC 2406.

Hashed Message Authentication Code (HMAC)

A mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, such as MD5 or SHA-1, in combination with a secret shared key. For more information on HMAC, see RFC 2104.

Internet Key Exchange (IKE)

Establishes shared security parameters for any hosts or routers using IPsec. IKE establishes the SAs for IPsec. For more information about IKE, see RFC 2407.

Message Digest 5 (MD5)

An authentication algorithm that takes a data message of arbitrary length and produces a 128-bit message digest. For more information, see RFC 1321.

Perfect Forward Secrecy (PFS)

Provides additional security by means of a Diffie-Hellman shared secret value. With PFS, if one key is compromised, previous and subsequent keys are secure because they are not derived from previous keys.

public key infrastructure (PKI)

A trust hierarchy that enables users of a public network to securely and privately exchange data through the use of public and private cryptographic key pairs that are obtained and shared with peers through a trusted authority.

registration authority (RA)

A trusted third-party organization that acts on behalf of a CA to guarantee the identity of a user.

Routing Engine

A PCI-based architectural portion of a Junos OS-based router that handles the routing protocol process, the interface process, some of the chassis components, system management, and user access.

security association (SA)

Specifications that must be agreed upon between two network devices before IKE or IPsec are allowed to function. SAs primarily specify protocol, authentication, and encryption options.

Security Association Database (SADB)

A database where all SAs are stored, monitored, and processed by IPsec.

Secure Hash Algorithm 1 (SHA-1)

An authentication algorithm that takes a data message of less than 264 bits in length and produces a 160-bit message digest. For more information on SHA-1, see RFC 3174.

Secure Hash Algorithm 2 (SHA-2)

A successor to the SHA-1 authentication algorithm that includes a group of SHA-1 variants (SHA-224, SHA-256, SHA-384, and SHA-512). SHA-2 algorithms use larger hash sizes and are designed to work with enhanced encryption algorithms such as AES.

Security Policy Database (SPD)

A database that works with the SADB to ensure maximum packet security. For inbound packets, IPsec checks the SPD to verify if the incoming packet matches the security configured for a particular policy. For outbound packets, IPsec checks the SPD to see if the packet needs to be secured.

Security Parameter Index (SPI)

An identifier that is used to uniquely identify an SA at a network host or router.

Simple Certificate Enrollment Protocol (SCEP)

A protocol that supports CA and registration authority (RA) public key distribution, certificate enrollment, certificate revocation, certificate queries, and certificate revocation list (CRL) queries.

IPsec for ACX Series Overview

The Juniper Networks Junos operating system (Junos OS) supports IPsec. This topic includes the following sections, which provide background information about configuring IPsec on ACX Series Universal Metro Routers.

Note:

IPsec is supported only on the ACX1100 AC-powered router and ACX500 routers. Service chaining (GRE, NAT, and IPSec) on ACX1100-AC and ACX500 routers is not supported.

Note:

ACX5048 and ACX5096 routers do not support IPsec configurations.

For a list of the IPsec and IKE standards supported by Junos OS, see the Junos OS Hierarchy and RFC Reference.

IPsec

The IPsec architecture provides a security suite for the IP version 4 (IPv4) network layer. The suite provides functionality such as authentication of origin, data integrity, confidentiality, replay protection, and nonrepudiation of source. In addition to IPsec, Junos OS also supports the Internet Key Exchange (IKE), which defines mechanisms for key generation and exchange, and manages security associations.

IPsec also defines a security association and key management framework that can be used with any transport layer protocol. The security association specifies what protection policy to apply to traffic between two IP-layer entities. IPsec provides secure tunnels between two peers.

Security Associations

To use IPsec security services, you create security associations between hosts. A security association is a simplex connection that allows two hosts to communicate with each other securely by means of IPsec. There are two types of security associations:

  • Manual security associations require no negotiation; all values, including the keys, are static and specified in the configuration. Manual security associations statically define the security parameter index (SPI) values, algorithms, and keys to be used, and require matching configurations on both ends of the tunnel. Each peer must have the same configured options for communication to take place.

  • Dynamic security associations require additional configuration. With dynamic security associations, you configure IKE first and then the security association. IKE creates dynamic security associations; it negotiates security associations for IPsec. The IKE configuration defines the algorithms and keys used to establish the secure IKE connection with the peer security gateway. This connection is then used to dynamically agree upon keys and other data used by the dynamic IPsec security association. The IKE security association is negotiated first and then used to protect the negotiations that determine the dynamic IPsec security associations.

IKE

IKE is a key management protocol that creates dynamic security associations; it negotiates security associations for IPsec. An IKE configuration defines the algorithms and keys used to establish a secure connection with a peer security gateway.

IKE performs the following tasks:

  • Negotiates and manages IKE and IPsec parameters.

  • Authenticates secure key exchange.

  • Provides mutual peer authentication by means of shared secrets (not passwords) and public keys.

  • Provides identity protection (in main mode).

See Also

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
18.2R1
Starting in Junos OS Release 18.2R1, you can configure an MX Series router with MS-MPCs or MS-MICs to act only as an IKE responder.
18.2R1
Starting in Junos OS Release 18.2R1, you can configure the MX Series router with MS-MPCs or MS-MICs to send only the end-entity certificate for certificate-based IKE authentication instead of the full certificate chain.
17.4R1
Starting in Junos OS Release 17.4R1, AES-GCM is supported in Junos FIPS mode.
17.3R1
Starting In Junos OS Release 17.3R1, Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) is supported for MS-MPCs and MS-MICs.