Encryption Path

IPsec_GW Reference Pipeline User Guide (UG1671)

Document ID
Release Date
1.1 English

Packet paths for encryption and decryption follow P4 Ingress to P4 Egress pipelines.

For the encryption path, where a packet comes in from an uplink un-encrypted, the P4 pipeline uses the crypto block between the P4I deparser and the packet buffer. The P4 pipeline can also be used for post-encryption/decryption operations (multi-service), such as packet rewrites, SDN policy offload, flow offloads, NAT, stateful firewall, observability, or additional flow lookup. See the following figure.

Figure 1. Packet Encryption

It is worth noting that Arm® cores are not in the path of the IPsec data path, unless desired. All IPsec functionalities can be implemented in P4 with an inline crypto engine, which provides near-line rate performance for the IPsec data plane. The current reference pipeline supports configuring static security associations (SAs) and using a custom control plane (strongSwan or other third party). The SSDK provides corresponding SA APIs, which customers can use to program the P4 SA table. The P4 pipeline can also be extended to support dynamic SA configuration (strongSwan or other third party vendors). This allows the SAs to be configured automatically based on the traffic flows in the network.

Below is the path taken in the P4 pipeline to perform IPsec encryption:

lif → p4i_init → nacl → tunnel_mapping → tunnel → ipsec_encrypt → inter_pipe → Egress
p4e_init → ipsec_action → nexthop → checksum → inter_pipe → Out

The following applies:

  • Because IPsec_GW is a stateless app, SA index required to encrypt the packet is derived from packet vlan-id.
  • The tunnel-mapping table entry contains the information about vlan-id -> tunnel-id mapping.
  • The tunnel table entry provides ipsec tunnel mode, encrypt sa-index, nexthop info, and so on.
  • Based on the sa index, the ipsec_info required for encryption is derived in the ipsec_encrypt table and it is passed to the deparser.
  • The P4I deparser sets the IPSec_info_valid bit, populates the IPSec_info, inserts a valid ESP header and trailer, and adds an empty ESP authentication trailer. The modified packet is sent to the inline IPsec engine.
  • The Inline IPsec engine encrypts the plain text payload and fills the ESP authentication trailer. The resultant packet is sent to the Packet Buffer.
  • The P4E Parser identifies the packet and parses the ESP header. The ipsec_post_encrypt table sets up esp iv header and UDP NAT (if enabled).
  • The Out uplink port and packet MAC address are derived in the nexthop table, and the packet is sent to the designated uplink port.