VPN Overview

A virtual private network (VPN) provides a means for securely communicating among remote computers
across a public wide area network (WAN), such as the Internet.

A VPN connection can link two local area networks (LANs) (site-to-site VPN) or a remote dial-up user and
a LAN. The traffic that flows between these two points passes through shared resources such as routers,
switches, and other network equipment that make up the public WAN. To secure VPN communication
while passing through the WAN, the two participants create an IP Security (IPsec) tunnel.

Note: The term tunnel does not denote tunnel mode (see Packet Processing

in Tunnel Mode). Instead, it refers to the IPsec connection.

This topic covers:

 Security Associations (SAs)

 IPsec Key Management
 IPsec Security Protocols
 IPsec Tunnel Negotiation
 Related Topics

Security Associations (SAs)

A security association (SA) is a unidirectional agreement between the VPN participants regarding the
methods and parameters to use in securing a communication channel. 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 your needs. If you only need to authenticate the IP packet
source and content integrity, you can authenticate the packet without applying any encryption. On the
other hand, if you are only concerned with preserving privacy, you can encrypt the packet without
applying any authentication mechanisms. Optionally, you can both encrypt and authenticate the packet.
Most network security designers choose to encrypt, authenticate, and replay-protect their VPN traffic.

An IPsec tunnel consists of a pair of unidirectional SAs—one at each end of the tunnel—that specify the
security parameter index (SPI), destination IP address, and security protocol (Authentication Header or
Encapsulating Security Payload) employed. An SA groups together the following components for securing
communications:

 Security algorithms and keys

 Protocol mode, either transport or tunnel. JUNOS devices always use tunnel mode. (For more
information, see Packet Processing in Tunnel Mode.)
 Key-management method, either manual key or AutoKey IKE. (For more information, see IPsec
Key Management.)
 SA lifetime

For inbound traffic, JUNOS Software looks up the SA by using the following triplet:
  Destination IP address
 Security protocol, either AH or ESP (see IPsec Security Protocols)
 Security parameter index (SPI) value

For outbound VPN traffic, the policy invokes the SA associated with the VPN tunnel.

IPsec Key Management

The distribution and management of keys are critical to using VPNs successfully. JUNOS Software
supports IPsec technology for creating VPN tunnels with three kinds of key creation mechanisms:

 Manual key
 AutoKey IKE with a preshared key or a certificate
 Diffie-Hellman key

You can choose your key creation mechanism—also called authentication method—during phase 1 and
phase 2 proposal configuration. For more information, see IPsec Tunnel Negotiation.

Note: Manual key creation and AutoKey IKE with certificates are not
supported with the dynamic VPN feature at this time.

Manual Key

With manual keys, administrators at both ends of a tunnel configure all the security parameters. This is a
viable technique for small, static networks where the distribution, maintenance, and tracking of keys are
not difficult. However, safely distributing manual-key configurations across great distances poses security
issues. Aside from passing the keys face-to-face, you cannot be completely sure that the keys have not
been compromised while in transit. Also, whenever you want to change the key, you are faced with the
same security issues as 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 element manually. IPsec supports the automated generation and negotiation of keys and
security associations using the Internet Key Exchange (IKE) protocol. JUNOS Software refers to such
automated tunnel negotiation as AutoKey IKE and supports AutoKey IKE with preshared keys and
AutoKey IKE with certificates.

AutoKey IKE with Preshared Keys

Using AutoKey IKE with preshared keys to authenticate the participants in an IKE session, each side
must configure and securely exchange the preshared key in advance. In this regard, the issue of secure
key distribution is the same as that with manual keys. However, once distributed, an autokey, unlike a
manual key, can automatically change its keys at predetermined intervals using the IKE protocol.
Frequently changing keys greatly improves security, and automatically doing so greatly reduces key-
management responsibilities. However, changing keys increases traffic overhead; therefore, doing so too
often can reduce data transmission efficiency.

Note: A preshared key is a key for both encryption and decryption, which
both participants must have before initiating communication.
AutoKey IKE with Certificates

When using certificates to authenticate the participants during an AutoKey IKE negotiation, each side
generates a public-private key pair and acquires a certificate. As long as the issuing certificate authority
(CA) is trusted by both sides, the participants can retrieve the peer's public key and verify the peer's
signature. There is no need to keep track of the keys and SAs; IKE does it automatically.

