- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
11-27-2009 07:13 AM - edited 08-23-2017 10:52 PM
Main Mode
An IKE session begins with the initiator sending a proposal or proposals to the responder. The proposals define what encryption and authentication protocols are acceptable, how long keys should remain active, and whether perfect forward secrecy should be enforced, for example. Multiple proposals can be sent in one offering. The first exchange between nodes establishes the basic security policy; the initiator proposes the encryption and authentication algorithms it is willing to use. The responder chooses the appropriate proposal (we'll assume a proposal is chosen) and sends it to the initiator. The next exchange passes Diffie-Hellman public keys and other data. All further negotiation is encrypted within the IKE SA. The third exchange authenticates the ISAKMP session. Once the IKE SA is established, IPSec negotiation (Quick Mode) begins.
Aggressive Mode
Aggressive Mode squeezes the IKE SA negotiation into three packets, with all data required for the SA passed by the initiator. The responder sends the proposal, key material and ID, and authenticates the session in the next packet. The initiator replies by authenticating the session. Negotiation is quicker, and the initiator and responder ID pass in the clear.
Quick Mode
IPSec negotiation, or Quick Mode, is similar to an Aggressive Mode IKE negotiation, except negotiation must be protected within an IKE SA. Quick Mode negotiates the SA for the data encryption and manages the key exchange for that IPSec SA.
Graphical Representation
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Please note that the use of PFS is suggested in the first quick mode message via the optional KE payload, not within IKE Phase 1.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
how can configure cisco 877 on main mode?
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
You can create an Isakmp profile and set the mode to agressive. Then apply it to the crypto map.

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Please Briefly Explain why we have to make septate tunnel for SA & IPSec for VPN Connectivity ?
Why we build two tunnel (SA and IPSec) for VPN Data Transfer ? can it possible through only one tunnel ?
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Devang,
First tunnel (ISAKMP - phase 1) both sides initiates and agree on terms they'll use (as described in figure). At this point, if any config that must be the same on both sides are different, then your VPN won't be established.
Second tunnel (IPSec - phase 2) is created for encryption. You can use it or not, but it's highly recommended to use it.
Transit data will flow through 2nd tunnel, encrypted.
You can verify your SAs with these commands:
show crypto isakmp sa
show crypto ipsec sa peer «peer's IP»
HTH,
Patryck Dumit
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
How do I connect a Cisco / iPhone VPN client to a firewall running main mode ?
As soon as I disable aggressive mode VPN clients are not able to connect.

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Right....perfect forward secrecy comes in Phase 2, not in Phase 1.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi Patryck,
I have a question here. For DH Key exchange, first we need to agree upon prime number "p" (prime modulus) and other number "g" (generator).
Can you mention in which message we are going to negotiate/agree on these numbers..?
I have checked pcap files and i don't see these values anywhere.
Thanks,
Srini
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
I beg to disagree with the highlighted text below:
Aggressive Mode squeezes the IKE SA negotiation into three packets, with all data required for the SA passed by the initiator. The responder sends the proposal, key material and ID, and authenticates the session in the next packet. The initiator replies by authenticating the session. Negotiation is quicker, and the initiator and responder ID pass in the clear.
It is partly true, the initiator in the very first message lists Identification ID which is set to responder's IP. This is in clear text, responder sends the 2nd message in clear text with hash calculated . Now at this point initiator knows responder agrees its SA proposal sent in first message, initiator can now use session key, to ecrypyt message,the third message from initiator is encrypted which carries Identification ID as its own IP, calculated hash, so we see only responder ID is sent in clear text not initiator's ID.
For detail look at its capture file for aggressive mode:
https://www.cloudshark.org/captures/e51f5c8a6b24
Thanks,
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi Sara:
The link that you provided is not working.
Will like to understand more whether this vulnerability flag on aggressive mode is valid or not.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Looks like Sarah's link shows only the Responder ID, as mentioned (Aggressive Mode). Here's a pic, in case the link doesn't work for you.
Interesting stuff!
You can use it with certs for identity protection, though.
This link also has some quick and useful info:
http://www.internet-computer-security.com/VPN-Guide/Aggressive-Mode.html
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
It is partly true, the initiator in the very first message lists Identification ID which is set to responder's IP. This is in clear text, responder sends the 2nd message in clear text with hash calculated . Now at this point initiator knows responder agrees its SA proposal sent in first message, initiator can now use session key, to ecrypyt message,the third message from initiator is encrypted which carries Identification ID as its own IP, visit here calculated hash, so we see only responder ID is sent in clear text not initiator's ID.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
"It is partly true, the initiator in the very first message lists Identification ID which is set to responder's IP. This is in clear text, responder sends the 2nd message in clear text with hash calculated . Now at this point initiator knows responder agrees its SA proposal sent in first message, initiator can now use session key, to ecrypyt message,the third message from initiator is encrypted which carries Identification ID as its own IP, visit here calculated hash, so we see only responder ID is sent in clear text not initiator's ID."
Thanks a lot for detailed information regarding this one really help me a lot.