Inline IPsec

Salient Features of Inline IPsec Data Plane

The following are the salient features of IPsec data plane

• Supports both IPv4 and IPv6 IPsec protocols

• Supports 128-bit key and 256-bit key AES-GCM

• Supports up to 2000 tunnels per chassis

• Each forwarding ASIC supports two Packet Forwarding Engines. Starting with Junos OS Release 24.4R1, both the Packet Forwarding engines can be configured, supporting up to 600Gbps half-duplex (300Gbps half-duplex per PFE).

For details on platform and Junos version support, see Feature Explorer.

Figure 1 illustrates the architecture of inline IPsec data plane, control plane, and management plane and API interface.

Figure 1: Architecture

Inline services interfaces are virtual interfaces that reside on the Packet Forwarding Engine. For more information see, Enabling Inline Service Interfaces

You can configure inline services with four si ifds per PIC in the format, si/fpc/pic/port-number. If the fpc is 0, and pic 0, you can have four si ifds – si-0/0/0, si-0/0/1 , si-0/0/2 and si-0/0/3.

The following features are supported:

• ESP tunnel mode with AES-128-GCM and AES-256-GCM for IPsec SA for both IPv4 and IPv6 encapsulations.

• 32 bit and Extended Sequence number (64 bit).

• IKEV2 with local and remote identities, re-auth, authentication using x509 certificates, IKE fragmentation.

• Dead-Peer-Detection

• Tunnel-MTU per VPN is supported. If the IPsec packet exceeds the configured MTU, the packet is pre-fragmented and then ESP encapsulated. This prevents fragmentation after ESP encapsulation.

• SA lifetime in seconds (IKE and IPsec rekey).

• UDP encapsulation of ESP packets.

The following features are not supported:

• Authentication Header (AH)

• Transport mode

• Reassembly of IPv4 packets prior to decryption

• Null encryption as per RFC4543

• IKE-V1

The IPsec and IKE Features Supported for Inline IPsec lists the supported IPSec and IKE features for inline IPsec:

A Security Association (SA) is a simplex connection that enables two hosts to communicate with each other securely by means of IPsec. An SA encapsulates the encryption and integrity algorithms, cryptographic keys, security policy, and the lifetime of the SA. An IKE SA contains attributes for establishing an IPsec SA whereas an IPsec SA defines the attributes for encrypting the actual data traffic.

ike-key-managment-daemon (IKED), a Junos RE daemon, maintains the lifetime of IKE and IPsec SAs. An IKE configuration defines the algorithms and keys used to establish a secure connection with a peer security gateway.

Security Associations

To use IPsec security services, you create SAs between two end-points. An SA is a simplex connection that enables two hosts to communicate with each other securely by means of IPsec. There are two types of SAs:

• Manual SAs require no negotiation; all values, including the keys, are static and specified in the configuration. Manual SAs statically define the security parameter index (SPI) values, algorithms, and keys to be used, and require matching configurations on both ends of the tunnel. Each peer must have the same configured options for communication to take place.

• Dynamic SAs require additional configuration. . IKE creates dynamic security associations; it negotiates SAs for IPsec. The IKE configuration defines the algorithms and keys used to establish the secure IKE connection with the peer security gateway. This connection is then used to dynamically agree upon keys and other data used by the dynamic IPsec SA. The IKE SA is negotiated first and then used to protect the negotiations that determine the dynamic IPsec SAs.

IKE

IKE is a key management protocol that creates dynamic SAs; it negotiates SAs for IPsec. An IKE configuration defines the algorithms and keys used to establish a secure connection with a peer security gateway.

IKE performs the following tasks:

• Negotiates and manages IKE and IPsec parameters.

• Authenticates secure key exchange.

• Provides mutual peer authentication by means of shared secrets (not passwords) and public keys.

• Provides identity protection (in main mode).

Inline IPsec only supports IKE version 2 (IKE v2). IKE negotiates security attributes and establishes shared secrets to form the bidirectional IKE SA. After IKE SAs are negotiated, inbound and outbound IPsec SAs are established, and the IKE SA secures the exchange of IPsec SA. IKE also generates keying material, provides Perfect Forward Secrecy, and exchanges identities.

In responder-only mode, the MX Series router does not initiate IKE negotiations, it only responds to IKE negotiations initiated by the peer gateway. This might be required while inter-operating with other vendor’s equipment, such as Cisco devices. Because the MX Series does not support the protocol and port values in the traffic selector, it cannot initiate an IPsec tunnel to another vendor’s peer gateway that expects these values. By configuring the response-only mode on the MX Series, the MX can accept the traffic selector in the IKE negotiation initiated from the peer gateway.

