IPSec VPN Concepts in Juniper SRX Devices


Internet Protocol Security (IPsec) is a protocol that authenticates, validates, and encrypts data packets to provide secure communication between two computers over an Internet Protocol network. IPSec works at Layer 3 and supports both unicast and multicast traffic. On IPv4 networks, IPSec is usually used in VPN tunnel. Furthermore, an IPSec can also be used for end-to-end communication. We will discuss it later in this article.

Don't know what a VPN is? Please read the previous article regarding What is VPN and How do VPNs work?

A secure VPN must provide the following security features: Confidentiality, Integrity, and Source Authentication (Availability).

  • Confidentiality: ensures the data cannot be read except by the sender and receiver.
  • Integrity: ensures that the data sent is not altered while it is transmitted.
  • Source Authentication (Availability): ensures only authenticated users can access the data.

As in the picture above, when the right router and left router are connected and implement IPSec VPN to connect the two LANs. Then their communication traffic through the internet will be encrypted.

So, the security devices should have the following abilities:

  • Encrypt packets to make them unreadable while it is transmitted.
  • Decrypt the packet and verify the payload to ensure that the packets received are not altered.
  • Authenticate the source of the packets to ensure packets are sent from authenticated sources.

The following are the topics we will discuss:

Penjelesan menggunakan Bahasa Indonesia:

Confidentiality: Data Encryption

To provide confidentiality, the sender will encrypt the packet to be sent using two-way algorithm. So, the data can be decrypted by the receiver. Then how do they do encryption and decryption?

Both the sender and receiver use a key to encrypt and decrypt packets. Based on key usage, there are two methods used to encrypt and decrypt. Those are symmetric and asymmetric encryption.

1. Symmetric Key Encryption

Symmetric key encryption is the most straightforward form of encryption with the least amount of overhead. Because the key used to encrypt the data is the same key used to decrypt the data. Thus, same key must be known on both sides of a connection.

Symmetric key size range from 56 bit to 256 bits. These keys are considered to be very fast because they are not very long, and they are widely used for bulk data encryption. However, because the key must be known to both the sender and the receiver, key management is a problem when using symmetric keys.

Examples of symmetric key encryption include Rivers Chipper 4 (RC4), Advanced Encryption Standard (AES), Data Encryption Standard (DES), and Blowfish.

Juniper SRX devices support these symmetric key encryption algorithm:

Algorithm Bit Length
DES-CBC 56-bit
3DES-CBC 112-bit
AES-128-CBC 128-bit
AES-128-GCM 128-bit
AES-192-CBC 192-bit
AES-256-CBC 256-bit
AES-256-GCM 256-bit

2. Asymmetric Key Encryption

Asymmetric encryption requires a pair of mathematically related keys. Either key in the key pair can be used to encrypt, but the remaining key of the key pair must be used to decrypt. In practice, one of the kets is kept secret and known only to the owner, this key is the private key. You can only decrypt data encrypted by the public key by using the corresponding public key and vice versa. The keys are mathematically related such that it is almost impossible to derive one key out another.

Public key sizes range from 512 to 2048 bits. Because of the large size, these keys are extremely slow and generally not feasible for bulk data encryption. However, the asymmetric key algorithm widely used for user and device authentication. Examples of asymmetric encryption algorithms include Diffie Hellman (DH) and Rivest Shamir Adleman (RSA).

Junos OS supports several DH groups. DH groups are sets of very large prime numbers, which serve as the modulus in the key exchange process. Larger primes result in encryption that is harder to crack due to the increased computing time required. However, larger primes also result in slower encryption speeds. Junos SRX currently support the following DH groups:

DH Groups Key Size
Group 1 768-bit
Group 2 1024-bit
Group 5 1536-bit
Group 14 2048-bit
Group 19 256-bit elliptical curve
Group 20 384-bit elliptical curve
Group 24 2048-bit modulus and 256-bit prime order subgroup

