IPSec. Part 1. IKEv1. Main Mode basics

Phase 1 is where the two IKEv1 peers establish a secure, authenticated channel with which to communicate. This is called the IKEv1 Security Association (SA). “Main Mode” and “Aggressive Mode” each accomplish a Phase 1 exchange.

Phase 2 is where Security Associations are negotiated on behalf of services such as IPsec […]. “Quick Mode” accomplishes a Phase 2 exchange.

Phase 1 allows two peers to calculate the key for data encryption without an explicit exchange of this key, and authenticate the peers.

Phase 1 Main mode consists of 3 exchanges:
1) Negotiation of protection mechanisms – an exchange of SAs
2) DF exchange – Diffie-Hellman public values and ancillary data (e.g. nonces)
3) Check of the Identity of the peer (this exchange is encrypted)

Each exchange consists of 2 messages: one from Initiator and one from Responder.

IKEv1 works over UDP port 500.


For more detailed message exchange depiction, please follow this link – Tech-invite: IPsec Guide – IKE Exchanges (Phase 1 and Phase 2)

IKEv1. Main Mode. Message 1 and 2

Initiator sends a list of possible sets of attributes that can be used for the IKEv1 Security Association:
– encryption algorithm
– hash algorithm
– authentication method (pre-shared key or certificates)
– information about a group over which to do Diffie-Hellman
– lifetime for this SA

Responder picks the one that is compliant with locally configured attributes. The Lifetime may not match: it is MIN (Initiator, Responder). The rest of the attributes in one set must match.

IKEv1. Main Mode. Message 3 and 4

Initiator and Responder exchange DH public values:
– Diffie-Hellman key values (KE)
– Nonces


After this exchange, each peer calculates SKEYID based on the information known only to the peers and information retrieved from this IKE negotiation. In case of pre-shared key authentication method, these values are pre-shared key and nonces of Initiator and Responder [RFC2409#Page-10]:

SKEYID = HASH function (pre-shared-key, Ni_b | Nr_b)

This SKEYID is used in calculation of:
– SKEYID_e – Phase 1 encryption key;
– SKEYID_a – Phase 1 authentication key;
– SKEYID_d – a value that will be used in the derivation of the Phase 2 keys.

NOTE: In Main Mode, to hide the identity, a secret symmetric key is generated. Before this, the pre-shared secret key must be selected. At this point the only data for the identification of the peer is the source address of the IKE message. Thus, the IP addresses that are used for pre-shared key configuration should not overlap. IOS IKEv1/IKEv2 Selection Rules for Keyrings and Profiles – Troubleshooting Guide gives a detailed examples of such cases.

IKEv1. Main Mode. Message 5 and 6

From this point, all messages are encrypted. The following data is sent:
– HASH values that are build with use of SKEYID_a
– Identification payload (IPv4, IPv6, FQDN)

Once this is done, a secure authenticated bidirectional communication is established and IKEv1 Phase 2 starts (Quick mode)

IKEv1. Quick mode

Quick mode is used to establish tunnels for data transfer. During Quick mode the following is negotiated:
– Proxy ID local/remote – identify traffic that is a subject to be forwarded via IPSec tunnel (Source and Destination addresses/subnets)
– Encapsulation method (relevant to GRE traffic only)
– Protocol for authentication and/or encryption (AH or ESP)

A term “Proxy ID” is not used in RFC2409, although most vendors use it. RFC2409 uses a term “client identities” – IDci and IDcr [RFC2409#Page-17]:
The client identities are used to identify and direct traffic to the appropriate tunnel in cases where multiple tunnels exist between two peers and also to allow for unique and shared SAs with different granularities.

The AH protocol provides a mechanism for authentication only. This protocol does not encrypt the traffic, but simply authenticates the traffic to ensure that it came from the correct source and has not been modified. Data integrity is ensured by using a message digest that is generated by an algorithm such as HMAC-MD5 or HMAC-SHA.

The ESP protocol provides data confidentiality (encryption) and authentication (data integrity, data origin authentication, and replay protection). 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.

Quick mode consists of 3 messages:


Successful IKE exchange results in a secure tunnel – the IKE phase 1 tunnel – is only used for management traffic. This tunnel is used for establishing IKE phase 2 tunnels, which are used for a data transfer. Two IKE phase 2 tunnels are used: one is for inbound, the other is for outbound.

This entry was posted in Без рубрики and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s