Table of Contents 1 IKE 1-1

Table of Contents 1 IKE 1-1 IKE Overview 1-1 Security Mechanism of IKE 1-1 Operation of IKE 1-1 Functions of IKE in IPsec 1-2 Relationship Between IKE and IPsec 1-3 Protocols 1-3 Configuring IKE 1-3 Configuration Task List 1-3 Configuring Global IKE Parameters 1-4 Configuring an IKE Proposal 1-5 Configuring IKE DPD 1-7 Configuring an IKE Peer 1-8 Viewing IKE SAs 1-10 IKE Configuration Example 1-11 i

1 IKE IKE Overview Built on a framework defined by the Internet Security Association and Key Management Protocol (ISAKMP), Internet Key Exchange (IKE) provides automatic key negotiation and SA establishment services for IP Security (IPsec), simplifying the application, management, configuration and maintenance of IPsec dramatically. Instead of transmitting keys directly across a network, IKE calculates shared keys after exchanging a series of data. This disables a third party from decrypting the keys even if the third party captured all exchanged data that is used to calculate the keys. Security Mechanism of IKE IKE has a series of self-protection mechanisms and supports secure identity authentication, key distribution, and IPsec SA establishment on unsecured networks. Data authentication Data authentication involves two concepts: Identity authentication: Mutual identity authentication between peers. Two authentication methods are available: pre-shared key authentication and PKI-based digital signature authentication (RSA signature). Identity protection: Protecting identity information by using the generated keys to encrypt it for transmission. DH The Diffie-Hellman (DH) algorithm is a public key algorithm. With this algorithm, two peers can exchange some data and then use the data to calculate the shared keys, rather than transmitting the keys directly. Due to the decryption complexity, a third party cannot decrypt the keys even after intercepting all the exchanged data. Thus, the DH exchange technology enables communication peers to obtain the common information securely. PFS The Perfect Forward Secrecy (PFS) feature is a security feature based on the DH algorithm. It guarantees that decryption of a key makes no impact on the security of other keys because the keys have no derivative relations. For IPsec, PFS is implemented by adding an additional key exchange at IKE negotiation phase 2. Operation of IKE IKE negotiates keys and establishes SAs for IPsec in two phases: 1) Phase 1: The two peers establish an ISAKMP SA, a secure, authenticated channel for communication. In this phase, two modes are available: main mode and aggressive mode. 1-1

2) Phase 2: Using the ISAKMP SA established in phase 1, the two peers negotiate to establish IPsec SAs. Figure 1-1 IKE exchange process in main mode As shown in Figure 1-1, the main mode of IKE negotiation in phase 1 involves three pairs of messages: SA exchange, used for negotiating the security policy. Key exchange, used for exchanging the Diffie-Hellman public value and other values like the random number. Key data is generated in this stage. ID and authentication data exchange, used for authentication of identity and exchanged data in phase 1. The main difference between main mode and aggressive mode is that aggressive mode does not provide identity protection and only exchanges the above three messages. As aggressive mode exchanges less information and features higher negotiation speed, it applies to scenarios where the requirement for identity protection is lower. For scenarios with higher requirement for identity protection, main mode is recommended. Functions of IKE in IPsec IKE automatically negotiates IPsec parameters such as the keys, reducing the manual configuration complexity greatly. IKE always performs DH exchange when establishing an SA, ensuring that each SA has a key with no relation with any other key. IPsec uses the sequence number, a 32-bit value in the AH or ESP header, for anti-replay. If the value overflows, a new SA needs to be established for anti-replay, in which procedure IKE is required. Identity authentication and management of peers influence IPsec deployment. A large-scale IPsec deployment needs the support of certificate authorities (CAs) or other institutes which manage identity data centrally. 1-2

IKE allows for end-to-end dynamic authentication. Relationship Between IKE and IPsec Figure 1-2 Relationship between IKE and IPsec IKE SA negotiation IKE Device A Device B TCP/UDP SA TCP/UDP IPsec Encrypted IP packets IPsec Figure 1-2 illustrates the relationship between IKE and IPsec: IKE is an application layer protocol using UDP and functions as the signaling protocol of IPsec. IKE negotiates SAs for IPsec and delivers negotiated parameters and generated keys to IPsec. IPsec uses the SAs set up through IKE negotiation for encryption and/or authentication of IP packets. Protocols IKE related protocols include: RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP) RFC2409: The Internet Key Exchange (IKE) RFC2412: The OAKLEY Key Determination Protocol Configuring IKE Configuration Task List Before configuring IKE, you need to: Determine the strength of the algorithms for IKE negotiation, namely the security protection level, including the identity authentication method, encryption algorithm, authentication algorithm, and DH group. Different algorithms provide different levels of protection. A stronger algorithm means more resistant to decryption of protected data but requires more resources. Generally, the longer the key, the stronger the algorithm. Determine the pre-shared key or the PKI domain the certificate belongs to. For PKI configuration, see PKI Configuration in the Firewall Web Configuration Manual. 1-3