Juniper does not recommend DH Group 1, 2, and 5.

How Are Keys Exchanged?

One option is to manually configure the keys on both sides of the connection. Manual key configuration is straightforward, but missconfigurations are common, especially when each device has different administrator. Manual configuration also usually means that keys rarely change, which is itself a potential security issue: given a large of enough time, these keys can be broken.

Automating the key exchange process is a good idea, but you must overcome the problem of sending keys across a public network. Diffie Hellman solved this problem. Diffie Hellman algorithm is a method whereby two parties can agree upon a secret key known only to them. The strength of the technique is that it enables the participants to create the secret value over an unsecured medium without exchanging the secret value itself. This method also makes it computationally infeasible to perform reverse generation of the secret if it somehow intercepted.

Integrity: Hash Function

Encrypted data doesn't mean it cannot be changed, changing the value of 1 bit only affects the results of the encrypted data decryption. Therefore, we need integrity, a method to ensure that the data has not been altered when transmitted. To provide integrity, IPSec uses a hash algorithm.

What is the difference between hash and encryption? Hash is one-way algorithm, which means data cannot be determined from the hash value.

For example:
The word "Indonesia" after being encrypted using the AES-128-ECB algorithm, will be: fNAScTYnMopb7Cs0WvMVrg==.

And "fNAScTYnMopb7Cs0WvMVrg==" when decrypted using the same algorithm as it was encrypted, the result will be: "Indonesia".

But when you hash "Indonesia" using SHA1 algorithm, the value will be: 35536a41b209715d9e3ad440431fef2672f20bbe. And there is no algorithm to find out what the value of 35536a41b209715d9e3ad440431fef2672f20bbe.

FYI, if you found a tool on the internet with a gimmick "SHA1 decryption" or another hash algorithm decryption. Maybe you will test it and see that the data can be decrypted successfully. It's not really a decryption process! But the data from their databases, which they might get from someone trying to hash a data there.

The following figure shows the hash works to ensure data integrity.

  1. The sender runs the data through the has algorithm, which creates a hash value.
  2. The sender appends the hash value to the data and sends both the data and the hash value to the receiver.
  3. The receiver separates the data and the hash value.
  4. The receiver hashes the data.
  5. The receiver the compares the calculated hash value to the received hash value. If doesn't match, it means the data has been changed when transmitted.

Junos OS supports the following hash algorithms: Message Digest 5 (MD5), Secure Hash Algorithm (SHA).

IKE Phase 1 Algorithms Bit Length
MD5 128-bit
SHA-1 160-bit
SHA-256 256-bit
SHA-384 384-bit

IKE Phase 2 Algorithms Bit Length
HMAC-MD5-96 96-bit
HMAC-SHA-1-96 96-bit
HMAC-SHA-256-128 128-bit

Hash algorithms also produces a fixed-length output (depending on algorithm). Larger output may reduce probability of a hash collision. A collision occurs when different input values produce the same output.

Best practice from Juniper is preferred to use SHA-1 than MD5 because MD5 is no longer considered secure enough for many purposes. Even if necessary, use an algorithm whose output bit size is larger. It will make it even stronger, but it will need more computer resources and/or more longer processing time.

Availability: Source Authentication

Hashing verifies that the data is unaltered. But how do you validate the source of the data?

One method is to perform source authentication by using a Hashed Message Authentication Code (HMAC). The sender appends a secret preshared key to the data, then performs the hash function. For hashes to successfully match, the receiver must append the same ket value to the data before performing the hash function. The key itself never transmit along with the data.

The following figure shows the process of authentication with HMAC.

  1. The sender appends the pre-shared key (PSK) to the data, then performs hash function.
  2. The sender appends the hash value to the data and sends both the data and the hash value to the receiver.
  3. The receiver separates the data and the hash value.
  4. The receiver appends the preshared key to the data, then hashes them.
  5. The receiver the compares the calculated hash value to the received hash value. If it matches, it means that the data sender is authenticated.

