Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

TechLibrary
Navigation

Understanding IKE and IPsec Packet Processing

An IPsec VPN tunnel consists of tunnel setup and applied security. During tunnel setup, the peers establish security associations (SAs), which define the parameters for securing traffic between themselves. (See VPN Overview.) After the tunnel is established, IPsec protects the traffic sent between the two tunnel endpoints by applying the security parameters defined by the SAs during tunnel setup. Within the Junos OS implementation, IPsec is applied in tunnel mode, which supports the Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols.

This topic includes the following sections:

Packet Processing in Tunnel Mode

IPsec operates in one of two modes—transport or tunnel. When both ends of the tunnel are hosts, you can use either mode. When at least one of the endpoints of a tunnel is a security gateway, such as a Junos OS router or firewall, you must use tunnel mode. Juniper Networks devices always operate in tunnel mode for IPsec tunnels.

In tunnel mode, the entire original IP packet—payload and header—is encapsulated within another IP payload, and a new header is appended to it, as shown in Figure 1. The entire original packet can be encrypted, authenticated, or both. With the Authentication Header (AH) protocol, the AH and new headers are also authenticated. With the Encapsulating Security Payload (ESP) protocol, the ESP header can also be authenticated.

Figure 1: Tunnel Mode

Tunnel Mode

In a site-to-site VPN, the source and destination addresses used in the new header are the IP addresses of the outgoing interface. See Figure 2.

Figure 2: Site-to-Site VPN in Tunnel Mode

Site-to-Site VPN in Tunnel Mode

In a dial-up VPN, there is no tunnel gateway on the VPN dial-up client end of the tunnel; the tunnel extends directly to the client itself (see Figure 3). In this case, on packets sent from the dial-up client, both the new header and the encapsulated original header have the same IP address: that of the client’s computer.

Note: Some VPN clients, such as the dynamic VPN client and Netscreen-Remote, use a virtual inner IP address (also called a “sticky address”). Netscreen-Remote enables you to define the virtual IP address. The dynamic VPN client uses the virtual IP address assigned during the XAuth configuration exchange. In such cases, the virtual inner IP address is the source IP address in the original packet header of traffic originating from the client, and the IP address that the ISP dynamically assigns the dial-up client is the source IP address in the outer header.

Figure 3: Dial-Up VPN in Tunnel Mode

Dial-Up VPN in Tunnel Mode

IKE Packet Processing

When a cleartext packet arrives on a Juniper Networks device that requires tunneling, and no active Phase 2 SA exists for that tunnel, Junos OS begins IKE negotiations and drops the packet. The source and destination addresses in the IP packet header are those of the local and remote IKE gateways, respectively. In the IP packet payload, there is a UDP segment encapsulating an ISAKMP (IKE) packet. The format for IKE packets is the same for Phase 1 and Phase 2. See Figure 4.

Meanwhile, the source host has sent the dropped packet again. Typically, by the time the second packet arrives, IKE negotiations are complete, and Junos OS protects the packet and all subsequent packets in the session—with IPsec before forwarding it.

Figure 4: IKE Packet for Phases 1 and 2

IKE Packet for Phases 1 and 2

The Next Payload field contains a number indicating one of the following payload types:

  • 0002—SA Negotiation Payload contains a definition for a Phase 1 or Phase 2 SA.
  • 0004—Proposal Payload can be a Phase 1 or Phase 2 proposal.
  • 0008—Transform Payload gets encapsulated in a proposal payload that gets encapsulated in an SA payload.
  • 0010—Key Exchange (KE) Payload contains information necessary for performing a key exchange, such as a DH public value.
  • 0020—Identification (IDx) Payload.
    • In Phase 1, IDii indicates the initiator ID, and IDir indicates the responder ID.
    • In Phase 2, IDui indicates the user initiator, and IDur indicates the user responder.

    The IDs are IKE ID types such as FQDN, U-FQDN, IP address, and ASN.1_DN.

  • 0040—Certificate (CERT) Payload.
  • 0080—Certificate Request (CERT_REQ) Payload.
  • 0100—Hash (HASH) Payload contains the digest output of a particular hash function.
  • 0200—Signature (SIG) Payload contains a digital signature.
  • 0400—Nonce (Nx) Payload contains some pseudorandom information necessary for the exchange).
  • 0800—Notify Payload.
  • 1000—ISAKMP Delete Payload.
  • 2000—Vendor ID (VID) Payload can be included anywhere in Phase 1 negotiations. Junos OS uses it to mark support for NAT-T.

Each ISAKMP payload begins with the same generic header, as shown in Figure 5.

Figure 5: Generic ISAKMP Payload Header

Generic ISAKMP Payload Header

There can be multiple ISAKMP payloads chained together, with each subsequent payload type indicated by the value in the Next Header field. A value of 0000 indicates the last ISAKMP payload. See Figure 6 for an example.

Figure 6: ISAKMP Header with Generic ISAKMP Payloads

ISAKMP Header with Generic ISAKMP Payloads

IPsec Packet Processing

After IKE negotiations complete and the two IKE gateways have established Phase 1 and Phase 2 security associations (SAs), all subsequent packets are forwarded using the tunnel. If the Phase 2 SA specifies the Encapsulating Security Protocol (ESP) in tunnel mode, the packet looks like the one shown in Figure 7. The device adds two additional headers to the original packet that the initiating host sends.

Note: For information about ESP, see ESP Protocol. For information about tunnel mode, see Packet Processing in Tunnel Mode.

As shown in Figure 7, the packet that the initiating host constructs includes the payload, the TCP header, and the inner IP header (IP1).

Figure 7: IPsec Packet—ESP in Tunnel Mode

IPsec Packet—ESP in Tunnel Mode

The router IP header (IP2), which Junos OS adds, contains the IP address of the remote gateway as the destination IP address and the IP address of the local router as the source IP address. Junos OS also adds an ESP header between the outer and inner IP headers. The ESP header contains information that allows the remote peer to properly process the packet when it receives it. This is shown in Figure 8.

Figure 8: Outer IP Header (IP2) and ESP Header

Outer IP Header (IP2) and ESP Header
Previous Page Next Page