Perform the tasks in Table 1-1 to configure IKE. Table 1-1 IKE configuration task list Task Configuring Global IKE Parameters Configuring an IKE Proposal Configuring IKE DPD Optional Remarks Configure the IKE local name and NAT keepalive interval. Required when IKE peers need to specify an IKE proposal. An IKE proposal defines a set of attributes describing how IKE negotiation should take place. You may create multiple IKE proposals with different preferences. The preference of an IKE proposal is represented by its sequence number, and the smaller the sequence number, the higher the preference. Two peers must have at least one pair of matched IKE proposals for successful IKE negotiation. During IKE negotiation, the negotiation initiator sends its IKE proposals to the peer. The peer will match the IKE proposals against its own IKE proposals, starting with the one with the smallest sequence number. The match goes on until a match is found or all IKE proposals are found mismatched. The matched IKE proposals will be used to establish the security tunnel. Two matched IKE proposals have the same encryption algorithm, authentication method, authentication algorithm, and DH group. The ISAKMP SA lifetime will take the smaller one of the two matched IKE proposals. By default, there is an IKE proposal, which has the lowest preference and uses these default settings: Authentication method: Pre-shared key, Authentication algorithm: SHA, Encryption algorithm: DES-CBC, DH group: Group1, SA lifetime: 86400 seconds. Optional Dead peer detection (DPD) is used for detecting the status of IPsec peers. With the DPD function enabled, if an end receives no IPsec protected packets from its peer in the DPD query triggering interval, it sends a DPD request to the peer to detect whether the IKE peer exists. Required Create an IKE peer and configure the related parameters. Configuring an IKE Peer Viewing IKE SAs If you change the settings of an IKE peer, be sure to clear the established IPsec SAs and ISAKMP SAs on the pages displayed after you select VPN > IKE > IKE SA and select VPN > IPSec > IPSec SA respectively. Otherwise, SA renegotiation will fail. Optional View the summary information of the current ISAKMP SA. Configuring Global IKE Parameters Select VPN > IKE > Global from the navigation tree to enter IKE global configuration page, as shown in Figure 1-3. 1-4

Figure 1-3 IKE global configuration page Table 1-2 describes the configuration items for configuring global IKE parameters. Table 1-2 Global IKE configuration items Item IKE Local Name NAT Keepalive Interval Type a name for the local security gateway. If the local device acts as the IKE negotiation initiator and uses the security gateway name for IKE negotiation, you need to configure this argument on the local device. Then, the local device sends its gateway name as identification to its peer and the peer uses the locally configured remote gateway name to authenticate the local device. Therefore, make sure that the local gateway name configured here is identical to the remote gateway name configured on its peer. By default, the device name is used as the local gateway name. Set the interval at which the ISAKMP SA sends NAT keepalive packets to its peer. NAT mappings on a NAT gateway may get aged. If no packet traverses an IPsec tunnel in a certain period of time, the NAT mapping will be deleted, disabling the tunnel beyond the NAT gateway from transferring data. To prevent NAT mappings from being aged, an ISAKMP SA sends to its peer NAT keepalive packets at a certain interval to keep the NAT session alive. Return to IKE configuration task list. Configuring an IKE Proposal Select VPN > IKE > Proposal from the navigation tree to display existing IKE proposals, as shown in Figure 1-4. Then, click Add to enter the IKE proposal configuration page, as shown in Figure 1-5. Figure 1-4 IKE proposal list 1-5

Figure 1-5 Add an IKE proposal Table 1-3 describes the configuration items for creating an IKE proposal. Table 1-3 IKE proposal configuration items. Item IKE Proposal Number Authentication Method Authentication Algorithm Encryption Algorithm DH Group Type the IKE proposal number. The number also stands for the priority of the IKE proposal, with a smaller value meaning a higher priority. During IKE negotiation, the system matches IKE proposals in order of proposal number, starting from the smallest one. Select the authentication method to be used by the IKE proposal. Preshared Key: Uses the pre-shared key method. RSA Signature: Uses the RSA digital signature method. Select the authentication algorithm to be used by the IKE proposal. SHA1: Uses HMAC-SHA1. MD5: Uses HMAC-MD5. Select the encryption algorithm to be used by the IKE proposal. DES-CBC: Uses the DES algorithm in CBC mode and 56-bit keys for encryption. 3DES-CBC: Uses the 3DES algorithm in CBC mode and 168-bit keys for encryption. AES-128: Uses the AES algorithm in CBC mode and 128-bit keys for encryption. AES-192: Uses the AES algorithm in CBC mode and 192-bit keys for encryption. AES-256: Uses the AES algorithm in CBC mode and 256-bit keys for encryption. Select the DH group to be used in key negotiation phase 1. Group1: Uses the 768-bit Diffie-Hellman group. Group2: Uses the 1024-bit Diffie-Hellman group. Group5: Uses the 1536-bit Diffie-Hellman group. Group14: Uses the 2048-bit Diffie-Hellman group. 1-6

