Understanding 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, see IPsec Security Protocols.)
- A Diffie-Hellman (DH) group. (For more information, see Diffie-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 OS 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.
This topic includes the following sections:
Main Mode
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 DH exchange, and the initiator and recipient each provide a pseudorandom 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 DH exchange, and sends a pseudorandom number and its IKE identity.
- Second message—The recipient accepts the SA; authenticates the initiator; and sends a pseudorandom 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. |
Related Topics
- Junos OS Feature Support Reference for SRX Series and J Series Devices
- VPN Overview
- Example: Configuring an IKE Phase 1 Proposal (CLI)
- Example: Configuring an IKE Policy (CLI)
- Example: Configuring an IKE Gateway (CLI)
Hide Navigation Pane
Show Navigation Pane
Download
SHA1