Diffie-Hellman Exchange

A Diffie-Hellman (DH) exchange allows the participants to produce a shared secret value. The strength of
the technique is that it allows the participants to create the secret value over an unsecured medium
without passing the secret value through the wire. There are five Diffie-Hellman groups; JUNOS Software
supports groups 1, 2, and 5. The size of the prime modulus used in each group's calculation differs as
follows:

 DH Group 1—768-bit modulus

 DH Group 2—1024-bit modulus
 DH Group 5—1536-bit modulus

Note: The strength of DH Group 1 security has depreciated; therefore we do

not recommend its use.

The larger the modulus, the more secure the generated key is considered to be; however, the larger the
modulus, the longer the key-generation process takes. Because the modulus for each DH group is a
different size, the participants must agree to use the same group.

Note: If you configure multiple (up to four) proposals for Phase 1

negotiations, use the same Diffie-Hellman group in all proposals. The same
guideline applies to multiple proposals for Phase 2 negotiations.

IPsec Security Protocols

IPsec uses two protocols to secure communications at the IP layer:

 Authentication Header (AH)—A security protocol for authenticating the source of an IP packet
and verifying the integrity of its content
 Encapsulating Security Payload (ESP)—A security protocol for encrypting the entire IP packet
(and authenticating its content)

You can choose your security protocols—also called authentication and encryption algorithms—during
phase 1 and phase 2 proposal configuration. For more information, see IPsec Tunnel Negotiation.

Authentication Header (AH) Protocol

The Authentication Header (AH) protocol provides a means to verify the authenticity/integrity of the
content and origin of a packet. 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-1 hash functions.
  Message Digest 5 (MD5)—An algorithm that produces a 128-bit hash (also called a digital
signature or message digest) from a message of arbitrary length and a 16-byte key. The resulting
hash is used, like a fingerprint of the input, to verify content and source authenticity and integrity.
 Secure Hash Algorithm-1 (SHA-1)—An algorithm that produces a 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 larger hashes it produces. Because the computational processing is done in the ASIC, the
performance cost is negligible.

Note: For more information on MD5 hashing algorithms, see RFCs

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

Encapsulating Security Payload (ESP) Protocol

The Encapsulating Security Payload (ESP) protocol provides a means to ensure privacy (encryption) and
source authentication and content integrity (authentication). ESP in tunnel mode encapsulates the entire
IP packet (header and payload) and then appends a new IP header to the now-encrypted packet. This
new IP header contains the destination address needed to route the protected data through the network.
(For more information about tunnel mode, see Packet Processing in Tunnel Mode.)

With ESP, you can both encrypt and authenticate, encrypt only, or authenticate only. For encryption, you
can choose one 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 a significant performance savings but
is considered unacceptable for many classified or sensitive material transfers.
 Advanced Encryption Standard (AES)—An emerging encryption standard which, when
adopted by Internet infrastructures worldwide, will offer greater interoperability with other devices.
JUNOS Software supports AES with 128-bit, 192-bit, and 256-bit keys.

For authentication, you can use either MD5 or SHA-1 algorithms.

Note: Even though is possible to select NULL for encryption, it has been

demonstrated that IPsec might be vulnerable to attack under such
circumstances. Therefore, we suggest that you choose an encryption
algorithm for maximum security.

IPsec Tunnel Negotiation

To establish an AutoKey IKE IPsec tunnel, two phases of negotiation are required:

 In Phase 1, the participants establish a secure channel in which to negotiate the IPsec security
associations (SAs).
 In Phase 2, the participants negotiate the IPsec SAs for encrypting and authenticating the
ensuing exchanges of user data.

For a manual key IPsec tunnel, because all of the SA parameters have been previously defined, there is
no need to negotiate which SAs to use. In essence, the tunnel has already been established. When traffic
matches a policy using that manual key tunnel or when a route involves the tunnel, the Juniper Networks
device simply encrypts and authenticates the data, as you determined, and forwards it to the destination
gateway.

Phase 1 of IKE Tunnel Negotiation