IPSec Tunnel Mode and Transport Mode

Tunnel mode is used when both parties are a VPN gateway (eg router, firewall) or one of them is a VPN gateway. Transport mode is used when both parties are host-device (i.e, PC, laptop).

The main difference, tunnel mode encapsulates the original packet then adds a new IP header whereas transport mode doesn't, transport mode only encapsulates the segment (TCP / UDP header and Data).

When both ends of the tunnel are hosts, you can use either mode. When at least one of the endpoints of a tunnel is a security gateway, such as a Junos OS router or firewall, you must use tunnel mode. Juniper Networks devices always operate in tunnel mode for IPsec tunnels.

Internet Key Exchange (IKE)

An IPsec VPN tunnel consists of tunnel setup and applied security. During tunnel setup, the peers establish security associations (SAs), which define the parameters for securing traffic between themselves. After the tunnel is established, IPsec protects the traffic sent between the two tunnel endpoints by applying the security parameters defined by the SAs during tunnel setup.

With IPSec VPNs, the IKE protocol is typically used to set up a tunnel, but it doesn’t authenticate or encrypt user data. IKE use UDP port 500. IKE is a secure key management protocol used by IPSec to exchange information in a secure and dynamic manner with little or no intervention. The IKE proposal exchange is part of the IPSec tunnel establishement process. IKE works in two phases to set up the tunnel.

The format for IKE packets is the same for Phase 1 and Phase 2.

IKE Phase 1

Phase 1 of an AutoKey Internet Key Exchange (IKE) tunnel negotiation consists of the exchange of proposals for how to authenticate and secure the channel. The participants exchange proposals for acceptable security services such as:

  • Encryption algorithm for data encryption.
  • Hash algorithm for authentication.
  • Authentication method: Preshared key or RSA/DSA certificates.
  • Diffie-Hellman (DH) group.

A successful Phase 1 negotiation concludes when both ends of the tunnel agree to accept at least one set of the Phase 1 security parameters proposed and then process them. Juniper Networks devices support up to four proposals for Phase 1 negotiations, allowing you to define how restrictive a range of security parameters for key negotiation you will accept.

Phase 1 exchanges can take place in either main mode or aggressive mode. You can choose your mode during IKE policy configuration.

  • Main mode is used when both peers use statically assigned addresses.
  • Aggressive mode is used when one peer has a dynamically assigned addresses. The peer with the dynamic address must initiate the tunnel.

IKE Phase 2

After the participants have established a secure and authenticated channel, they proceed through Phase 2, in which they negotiate security associations (SAs) to secure the data to be transmitted through the IPsec tunnel.

Similar to the process for Phase 1, the participants exchange proposals to determine which security parameters to employ in the SA. A Phase 2 proposal also includes a security protocol—either Encapsulating Security Payload (ESP) or Authentication Header (AH)—and selected encryption and authentication algorithms. The proposal can also specify a Diffie-Hellman (DH) group, if Perfect Forward Secrecy (PFS) is desired.

Regardless of the mode used in Phase 1, Phase 2 always operates in quick mode and involves the exchange of three messages.

Juniper Networks devices support up to four proposals for Phase 2 negotiations, allowing you to define how restrictive a range of tunnel parameters you will accept. Junos OS provides predefined standard, compatible, and basic Phase 2 proposal sets. You can also define custom Phase 2 proposals.

Proxy IDs

In Phase 2, the peers exchange proxy IDs. A proxy ID consists of a local and remote IP address prefix. The proxy ID for both peers must match, which means that the local IP address specified for one peer must be the same as the remote IP address specified for the other peer.

Perfect Forward Secrecy (PFS)

PFS addresses this security risk by forcing a new DH key exchange to occur for each Phase 2 tunnel. Using PFS is thus more secure, although the rekeying procedure in Phase 2 might take slightly longer with PFS enabled.