Figure 2 illustrates the IPsec SA and IKE exchange between peer gateways.

Dead-Peer-Detection (DPD)

DPD is a method used to verify the liveliness of the IKE peer to avoid blackholing of IPsec traffic. A device performs this verification by periodically sending DPD probes (R-U-THERE message) and waiting for DPD response (R-U-THERE-ACK message).

You can configure DPD in the following modes:

• always-send—Instructs the device to send DPD probe at regular interval regardless of whether there is outgoing IPsec traffic to the peer.

• optimized—Send DPD probe if there is no incoming IKE or IPsec traffic within the configured interval after outgoing packets are sent to the peer. This is the default DPD mode.

• probe-idle-tunnel—Send DPD probe during idle traffic time between peers.

NAT-T

Network Address Translation-Traversal (NAT-T) is a method used for managing IP address translation-related issues encountered when the data protected by IPsec passes through a device configured with NAT for address translation

IPsec WAN Connectivity

MX series routers that support inline IPsec have two Packet Forwarding Engines (PFEs) slices per YT ASIC. Each PFE slice is capable of up to 800Gbps of bandwidth. Each PFE slice has two Port Groups (PG), for a total of four PGs per YT

Figure 3: Port Groups

Each PG supports up to 400Gbps of bandwidth for WAN connectivity for regular (non-IPsec traffic). Port group 0 of each PFE slice can support IPsec.

Each port group that supports IPsec can support up to 300 Gbps WAN connectivity for IPsec traffic whereas the remaining 100Gbps can be used for non-IPsec traffic.

You can use the show chassis fpc slot-number pic slot-number to display the port-group information and the WAN connectivity status of a port.

UDP Encapsulation of ESP Traffic

IPsec provides secure tunnels between two peers, and IPsec encapsulated packets have IP headers that contain tunnel endpoint IPs that do not change. This results in the selection of a single forwarding path between the peers, as shown in Figure 7. When IPsec traffic is flowing between data centers with thousands of hosts, this single path selection limits the throughput.

Figure 7: IPsec with One Forwarding Path

You can overcome this problem by enabling UDP encapsulation of the IPsec packets, which appends a UDP header after the ESP header, as shown in Figure 8 .This provides Layer 3 and 4 information to the intermediate routers, and the IPsec packets are forwarded over multiple paths, as shown in Figure 9 . You enable UDP encapsulation for the service set.

Figure 8: Appended UDP Header

Figure 9: IPsec with Multiple Forwarding Paths

You can configure the UDP destination port with the value ranging from 1025 through 65536. The default destination port number is 500. You cannot configure 4500 as the destination port because it is a well-known port for NAT traversals.

The generated source port value is from 49152 through 65535.

UDP encapsulation supports Network Address Translation-Traversal (NAT-T)

Detection of a NAT device between IPsec peers takes precedence over UDP encapsulation configuration. If UDP encapsulation is configured between two peers, but NAT is detected between the same peers, NAT-Traversal mechanisms are implemented.

An Inbound IP packet is dropped if:

• udp-encapsulation is enabled and if the received IP packet does not have UDP header.

• udp-encapsulation is enabled and if the UDP destination port is not same as configured.

• udp-encapsulation is enabled and if the UDP destination port is not 500 or not configured.

To enable or disable UDP encapsulation and to configure UDP destination port:

1. Configure the global non-standard destination port. This is required to register or open-up the port for IPsec. You cannot assign port 500 and port 4500 as they bound to IPsec, by default.

   content_copy zoom_out_map

   [edit security ike]
   user@host> set packet-encapsulation dest-port dest-port

2. Enable packet encapsulation in IKE gateway.

   content_copy zoom_out_map

   [edit security ike  gateway gw1]
   user@host> set packet-encapsulation

3. Configure the UDP destination port to non-standard port.

   content_copy zoom_out_map

   [edit security ike  gateway gw1]
   user@host> set packet-encapsulation use-global-dest-port

Layer 3 VXLAN Traffic Encapsulation using Flexible Tunnel Interfaces (FTIs)

Junos OS supports VXLAN traffic over an IPsec tunnel using both FTIs and VTEP VXLANs. For more information see, Configuring Flexible Tunnel Interfaces and Understanding VXLANs.