Item Type the ISAKMP SA lifetime of the IKE proposal. Before an SA expires, IKE negotiates a new SA. As soon as the new SA is set up, it takes effect immediately and the old one will be cleared automatically when it expires. SA Lifetime If the SA lifetime expires, the system automatically updates the ISAKMP SA. As DH calculation in IKE negotiation takes time, especially on low-end devices, it is recommended to set the lifetime greater than 10 minutes to prevent the SA update from influencing normal communication. Return to IKE configuration task list. Configuring IKE DPD Select VPN > IKE > DPD from the navigation tree to display existing DPDs, as shown in Figure 1-6. Then, click Add to enter the DPD configuration page, as shown in Figure 1-7. Figure 1-6 DPD list Figure 1-7 Add an IKE DPD Table 1-4 describes the configuration items for creating an IKE DPD. Table 1-4 IKE DPD configuration items Item DPD Name DPD Query Triggering Interval DPD Packet Retransmission Interval Type a name for the IKE DPD. Type the interval after which DPD is triggered if no IPsec protected packets is received from the peer. Type the interval after which DPD packet retransmission will occur if no DPD response is received. 1-7

Return to IKE configuration task list. Configuring an IKE Peer Select VPN > IKE > Peer from the navigation tree to display existing IKE peers, as shown in Figure 1-8. Then, click Add to enter the IKE peer configuration page, as shown in Figure 1-9. Figure 1-8 IKE peer list Figure 1-9 Add an IKE peer Table 1-5 describes the configuration items for creating an IKE peer. 1-8

Table 1-5 IKE peer configuration items Item Peer Name Type a name for the IKE peer. Select the IKE negotiation mode in phase 1, which can be Main or Aggressive. IKE Negotiation Mode Local ID Type If one end of an IPsec tunnel is configured to obtain an IP address dynamically, the IKE negotiation mode must be Aggressive. In this case, SAs can be established as long as the username and password are correct. The specified negotiated mode is used when the local peer is the negotiation initiator. When acting as the responder, the negotiation mode of the initiator is used. Select the local ID type in IKE negotiation phase 1 IP Address: Uses an IP address as the ID in IKE negotiation. Gateway Name: Uses a gateway name as the ID in IKE negotiation. In main mode, only the ID type of IP address can be used in IKE negotiation and SA establishment. Local IP Address Type the IP address of the local security gateway. By default, it is the primary IP address of the interface referencing the security policy. Configure this item when you want to specify a special address for the local gateway Remote Gateway Remote ID IP Address Hostname Normally, you do not need to specify the local IP address unless you want to specify a special address, such as the loopback interface address. For the local peer to act as the initiator, you need to configure the remote gateway name or IP address, so that the initiator can find the remote peer during the negotiation. Type the IP address or host name of the remote security gateway. You can specify an IP address or a range of IP addresses for the remote gateway. If the local end is the initiator of IKE negotiation, it can have only one remote IP address and its remote IP address must match the local IP address configured on its peer. If the local end is the responder of IKE negotiation, it can have more than one remote IP address and one of its remote IP addresses must match the local IP address configured on its peer. The host name of the remote gateway is the only identifier of the IPsec peer in the network. The host name can be resolved into an IP address by the DNS server. If host name is used, the local end can serve as the initiator of IKE negotiation. Type the name of the remote security gateway. If the local ID type configured for the IKE negotiation initiator is Gateway Name, the initiator sends its gateway name (IKE Local Name) to the responder for identification. The responder then uses the locally configured remote gateway name (Remote ID) to authenticate the initiator. Therefore, make sure that the remote gateway name configured here is identical to the local gateway name (IKE Local Name) configured on its peer. Pre-Shared Key PKI Domain Enable DPD Configure one of these two items according to the authentication method: If the authentication method is pre-shared key, select Pre-Shared Key and then type the pre-shared key in the following text box. If the authentication method is RSA signature, select PKI Domain and then select the PKI domain to which the certificate belongs in the following drop-down box. Select the IKE DPD to be applied to the IKE peer. 1-9