Replay Protection

Junos OS provides a replay protection feature that enables devices to check every IPsec packet to see if it has been received previously. If packets arrive outside a specified sequence range, Junos OS rejects them. Use of this feature does not require negotiation, because packets are always sent with sequence numbers. You simply have the option of checking or not checking the sequence numbers.

AH Protocol

The Authentication Header (AH) protocol provides a mechanism for authentication only. AH provides data integrity, data origin authentication, and an optional replay protection service. You can authenticate the packet by the checksum calculated through a Hash Message Authentication Code (HMAC) using a secret key and either MD5 or SHA hash functions.

ESP Protocol

The Encapsulating Security Payload (ESP) protocol data confidentiality (encryption) and authentication (data integrity, data origin authentication, and replay protection). ESP in tunnel mode encapsulates the entire IP packet (header and payload) and then appends a new IP header to the now-encrypted packet.

ESP can be used with confidentiality only, authentication only, or both confidentiality and authentication. When ESP provides authentication functions, it uses the same algorithms as AH, but the coverage is different. AH-style authentication authenticates the entire IP packet, including the outer IP header, while the ESP authentication mechanism authenticates only the IP datagram portion of the IP packet.

After IKE negotiations completed and the two IKE gateways have established Phase 1 and Phase 2 security associations (SAs), all subsequent packets are forwarded using the tunnel. If the Phase 2 SA specifies the Encapsulating Security Protocol (ESP) in tunnel mode, the packet looks like the one shown in:

Juniper Policy-Based VPNs and Route-Based VPNs

On Juniper devices, there are two ways of implementing IPSec VPN, policy-based and route-based. Policy-based VPNs are only supported on SRX5400, SRX5600, and SRX5800 devices. Platform support depends on the Junos OS release in your installation.

In policy-based VPNs, a tunnel is treated as an object that, together with source, destination, application, and action, constitutes a tunnel policy that permits VPN traffic. A tunnel policy specifically references a VPN tunnel by name.

In route-based VPNs, a policy does not specifically reference a VPN tunnel. A route determines which traffic is sent through the tunnel based on a destination IP address.

The following table shows the differences.

Policy-Based VPN Route-Based VPN
The number of policy-based VPN tunnels that you can create is limited by the number of tunnels that the device supports. The number of route-based VPN tunnels that you create is limited by the number of st0 interfaces (for point-to-point VPNs) or the number of tunnels that the device supports, whichever is lower.
With a policy-based VPN, although you can create numerous tunnel policies referencing the same VPN tunnel, each tunnel policy pair creates an individual IPsec SA with the remote peer. Each SA counts as an individual VPN tunnel. Because the route, not the policy, determines which traffic goes through the tunnel, multiple policies can be supported with a single SA or VPN.
In a policy-based VPN, the action must be permit and must include a tunnel. include a tunnel. In a route-based VPN, the regulation of traffic is not coupled to the means of its delivery.
The exchange of dynamic routing information is not supported in policy-based VPNs. Route-based VPNs support the exchange of dynamic routing information through VPN tunnels. You can enable an instance of a dynamic routing protocol, such as OSPF, on an st0 interface that is bound to a VPN tunnel.
If you need more granularity than a route can provide to specify the traffic sent to a tunnel, using a policy-based VPN with security policies is the best choice. Route-based VPNs uses routes to specify the traffic sent to a tunnel; a policy does not specifically reference a VPN tunnel.
With a policy-based VPN tunnel, you can consider a tunnel as an element in the construction of a policy. When the security device does a route lookup to find the interface through which it must send traffic to reach an address, it finds a route through a secure tunnel (st0) interface.
With a route-based VPN tunnel, you can consider a tunnel as a means for delivering traffic, and can consider the policy as a method for either permitting or denying the delivery of that traffic.

Source: Junos Tech Library: IPsec VPN Overview

Disqus Comments