the two endpoints of its connection remains secure.
VPN runs on the network layer of the TCP/IP layered communications stack model. Specifically, VPN uses

the IP Security Architecture (IPSec) open framework. IPSec provides base security functions for the

Internet, as well as furnishes flexible building blocks from which you can create robust, secure virtual

private networks.
VPN also supports Layer 2 Tunnel Protocol (L2TP) VPN solutions. L2TP connections, which are also called

virtual lines, provide cost-effective access for remote users by allowing a corporate network server to

manage the IP addresses assigned to its remote users. Further, L2TP connections provide secure access

to your system or network when you protect them with IPSec.
It is important that you understand the effect a VPN will have on your entire network. Correct planning

and implementation are essential to your success. Review these topics to ensure that you know how

VPNs work and how you might use them:

What's new for IBM i 7.2

Read about new or changed information for the Virtual Private Networking topic collection.

IKE Version 2
Enhancements were added to the IKE version 2 (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#16) support.
• NAT compatible IpSec negotiation support in IKEv2.
• Rekey of IKE_SA.
• Authentication with Elliptical Curve Digital Signature Algorithm (ECDSA).
• URL lookup of certificates.
• Enhanced Cryptographic Algorithms for Key Ex (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#12)change Policy and Data Policy security association

attributes.

Filter rules and VPN commands
There are new commands to load and unload filter rules and to manage VPN connections.
• LODIPFTR - load and unload filter rules.
• STRVPNCNN - start VPN connection.
• ENDVPNCNN - end VPN connection.
• CPYVPNCFGF - XML export and import VPN configurations.

How to see what's new or changed
To help you see where technical changes were made, the information center uses:
• The image to mark where new or changed information begins.
• The image to mark where new or changed information ends.

In PDF files, you might see revision bars (|) in the left margin of new and changed information.
To find other information about what's new or changed this release, see the Memo to users ().

PDF file for Virtual private network

You can view and print a PDF file of this information.

To view or download the PDF version of this document, select Virtual private network (VPN) ()

Saving PDF files
To save a PDF on your workstation for viewing or printing:

1. Right-click the PDF link in your browser.
2. Click the option that saves the PDF locally.
3. Navigate to the directory in which you would like to save the PDF.
4. Click Save.

Downloading Adobe Reader
You need Adobe Reader installed on your system to view or print these PDFs. You can download a copy
from the Adobe Web site (www.adobe.com/products/ (http://www.adobe.com/products/acrobat/readstep.html)acrobat/readstep.html)

VPN concepts

It is important that you have at least a basic knowledge of standard VPN technologies before you

implement a VPN connection.
Virtual private networking (VPN) uses several important TCP/IP protocols to protect data traffic. To better

understand how any VPN connection works, familiarize yourself with these protocols and concepts and

how VPN uses them:

IP Security protocols

IP Security (IPSec) provides a stable, long lasting base for providing network layer security.
IPSec supports all of the cryptographic algorithms in use today, and can also accommodate newer, more

powerful algorithms as they become available. IPSec protocols address these major security issues:
Data origin authentication

Verifies that each datagram was originated by the claimed sender.

Data integrity

Verifies that the contents of a datagram were not changed in transit, either deliberately or due to

random errors.

Data confidentiality

Conceals the content of a message, typically by using encryption.

Replay protection

Ensures that an attacker cannot intercept a datagram and play it back at some later time.

Automated management of cryptographic keys and security associations

Ensures that your VPN policy can be used throughout the extended network with little or no manual

configuration.

VPN uses two IPSec protocols to protect data as it flows through the VPN: Authentication Header (AH)

and Encapsulating Security Payload (ESP). The other part of IPSec enablement is the Internet Key

Exchange (IKE) protocol, or key management. While IPSec encrypts your data, IKE supports automated

2 IBM i: Virtual Private Networking

negotiation of security associations (SAs), and automated generation and refreshing of cryptographic

keys.
Note: Some VPN configurations could have a security vulnerability depending on how IPSec is configured.

The vulnerability affects configurations where IPsec is configured to employ Encapsulating Security

Payload (ESP) in tunnel mode with confidentiality (encryption), but without integrity protection

(authentication) or Authentication Header (AH). The default configuration when ESP is selected always

includes an authentication algorithm that provides integrity protection. Therefore, unless the

authentication algorithm in the ESP transform is removed, VPN configurations will be protected from this

vulnerability. The IBM Universal Connection VPN configuration is not affected by this vulnerability.
To check if your system is affected by this security vulnerability follow these steps:

1. In IBM Navigator for i, expand Network > IP Policies > Virtual Private Networking and click IP

Security Policies.

2. Right-click Data Policies and select Open.
3. Right-click on the data policy you want to check and select Properties.
4. Click on the Proposals tab.
5. Select any of the data protection proposals that are using the ESP protocol and click Edit.
6. Click on the Transforms tab.
7. Select any transforms from the list that use the ESP protocol and click Edit.
8. Verify that the Authentication algorithm has any other value then None.

The Internet Engineering Task Force (IETF) formally defines IPSec in Request for Comment (RFC) 4301,

Security Architecture for the Internet Protocol. You can view this RFC on the Internet at the following Web

site: http://www.rfc-editor.org.
The principal IPSec protocols are listed below:
Related concepts
Key management (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#14)

A dynamic VPN provides additional security for your communications by using the Internet Key Exchange

(IKE) protocol for key management. IKE allows the VPN servers on each end of the connection to

negotiate new keys at specified intervals.
Related information
http://www.rfc-editor.org (http://www.rfc-editor.org)

Authentication Header

The Authentication Header (AH) protocol provides data origin authentication, data integrity, and replay

protection. However, AH does not provide data confidentiality, which means that all of your data is sent in

the clear.
AH ensures data integrity with the checksum that a message authentication code, like MD5, generates. To

ensure data origin authentication, AH includes a secret shared key in the algorithm that it uses for

authentication. To ensure replay protection, AH uses a sequence number field within the AH header. It is

worth noting here, that these three distinct functions are often lumped together and referred to as

authentication. In the simplest terms, AH ensures that your data has not been tampered with en route to

its final destination.
Although AH authenticates as much of the IP datagram as possible, the values of certain fields in the IP

header cannot be predicted by the receiver. AH does not protect these fields, known as mutable fields.

However, AH always protects the payload of the IP packet.
The Internet Engineering Task Force (IETF) formally defines AH in Request for Comment (RFC) 4302, IP

Authentication Header. You can view this RFC on the Internet at the following Web site: http://www.rfc-

editor.org.

Virtual Private Networking 3

Ways of using AH
You can apply AH in two ways: transport mode or tunnel mode. In transport mode, the IP header of the

datagram is the outermost IP header, followed by the AH header and then the payload of the datagram.

AH authenticates the entire datagram, except the mutable fields. However, the information contained in

the datagram is transported in the clear and is, therefore, subject to eavesdropping. Transport mode

requires less processing overhead than tunnel mode, but does not provide as much security.
Tunnel mode creates a new IP header and uses it as the outermost IP header of the datagram. The AH

header follows the new IP header. The original datagram (both the IP header and the original payload)

comes last. AH authenticates the entire datagram, which means that the responding system can detect

whether the datagram changed while in transit.
When either end of a security association is a gateway, use tunnel mode. In tunnel mode the source and

destination addresses in the outermost IP header do not need to be the same as those in the original IP

header. For example, two security gateways might operate an AH tunnel to authenticate all traffic

between the networks they connect together. In fact, this is a very typical configuration.
The main advantage to using tunnel mode, is that tunnel mode totally protects the encapsulated IP

datagram. In addition, tunnel mode makes it possible to use private addresses.

Why AH?
In many cases, your data only requires authentication. While the Encapsulating Security Payload (ESP)

protocol can perform authentication, AH does not affect your system performance as does ESP. Another

advantage of using AH, is that AH authenticates the entire datagram. ESP, however, does not authenticate

the leading IP header or any other information that comes before the ESP header.
In addition, ESP requires strong cryptographic algorithms in order to be put into effect. Strong

cryptography is restricted in some regions, while AH is not regulated and can be used freely around the

world.

Using ESN with AH
If you use the AH protocol then you might want to enable Extended Sequence Number (ESN). ESN allows

you to transmit large volumes of data at a high speed with out re-keying. The VPN connection uses a 64-

bit sequence numbers instead of 32-bit numbers over IPSec. Using 64-bit sequence numbers allows

more time before re-keying, which prevents sequence number exhaustion and minimizes the use of

system resources.

What algorithms does AH use to protect my information?
AH uses algorithms known as hashed message authentication codes (HMAC). Specifically, VPN uses

HMAC-MD5, HMAC-SHA, HMAC-SHA-256,HMAC-SHA384, HMAC-SHA512, or AES-XCBC-MAC. Each of

the algorithms take variable-length input data and a secret key to produce fixed-length output data

(called a hash or MAC value). If the hashes of two messages match, then it is likely that the messages are

the same.
The Internet Engineering Task Force (IETF) formally defines the algorithms in the following Request for

Comments (RFC):
• HMAC-MD*************, HMAC-MD5 IP Authentication with Replay Prevention
• HMAC-SHA in RFC 2404, The Use of HMAC-******** within ESP and AH
• HMAC-SHA_****************, and HMAC-SHA-***************, Using HMAC-SHA-256, HMAC-

SHA-384, and HMAC-SHA-512 with IPsec

• AES-XCBC-MAC in RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
You can view these RFCs on the Internet at the following Web site: http://www.rfc-editor.org.
Related concepts
Encapsulating Security Payload (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#11)

4 IBM i: Virtual Private Networking

The Encapsulating Security Payload (ESP) protocol provides data confidentiality, and also optionally

provides data origin authentication, data integrity checking, and replay protection.
Enhanced Cryptographic Algorithms (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#12)

Cryptographic algorithms supported in the VPN selection for Key Exchange Policy and Data policy security

association attributes.
Related information
http://www.rfc-editor.org (http://www.rfc-editor.org)

Encapsulating Security Payload

The Encapsulating Security Payload (ESP) protocol provides data confidentiality, and also optionally

provides data origin authentication, data integrity checking, and replay protection.
The difference between ESP and the Authentication Header (AH) protocol is that ESP provides encryption,

while both protocols provide authentication, integrity checking, and replay protection. With ESP, both

communicating systems use a shared key for encrypting and decrypting the data they exchange.
If you decide to use both encryption and authentication, then the responding system first authenticates

the packet and then, if the first step succeeds, the system proceeds with decryption. This type of

configuration reduces processing overhead, as well as reduces your vulnerability to denial-of-service

attacks.

Two ways of using ESP
You can apply ESP in two ways: transport mode or tunnel mode. In transport mode, the ESP header

follows the IP header of the original IP datagram. If the datagram already has an IPSec header, then the

ESP header goes before it. The ESP trailer and the optional authentication data follow the payload.
Transport mode does not authenticate or encrypt the IP header, which might expose your addressing

information to potential attackers while the datagram is in transit. Transport mode requires less

processing overhead than tunnel mode, but does not provide as much security. In most cases, hosts use

ESP in transport mode.
Tunnel mode creates a new IP header and uses it as the outermost IP header of the datagram, followed

by the ESP header and then the original datagram (both the IP header and the original payload). The ESP

trailer and the optional authentication data are appended to the payload. When you use both encryption

and authentication, ESP completely protects the original datagram because it is now the payload data for

the new ESP packet. ESP, however, does not protect the new IP header. Gateways must use ESP in tunnel

mode.

What algorithms does ESP use to protect my information?
ESP uses a symmetric key that both communicating parties use to encrypt and decrypt the data they

exchange. The sender and the receiver must agree on the key before secure communication takes place

between them. VPN uses Data Encryption Standard (DES), triple-DES (3DES), Advanced Encryption

Standard (AES), or AES-CBC and AES-CTR for encryption.
If you choose the AES algorithm for encryption then you might want to enable Extended Sequence

Number (ESN). ESN allows you to transmit large volumes of data at a high speed. The VPN connection

uses a 64-bit sequence numbers instead of 32-bit numbers over IPSec. Using 64-bit sequence numbers

allows more time before re-keying, which prevents sequence number exhaustion and minimizes the use

of system resources.
The Internet Engineering Task Force (IETF) formally defines the algorithms in the following Request for

Comments (RFC):
• DES in Request for Comment (RFC) 1829, The ESP DES-CBC Transform
• 3DES in RFC 1851, The ESP Triple DES Transform
• AES-CBC in RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec
• AES-CTR in RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode with IPSec

Encapsulating Security Payload (ESP)

Virtual Private Networking 5

You can view these and other RFCs on the Internet at the following Web address: http://www.rfc-

editor.org.
ESP uses HMAC-MD5, HMAC-SHA, HMAC-SHA-*****************, HMAC-SHA-512, and AES-XCBC-

MAC algorithms to provide authentication functions. Each of the algorithms take variable-length input

data and a secret key to produce fixed-length output data (called a hash or MAC value). If the hashes of

two messages match, then it is likely that the messages are the same.
The Internet Engineering Task Force (IETF) formally defines the algorithms in the following Request for

Comments (RFC):
• HMAC-MD*************, HMAC-MD5 IP Authentication with Replay Prevention
• HMAC-SHA in RFC 2404, The Use of HMAC-******** within ESP and AH
• HMAC-SHA_*****************, and HMAC-SHA-***************, Using HMAC-SHA-256, HMAC-

SHA-384, and HMAC-SHA-512 with IPsec

• AES-XCBC-MAC in RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
You can view these RFCs on the Internet at the following Web address: http://www.rfc-editor.org.
ESP uses AES-CCM and AES-GCM to provide encryption and authentication. An authentication algorithm

cannot be selected if one of these "combined" algorithms is chosen.
• AES-CCM in RFC 4309, Using Advanced Encryption Standard (AES) CCM mode with IPSec Encapsulating

Security Payload (ESP)

• AES-GCM in RFC 4106, The Use of Galios/Counter Mode (GCM) in IPSec Encapsulating Security Payload

(ESP)

ESP uses AES-GMAC (Galios Message Authentication Code) to provide authentication, but not encryption.
• AES-GMAC in RFC 4543, The Use of Galios Message Authentication Code (GMAC) in IPSec ESP and AH.
Related concepts
Authentication Header (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#9)

The Authentication Header (AH) protocol provides data origin authentication, data integrity, and replay

protection. However, AH does not provide data confidentiality, which means that all of your data is sent in

the clear.
Enhanced Cryptographic Algorithms (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#12)

Cryptographic algorithms supported in the VPN selection for Key Exchange Policy and Data policy security

association attributes.
Related information
http://www.rfc-editor.org (http://www.rfc-editor.org)

AH and ESP combined

VPN allows you to combine AH and ESP for host-to-host connections in transport mode.
Combining these protocols protects the entire IP datagram. Although combining the two protocols offers

more security, the processing overhead involved might outweigh the benefit.

Enhanced Cryptographic Algorithms

Cryptographic algorithms supported in the VPN selection for Key Exchange Policy and Data policy security

association attributes.
Key Exchange Policy:
• Encryption

– 3DES-CBC
– AES-CBC (128, ************ bit)
– AES-CTR (128, ************ bit)

• Hash/PRF

6 IBM i: Virtual Private Networking

– SHA
– HMAC-SHA-256
– HMAC-SHA-384
– HMAC-SHA-512
– AES-XCBC-MAC (HASH 96 bits; PRF 128 bits)

• Diffie-Hellman

– Group 1
– Group 2
– Group 14
– Group 19 (256 ECP)
– Group 20 (384 ECP)
– Group 24

Data Policy:
• Authentication

– SHA
– HMAC-SHA-256
– HMAC-SHA-384
– HMAC-SHA-512
– AES-XCBC-MAC

• Diffie-Hellman for PFS

– Group 1
– Group 2
– Group 14
– Group 19 (256 bit ECP)
– Group 20 (384 bit ECP)
– Group 24

• Encryption

– 3DES-CBC
– AES-CBC (128, ************ bit)
– AES-CTR (128, ************ bit)
– AES-CCM (128, ************ bit)
– AES-GCM (128, ************ bit)
– AES-GMAC (128, ************ bit)

In addition to the enhanced cryptographic algorithms being supported, the following algorithms are de-

emphasized. They are still supported, but the direction is to use them less.
• Hash

– MD5

• Encryption

– DES
– RC4
– RC5

Virtual Private Networking 7

The Internet Engineering Task Force (IETF) formally defines the algorithms in the following Request for

Comments (RFC):
• AES-CBC in RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec
• AES-XCBC-MAC in RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
• HMAC-SHA_*****************, and HMAC-SHA-***************, Using HMAC-SHA-256, HMAC-

SHA-384, and HMAC-SHA-512 with IPsec

• HMAC-MD*************, HMAC-MD5 IP Authentication with Replay Prevention
• DES in Request for Comment (RFC) 1829, The ESP DES-CBC Transform
• DH groups ********* in RFC 4754, IKE and IKEV2 Authentication Using the Elliptical Curve Digital

Signature Algorithm (ECDSA)

• AES-CTR in RFC 3686, Using Advanced Encryption (AES) Counter Mode with IPSec Encapsulating

Security Payload (ESP)

• AES-CCM in RFC 4309, Using Advanced Encryption Standard (AES) CCM mode with IPSec Encapsulating

Security Payload (ESP)

• AES-GCM in RFC 4106, The Use of Galios/Counter Mode (GCM) in IPSec Encapsulating Security Payload

(ESP)

• AES-GMAC in RFC 4543, The Use of Galios Message Authentication Mode (GMAC) in IPSec ESP and AH
You can view these RFCs on the Internet at the following Web address: http://www.rfc-editor.org.
Related concepts
Authentication Header (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#9)

The Authentication Header (AH) protocol provides data origin authentication, data integrity, and replay

protection. However, AH does not provide data confidentiality, which means that all of your data is sent in

the clear.
Encapsulating Security Payload (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#11)

The Encapsulating Security Payload (ESP) protocol provides data confidentiality, and also optionally

provides data origin authentication, data integrity checking, and replay protection.

Key management

A dynamic VPN provides additional security for your communications by using the Internet Key Exchange

(IKE) protocol for key management. IKE allows the VPN servers on each end of the connection to

negotiate new keys at specified intervals.
With each successful negotiation, the VPN servers regenerate the keys that protect a connection, thus

making it more difficult for an attacker to capture information from the connection. Additionally, if you use

perfect forward secrecy, attackers cannot derive future keys based on past keying information.
The VPN key manager is IBM's implementation of the Internet Key Exchange (IKE) protocol. The key

manager supports the automatic negotiation of security associations (SAs), as well as the automatic

generation and refresh of cryptographic keys.
A security association (SA) contains information that is necessary to use the IPSec protocols. For

example, an SA identifies algorithm types, key lengths and lifetimes, participating parties, and

encapsulation modes.
Cryptographic keys, as the name implies, lock, or protect, your information until it safely reaches its final

destination.
Note: Securely generating your keys is the most important factor in establishing a secure and private

connection. If your keys are compromised, then your authentication and encryption efforts, no matter

how strong, become worthless.
Phases of key management

The VPN key manager uses two distinct phases in its implementation.

8 IBM i: Virtual Private Networking

Phase 1

Phase 1 establishes a master secret from which subsequent cryptographic keys are derived in

order to protect user data traffic. This is true even if no security protection yet exists between the

two endpoints. VPN uses either RSA signature mode, ECDSA signature mode, or preshared keys to

authenticate phase 1 negotiations, as well as to establish the keys that protect the IKE messages

that flow during the subsequent phase 2 negotiations.
A preshared key is a nontrivial string up to 128 characters long. Both ends of a connection must

agree on the preshared key. The advantage of using preshared keys is their simplicity, the

disadvantage is that a shared secret must be distributed out-of-band, for example over the

telephone or through registered mail, before IKE negotiations. Treat your preshared key like a

password.
RSA Signature authentication provides more security than preshared keys because this mode uses

digital certificates to provide authentication. You must configure your digital certificates using

Digital Certificate Manager. VPN has no limit on the RSA key lengths it supports. The certificates

that you use must come from certificate authorities that both key servers trust.
ECDSA Signatures are smaller than RSA Signatures of similar cryptographic strength, resulting is

improved communication efficiency. ECDSA Signatures supports three key lengths, ECDSA-256,

ECDSA-******************. You must configure your digital certificates using Digital Certificate

Manager. The certificates that you use must come from certificate authorities that both key

servers trust. ECDSA Signatures are not supported in IKEv1.

Phase 2

Phase 2, however, negotiates the security associations and keys that protect the actual

application data exchanges. Remember, up to this point, no application data has actually been

sent. Phase 1 protects the phase 2 IKE messages.
Once phase 2 negotiations are complete, your VPN establishes a secure, dynamic connection over

the network and between the endpoints that you defined for your connection. All data that flows

across the VPN is delivered with the degree of security and efficiency that was agreed on by the

key servers during the phase ************* negotiation processes.
In general, phase 1 negotiations are negotiated once a day, while phase 2 negotiations are

refreshed every 60 minutes or as often as every five minutes. Higher refresh rates increase your

data security, but decrease system performance. Use short key lifetimes to protect your most

sensitive data.

When you create a dynamic VPN by using IBM Navigator for i, you must define an IKE policy to enable

phase 1 negotiations and a data policy to govern phase 2 negotiations. Optionally, you can use the New

Connection wizard. The wizard automatically creates each of the configuration objects VPN requires to

work properly, including an IKE policy, data policy.

Suggested reading
If you want to read more about the Internet Key Exchange (IKE) protocol and key management, review

these Internet Engineering Task Force (IETF) Request for Comments (RFC):
IKEv1

• RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP
• RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)
• RFC 2409, The Internet Key Exchange (IKE)
These RFCs are currently supported for IKEv1.

You can view these RFCs on the Internet at the following Web site: http://www.rfc-editor.org.
Related concepts
Scenario: Firewall friendly VPN (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#37)

Virtual Private Networking 9

In this scenario, a large insurance company wants to establish a VPN between a gateway in Chicago and a

host in Minneapolis when both networks are behind a firewall.
IP Security protocols (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#8)

IP Security (IPSec) provides a stable, long lasting base for providing network layer security.
IKE version 2 (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#16)

IKE version 2 is an enhancement to the Internet key exchange protocol.
Related tasks
Configuring an Internet Key Exchange policy (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#55)

The Internet Key Exchange (IKE) policy defines what level of authentication and encryption protection

IKE uses during phase 1 negotiations.
Configuring a data policy (a9dde851bd65dabb548d19d7478a12f6_197**********51636457827.1636457827.html#56)

A data policy defines what level of authentication or encryption protects data as it flows through the VPN.
Related information
http://www.rfc-editor.org (http://www.rfc-editor.org)

IKE version 2

IKE version 2 is an enhancement to the Internet key exchange protocol.
IKE version 2 (IKEv2) was developed by the IETF with RFC4306. IKEv2 enhances the function of

negotiating the dynamic key exchange and authentication of the negotiating systems for VPN.
IKEv2 also simplifies the key exchange flows and introduces measures to fix ambiguities and

vulnerabilities inherent in IKEv1.
• IKEv2 provides a simpler message flow for key exchange negotiations.
• IKEv2 provides options to rekey the IKE_SA without reauthentication.
• With IKEv2, the key life times for the IKE_SA and CHILD_SA are managed independent of the peer

system.

• IKEv2 is the basis for future enhancements to the key exchange protocol.
Both IKEv1 and IKEv2 protocols operate in two phases. The differences between the two protocols

include:
• The first phase in IKEv2 is IKE_SA, consisting of the message pair IKE_SA_INIT. The attributes of the

IKE_SA phase are defined in the Key Exchange Policy.

• The second phase in IKEv2 is CHILD_SA. The first CHILD_SA is the IKE_AUTH message pair. More

CHILD_SA message pairs can be sent for rekey and informational messages. The CHILD_SA attributes

are defined in the Data Policy.

IKEv2 provides a simpler and more efficient exchange.
• IKEv********* has two possible exchanges: main mode and aggressive mode. With main mode, the

phase ************* negotiations are in two separate phases. Phase 1 main mode uses six messages to

complete; phase 2 in quick mode uses three messages.

• IKEv2

‹›×