IPsec Basics | Junos OS (2024)

Security Associations

A security association (SA) is a unidirectionalagreement between the VPN participants regarding the methods and parametersto use in securing a communication channel. Full bidirectional communicationrequires at least two SAs, one for each direction. Through the SA,an IPsec tunnel can provide the following security functions:

• Privacy (through encryption)

• Content integrity (through data authentication)

• Sender authentication and—if using certificates—nonrepudiation(through data origin authentication)

The security functions you employ depend on yourneeds. If you need only to authenticate the IP packet source and contentintegrity, you can authenticate the packet without applying any encryption.On the other hand, if you are concerned only with preserving privacy,you can encrypt the packet without applying any authentication mechanisms.Optionally, you can both encrypt and authenticate the packet. Mostnetwork security designers choose to encrypt, authenticate, and replay-protecttheir VPN traffic.

An IPsec tunnel consists of a pair of unidirectionalSAs—one SA for each direction of the tunnel—that specifythe security parameter index (SPI), destination IP address, and securityprotocol (Authentication Header [AH] or Encapsulating Security Payload[ESP] employed. An SA groups together the following components forsecuring communications:

• Security algorithms and keys.

• Protocol mode, either transport or tunnel. Junos OS devicesalways use tunnel mode. (See Packet Processing in TunnelMode.)

• Key-management method, either manual key or AutoKey IKE.

• SA lifetime.

For inbound traffic, Junos OS looks up the SA byusing the following triplet:

• Destination IP address.

• Security protocol, either AH or ESP.

• Security parameter index (SPI) value.

For outbound VPN traffic, the policy invokes the SA associatedwith the VPN tunnel.

Manual Key

With manual keys, administrators at both ends ofa tunnel configure all the security parameters. This is a viable techniquefor small, static networks where the distribution, maintenance, andtracking of keys are not difficult. However, safely distributing manual-keyconfigurations across great distances poses security issues. Asidefrom passing the keys face-to-face, you cannot be completely surethat the keys have not been compromised while in transit. Also, wheneveryou want to change the key, you are faced with the same security issuesas when you initially distributed it.

AutoKey IKE

When you need to create and manage numerous tunnels,you need a method that does not require you to configure every elementmanually. IPsec supports the automated generation and negotiationof keys and security associations using the Internet Key Exchange(IKE) protocol. Junos OS refers to such automated tunnel negotiationas AutoKey IKE and supports AutoKey IKE with preshared keys and AutoKeyIKE with certificates.

• AutoKey IKE with preshared keys—UsingAutoKey IKE with preshared keys to authenticate the participants inan IKE session, each side must configure and securely exchange thepreshared key in advance. In this regard, the issue of secure keydistribution is the same as that with manual keys. However, once distributed,an autokey, unlike a manual key, can automatically change its keysat predetermined intervals using the IKE protocol. Frequently changingkeys greatly improves security, and automatically doing so greatlyreduces key-management responsibilities. However, changing keys increasestraffic overhead; therefore, changing keys too often can reduce datatransmission efficiency.

  See Also

  What is IPsec (Internet Protocol Security)? - PyNet LabsIPsec Limitations

  A preshared key is a key for both encryption anddecryption, which both participants must have before initiating communication.

• AutoKey IKE with certificates—Whenusing certificates to authenticate the participants during an AutoKeyIKE negotiation, each side generates a public-private key pair andacquires a certificate.As long as the issuing certificate authority (CA) is trusted by bothsides, the participants can retrieve the peer’s public key andverify the peer's signature. There is no need to keep track of thekeys and SAs; IKE does it automatically.

Diffie-Hellman Exchange

A Diffie-Hellman (DH) exchange allows participants to produce a shared secret value. The strength of the technique is that it allows participants to create the secret value over an unsecured medium without passing the secret value through the wire. The size of the prime modulus used in each group's calculation differs as shown in the below table. Diffie Hellman (DH) exchange operations can be performed either in software or in hardware. The following Table 1 lists different Diffie Hellman (DH) groups and specifies whether the operation performed for that group is in the hardware or in software.

Starting in Junos OS Release 19.1R1, SRX Series Firewalls (except SRX300, SRX320, SRX340, SRX345, SRX380, SRX550HM Series Firewalls) support DH groups 15, 16, and 21.

Starting in Junos OS Release 20.3R1, vSRX Virtual Firewall (vSRX 3.0) instances with junos-ike package installed support DH groups 15, 16, and 21.

We do not recommend the use of DH groups 1, 2, and 5.

Because the modulus for each DH group is a different size, the participants must agree to use the same group.

IPsec Authentication Algorithms (AH Protocol)

The Authentication Header (AH) protocol providesa means to verify the authenticity and integrity of the content andorigin of a packet. You can authenticate the packet by the checksumcalculated through a Hash Message Authentication Code (HMAC) usinga secret key and either MD5 or SHA hash functions.

• Message Digest 5 (MD5)—An algorithm that producesa 128-bit hash (also called a digital signature or message digest) from a message of arbitrarylength and a 16-byte key. The resulting hash is used, like a fingerprintof the input, to verify content and source authenticity and integrity.

• Secure Hash Algorithm (SHA)—An algorithm that producesa 160-bit hash from a message of arbitrary length and a 20-byte key.It is generally regarded as more secure than MD5 because of the largerhashes it produces. Because the computational processing is done inthe ASIC, the performance cost is negligible.

For more information on MD5 hashing algorithms,see RFC 1321 and RFC 2403. For more information on SHA hashing algorithms,see RFC 2404. For more information on HMAC, see RFC 2104.

IPsec Encryption Algorithms (ESP Protocol)

The Encapsulating Security Payload (ESP) protocolprovides a means to ensure privacy (encryption) and source authenticationand content integrity (authentication). ESP in tunnel mode encapsulatesthe entire IP packet (header and payload) and then appends a new IPheader to the now-encrypted packet. This new IP header contains thedestination address needed to route the protected data through thenetwork. (See Packet Processing in TunnelMode.)

With ESP, you can both encrypt and authenticate,encrypt only, or authenticate only. For encryption, you can chooseone of the following encryption algorithms:

• Data Encryption Standard (DES)—A cryptographic block algorithm with a 56-bit key.

• Triple DES (3DES)—A more powerful version of DES in which the original DES algorithm is applied in three rounds, using a 168-bit key. DES provides significant performance savings but is considered unacceptable for many classified or sensitive material transfers.

• Advanced Encryption Standard (AES)—An encryption standard which offers greater interoperability with other devices. Junos OS supports AES with 128-bit, 192-bit, and 256-bit keys.

• ChaCha20-Poly1305 Authenticated Encryption with Associated Data—ChaCha20 stream cipher which supports Authenticated Encryption with Associated Data (AEAD) using Poly1305 authenticator.

For authentication, you can use either MD5 or SHAalgorithms.

Even though it is possible to select NULL for encryption,it has been demonstrated that IPsec might be vulnerable to attackunder such circ*mstances. Therefore, we suggest that you choose anencryption algorithm for maximum security.

• Services Interfaces Overviewfor Routing Devices

• MX Series 5G Universal RoutingPlatform Interface Module Reference

• Accessing Standards Documentson the Internet