following paragraphs.

IKE Phase 1.5 (optional): To further authenticate VPN participants (clients), you can use a protocol called Extended Authentication (Xauth) that provides user authentication of IPsec tunnels within the IKE protocol. Additionally, you can exchange other parameters between the peers. Mode configuration is used to deliver parameters such as the IP address and Domain Name System (DNS) address to the client.

IKE Phase 2: Phase 2 SAs are negotiated by the IKE process (ISAKMP) on behalf of other services such as IPsec that need key material for operation. Because the SAs that are used by IPsec are unidirectional, separate key exchanges are needed for data that is flowing in the forward direction and the reverse direction. The two peers have already agreed upon the transform sets, hash methods, and other parameters during the Phase 1 negotiation. Quick mode is the method used for the Phase 2 SA negotiations.

To establish a secure communication channel between two peers, the IKE protocol uses these three modes of operation:

• Main Mode: In the main mode, an IKE session begins with the initiator sending a proposal or proposals to the responder. These proposals define which encryption and authentication protocols are acceptable, how long keys should remain active, and whether perfect forward secrecy (PFS) should be enforced. Multiple proposals can be sent in one offering. The first exchange between nodes establishes the basic security policy. The responder chooses the appropriate proposal and sends the proposal to the initiator. The next exchange passes DH 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: The aggressive mode squeezes the IKE SA negotiation into three packets, with all data that is required for the SA being passed by the initiator. The responder sends the proposal, keying material, and identification and authenticates the session in the next packet. The initiator replies by authenticating the session. Negotiation is quicker than in main mode, and the initiator and responder ID pass in plaintext. Aggressive mode is appropriate and should be used whenever devices are capable of handling main mode with no difficulty.
• Quick Mode: The quick mode IPsec negotiation 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. If the respondent gives a negative response, the initiator will send the request in main mode.

Figure illustrates how an IKE negotiation results in secure communications between two SAs.

---

Content 3.2 Understanding IPsec Components and IPsec VPN Features 3.2.5 Other IKE Functions IKE can deliver additional functions that are used to verify if the peer device is still active, to pass IPsec through Network Address Translation (NAT) devices, or to exchange additional configuration parameters. These functions are summarized in Figure . Dead Peer Detection (DPD) and Cisco IOS Keepalives
DPD and Cisco IOS keepalives function on the basis of a timer. If the timer is set for 10 seconds, the router will send a “hello” message every 10 seconds. The benefit of Cisco IOS keepalives and periodic DPD is early detection of dead peers. However, Cisco IOS keepalives and periodic DPD rely on periodic messages that have to be sent frequently. The result of sending frequent messages is that the communicating peers must encrypt and decrypt more packets. The default operation of DPD is on-demand messaging. With on-demand DPD, messages are sent on the basis of traffic patterns. If a router has no traffic to send, the router never sends a DPD message. If a peer is dead and the router never has any traffic to send to the peer, the router will not find out that the peer is dead until the IKE or IPsec SA has to be rekeyed (the liveliness of the peer is unimportant if the router is not trying to communicate with the peer). The Problem with NAT
IPsec peers cannot be located behind a NAT-enabled device. A standard IPsec VPN tunnel does not work if there are one or more NAT (or Port Address Translation [PAT]) points in the delivery path of the IPsec packet. However, Internet service providers (ISPs) and small offices/home offices (SOHO) often use NAT to share single IP addresses. Although NAT helps conserve IP address space, NAT also introduces problems for IPsec. In fact, an IPsec VPN tunnel will not work if there are no port numbers in the IPsec headers that can be used to create and maintain translation tables. The Layer 4 port information is encrypted and therefore cannot be read. The Solution: IPsec NAT Transversal (NAT-T)
To solve the NAT issue, the IETF, through RFCs 3947 and 3948, has defined IPsec NAT Transversal (IPsec NAT-T). IPsec NAT-T defines both changes in the negotiation process and different methods of sending IPsec-protected data. The IPsec NAT-T, which was introduced in Cisco IOS Release 12.2(13)T, enables IPsec traffic to travel through NAT or PAT devices in the network by encapsulating IPsec packets in a UDP wrapper. NAT-T is negotiated with these factors:

• NAT-T detection
  • During IKE Phase 1 negotiation, two types of NAT detection occur before IKE quick mode begins: NAT support and NAT existence along the network path. To detect NAT support, the vendor ID string is exchanged with the remote peer. The remote peer sends a vendor ID string payload to its peer to indicate that this version supports NAT-T. Thereafter, NAT existence along the network path can be determined.
  • NAT-T enables an IPsec device to find any NAT device between two IPsec peers. To detect whether a NAT device exists along the network path, the peers send a payload with hashes of the IP address and port of both the source and destination address from each end. The hashes are sent as a series of NAT discovery (NAT-D) payloads. If, upon receipt, both ends recalculate the hashes and the hashes match the payload hash, each peer knows that no NAT device exists on the network path between them. If the payload hash and recalculated hashes do not match (that is, someone translated the address or port), then each peer needs to perform NAT-T to transport the IPsec packet through the network.
• NAT-T decision: While IKE Phase 1 detects NAT support and NAT existence along the network path, IKE Phase 2 decides whether the peers at both ends will use NAT-T. Quick mode SA payload is used for NAT-T negotiation.
• UDP encapsulation of IPsec packets: In addition to allowing IPsec packets to traverse across NAT devices, UDP encapsulation also addresses many incompatibility issues between IPsec, NAT, and PAT. The resolved issues are as follows:
  • Incompatibility between IPsec ESP and PAT: If PAT finds a legislative IP address and port, PAT drops the ESP packet. To prevent an ESP packet drop, UDP encapsulation is used to hide the ESP packet behind the UDP header. Therefore, PAT treats the ESP packet as a UDP packet, processing the ESP packet as a normal UDP packet.
  • Incompatibility between checksums and NAT: In the new UDP header, the checksum value is always 0. This value prevents an intermediate device from validating the checksum against the packet checksum. The checksum issue is therefore resolved because NAT changes the IP source and destination addresses.
  • Incompatibility between fixed IKE destination ports and PAT: PAT changes the port address in the new UDP header for translation and leaves the original payload unchanged.
• UDP encapsulated process for software engines: Transport Mode and Tunnel Mode ESP Encapsulation. After the IPsec packet is encrypted by a hardware accelerator or a software crypto engine, a UDP header and a non-IKE marker (which is 8 bytes in