Item Enable the NAT traversal function Enable the NAT traversal function for IPsec/IKE. The NAT traversal function must be enabled if a NAT security gateway exists in an IPsec/IKE VPN tunnel. In main mode, IKE does not support NAT traversal and therefore this item is unavailable. To save IP addresses, ISPs often deploy NAT gateways on public networks so as to allocate private IP addresses to users. In this case, one end of an IPsec/IKE tunnel may have a public address while the other end may have a private address, and therefore NAT traversal must be configured at the private network side to set up the tunnel. Return to IKE configuration task list. Viewing IKE SAs Select VPN > IKE > IKE SA from the navigation tree to display brief information about established ISAKMP SAs, as shown in Figure 1-10. You can click Delete All to remove all ISAKMP SAs. Note that when you clear a local IPsec SA, if the corresponding ISAKMP SA is still present, the local end will send a Delete Message to the remote end across the ISAKMP SA, notifying the remote end to delete the corresponding IPsec SA. If the corresponding ISAKMP SA is no longer present, the local end cannot notify the remote end to clear the corresponding IPsec SA. Figure 1-10 IKE SA list Table 1-6 describes the fields of IKE SA information. Table 1-6 IKE SA information fields Field Connection ID Remote IP Address Identifier of the ISAKMP SA Remote IP address of the SA 1-10

Field Flag Status of the SA, which may be: RD (ready): Indicates that the SA has already been established and is ready for use. ST (stayalive): Indicates that the local end is the tunnel negotiation initiator. RL (replaced): Indicates that the tunnel has been replaced and will be cleared soon. FD (fading): Indicates that the soft lifetime expires but the tunnel is still in use. The tunnel will be deleted when the hard lifetime expires. TO (timeout): Indicates the SA has received no keepalive packets after the last keepalive timeout. If no keepalive packets are received before the next keepalive timeout, the SA will be deleted. IKE maintains the link status of an ISAKMP SA by keepalive packets. Generally, if the peer is configured with the keepalive timeout, you need to configure the keepalive packet transmission interval on the local end. If the peer receives no keepalive packet during the timeout interval, the ISAKMP SA will be tagged with the TIMEOUT tag (if it does not have the tag), or be deleted along with the IPsec SAs it negotiated (when it has the tag already). Domain of Interpretation Interpretation domain that the SA belongs to Return to IKE configuration task list. IKE Configuration Example Network requirements As shown in Figure 1-11, an IPsec tunnel is established through IKE negotiation between the security gateways Device A and Device B to allow secure communication between Host A and Host B. Device A is configured with an IKE proposal using the sequence number of 10 and the authentication algorithm of MD5. Device B uses the default IKE proposal. The two devices use the pre-shared key authentication method. Figure 1-11 Network diagram for IKE configuration Security gateway Device A GE0/1 1.1.1.1/16 Internet Security gateway Device B GE0/1 2.2.2.2/16 Host A Host B Configuration procedure 1) Configure security gateway Device A # Configure the IKE peer. Select VPN > IKE > Peer from the navigation tree and then click Add. Perform the configurations shown in Figure 1-12. 1-11

Figure 1-12 Configure the IKE peer Type peer as the peer name. Select Main as the negotiation mode. Type 2.2.2.2 as the remote gateway IP address. Select Pre-Shared Key and type abcde as the pre-shared key. Click Apply. # Create an IKE proposal numbered 10. Select VPN > IKE > Proposal from the navigation tree and then click Add. Perform the configurations shown in Figure 1-13. 1-12

Figure 1-13 Create an IKE proposal numbered 10 Type 10 as the IKE proposal number. Select Preshared Key as the authentication method. Select MD5 as the authentication algorithm. Type 5000 as the SA lifetime. Click Apply. 2) Configure security gateway Device B # Configure the IKE peer. Select VPN > IKE > Peer from the navigation tree and then click Add to enter the IKE peer configuration page, as shown in Figure 1-12. Perform the following configurations: Type peer as the peer name. Select Main as the negotiation mode. Type 1.1.1.1 as the remote gateway IP address. Select Pre-Shared Key and type abcde as the pre-shared key. Click Apply. After the above configuration, security gateways Device A and Device B should be able to perform IKE negotiation. Device A is configured with an IKE proposal numbered 10, which uses the authentication algorithm of MD5, but Device B has only a default IKE proposal, which uses the default authentication algorithm of SHA. Therefore, Device B has no proposal matching proposal 10 of Device A, and the two devices have only one pair of matched proposals, namely the default IKE proposals. In addition, the two devices are not required to have the same ISAKMP SA lifetime; they will negotiate one. 1-13