Phase 1 of an AutoKey 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 algorithms (DES and 3DES) and authentication algorithms (MD5 and SHA-1). (For
more information, seeIPsec Security Protocols.)
 A Diffie-Hellman group. (For more information, seeDiffie-Hellman Exchange.)
 Preshared Key or RSA/DSA certificates. (For more information, see IPsec Key Management.)

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.

The predefined Phase 1 proposals that JUNOS Software provides are as follows:

 Standard—pre-g2-aes128-sha and pre-g2-3des-sha

 Compatible—pre-g2-3des-sha, pre-g2-3des-md5, pre-g2-des-sha, and pre-g2-des-md5
 Basic—pre-g1-des-sha and pre-g1-des-md5

You can also define custom Phase 1 proposals.

Note: If you are using the dynamic VPN feature, note that you must create a
custom Phase 1 proposal. Predefined Phase 1 proposals are not available at
this time.

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

Main Modes

In main mode, the initiator and recipient send three two-way exchanges (six messages total) to
accomplish the following services:

 First exchange (messages 1 and 2—Propose and accept the encryption and authentication
algorithms.
 Second exchange (messages 3 and 4—Execute a Diffie-Hellman exchange, and the initiator and
recipient each provide a pseudo-random number.
 Third exchange (messages 5 and 6)—Send and verify their identities.

The information transmitted in the third exchange of messages is protected by the encryption algorithm
established in the first two exchanges. Thus, the participants' identities are not transmitted in the clear.

Aggressive Mode
In aggressive mode, the initiator and recipient accomplish the same objectives, but in only two
exchanges, with a total of three messages:

 First message—The initiator proposes the SA, initiates a Diffie-Hellman exchange, and sends a
pseudo-random number and its IKE identity.
 Second message—The recipient accepts the SA; authenticates the initiator; and sends a pseudo-
random number, its IKE identity, and, if using certificates, the recipient's certificate.
 Third message—The initiator authenticates the recipient, confirms the exchange, and, if using
certificates, sends the initiator's certificate.

Because the participants' identities are exchanged in the clear (in the first two messages), aggressive
mode does not provide identity protection.

Note: When a dialup VPN user negotiates an AutoKey IKE tunnel with a

preshared key, aggressive mode must be used. Therefore, you must always
use aggressive mode with the dynamic VPN feature. Note also that a dialup
VPN user can use an e-mail address, a fully qualified domain name (FQDN),
or an IP address as its IKE ID. A dynamic peer can use either an e-mail
address or FQDN, but not an IP address.

Phase 2 of IKE Tunnel Negotiation

After the participants have established a secure and authenticated channel, they proceed through
Phase 2, in which they negotiate the 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 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. The predefined Phase 2 proposals that
JUNOS Software provides are as follows:

 Standard—g2-esp-3des-sha and g2-esp-aes128-sha

 Compatible—nopfs-esp-3des-sha, nopfs-esp-3des-md5, nopfs-esp-des-sha, and nopfs-esp-des-
md5
 Basic—nopfs-esp-des-sha and nopfs-esp-des-md5

You can also define custom Phase 2 proposals.

Note: If you are using the dynamic VPN feature, note that you must create a
custom Phase 2 proposal. Predefined Phase 2 proposals are not available at
this time.

Proxy IDs
In Phase 2, the peers exchange proxy IDs. A proxy ID is a three-part tuple consisting of local IP address-
remote IP address-service. The proxy ID for both peers must match, which means that the service
specified in the proxy ID for both peers must be the same, and the local IP address specified for one peer
must be the same as the remote IP address specified for the other peer.

You can specify the format of Proxy IDs during IPsec Autokey configuration.

Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) is a method for deriving Phase 2 keys independent from and unrelated to
the preceding keys. Alternatively, the Phase 1 proposal creates the key (the SKEYID_d key) from which
all Phase 2 keys are derived. The SKEYID_d key can generate Phase 2 keys with a minimum of CPU
processing. Unfortunately, if an unauthorized party gains access to the SKEYID_d key, all your encryption
keys are compromised.

PFS addresses this security risk by forcing a new Diffie-Hellman 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.

You can enable PFS during IPsec policy configuration.

Replay Protection

A replay attack occurs when somebody intercepts a series of packets and uses them later either to flood
the system, causing a denial-of-service (DoS), or to gain entry to the trusted network.