Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Configuring IKE Proposals

    Dynamic security associations (SAs) require IKE configuration. With dynamic SAs, you configure IKE first, and then the SA. IKE creates the dynamic SAs and negotiates them for IPsec. The IKE configuration defines the algorithms and keys used to establish the secure IKE connection with the peer security gateway.

    You can configure one or more IKE proposals. Each proposal is a list of IKE attributes to protect the IKE connection between the IKE host and its peer.

    Note: In IKEv1, the authentication method for SAs is negotiated with the remote peer based on the type of authentication method configured in the IKE proposal. In IKEv2, such a negotiation is not performed with the remote peer. Instead, each IKE peer uses the authentication method that is locally configured for them.

    For SAs in IKEv2, the authentication method is either the default value as IKEv1 (if another authentication method is not configured in the IKE proposal) or all IKEv2 proposals in the IKE policy must be configured with the same authentication method value.

    To configure an IKE proposal, include the proposal statement and specify a name at the [edit services ipsec-vpn ike] hierarchy level:

    [edit services ipsec-vpn ike]
    proposal proposal-name {authentication-algorithm (md5 | sha1 | sha-256);authentication-method (dsa-signatures | pre-shared-key | rsa-signatures);dh-group (group1 | group2 | group5 |group14);encryption-algorithm algorithm;lifetime-seconds seconds;}

    This section includes the following topics:

    Configuring the Authentication Algorithm for an IKE Proposal

    To configure the authentication algorithm for an IKE proposal, include the authentication-algorithm statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level:

    [edit services ipsec-vpn ike proposal proposal-name]authentication-algorithm (md5 | sha1 | sha-256);

    The authentication algorithm can be one of the following:

    • md5—Produces a 128-bit digest.
    • sha1—Produces a 160-bit digest.
    • sha-256—Produces a 256-bit digest.

      Note: For reference information on Secure Hash Algorithms (SHAs), see Internet draft draft-eastlake-sha2-02.txt, Secure Hash Algorithms (SHA and HMAC-SHA) (expires July 2006).

    Configuring the Authentication Method for an IKE Proposal

    To configure the authentication method for an IKE proposal, include the authentication-method statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level:

    [edit services ipsec-vpn ike proposal proposal-name]authentication-method (dsa-signatures | pre-shared-keys | rsa-signatures);

    The authentication method can be one of the following:

    • dsa-signatures—Digital Signature Algorithm
    • pre-shared-keys—A key derived from an out-of-band mechanism; the key authenticates the exchanges
    • rsa-signatures—Public key algorithm (supports encryption and digital signatures)

    Configuring the Diffie-Hellman Group for an IKE Proposal

    Diffie-Hellman is a public-key cryptography scheme that allows two parties to establish a shared secret over an insecure communications channel. It is also used within IKE to establish session keys.

    To configure the Diffie-Hellman group for an IKE proposal, include the dh-group statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level:

    [edit services ipsec-vpn ike proposal proposal-name]dh-group (group1 | group2 | group5 |group14);

    The group can be one of the following:

    • group1—Specifies that IKE use the 768-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.
    • group2—Specifies that IKE use the 1024-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.
    • group5—Specifies that IKE use the 1536-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.
    • group14—Specifies that IKE use the 2048-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

    Using a Diffie-Hellman group based on a greater number of bits results a more secure IKE tunnel than using a group based on fewer bits. However, this additional security entails additional processing time.

    Configuring the Encryption Algorithm for an IKE Proposal

    To configure the encryption algorithm for an IKE proposal, include the encryption-algorithm statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level:

    [edit services ipsec-vpn ike proposal proposal-name]encryption-algorithm algorithm;

    The encryption algorithm can be one of the following:

    • 3des-cbc—Cipher block chaining encryption algorithm with a key size of 24 bytes; its key size is 192 bits long.
    • des-cbc—Cipher block chaining encryption algorithm with a key size of 8 bytes; its key size is 56 bits long.
    • aes-128-cbc—Advanced Encryption Standard (AES) 128-bit encryption algorithm.
    • aes-192-cbc—Advanced Encryption Standard (AES) 192-bit encryption algorithm.
    • aes-256-cbc—Advanced Encryption Standard (AES) 256-bit encryption algorithm.

    Note: For a list of Data Encryption Standard (DES) encryption algorithm weak and semiweak keys, see RFC 2409, The Internet Key Exchange (IKE). The AES encryption algorithms use a software implementation that has much lower throughput, so DES remains the recommended option.

    For 3des-cbc, the first 8 bytes should differ from the second 8 bytes, and the second 8 bytes should be the same as the third 8 bytes.

    If you configure an authentication proposal but do not include the encryption statement, the result is NULL encryption. Certain applications expect this result. If you configure no specific authentication or encryption values, the Junos OS uses the default values of sha1 for the authentication and 3des-cbc for the encryption.

    Configuring the Lifetime for an IKE SA

    The lifetime-seconds statement sets the lifetime of an IKE SA. When the IKE SA expires, it is replaced by a new SA (and SPI) or the IPsec connection is terminated.

    To configure the lifetime for an IKE SA, include the lifetime-seconds statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level:

    [edit services ipsec-vpn ike proposal proposal-name]lifetime-seconds seconds;

    By default, the IKE SA lifetime is 3600 seconds. The range is from 180 through 86,400 seconds.

    Note: In IKEv1, the lifetime for SAs is negotiated with the remote peer based on the type of lifetime configured in the IKE proposal. In IKEv2, such a negotiation is not performed with the remote peer. Instead, each IKE peer uses the lifetime that is locally configured for them.

    For SAs in IKEv2, the lifetime is either the default value as IKEv1 (if another lifetime is not configured in the IKE proposal) or all IKEv2 proposals in the IKE policy must be configured with the same lifetime value.

    Note: For IKE proposals, there is only one SA lifetime value, specified by the Junos OS. IPsec proposals use a different mechanism; for more information, see Configuring the Lifetime for an IPsec SA.

    Example: Configuring an IKE Proposal

    Configure an IKE proposal:

    [edit services ipsec-vpn ike]
    proposal ike-proposal {authentication-method pre-shared-keys;dh-group group1;authentication-algorithm sha1;encryption-algorithm 3des-cbc;}

    Modified: 2017-03-23