IPsec Mode - 1.0 English

In IPsec mode, the HSC Subsystem processes data based on IETF RFC4106, RFC4303, RFC4543, and RFC8221. These RFC documents describe the use of AES in Galois/Counter Mode (in other words, GCM-AES) as an IPsec Encapsulating Security Payload (ESP) mechanism for confidentiality and data origin authentication. Some details from these RFCs are presented here to explain the functionality of the HSC Subsystem, however user familiarly with the IPsec protocol is assumed.

The HSC Subsystem supports the following IPsec-specific capabilities:

IPv4 and IPv6 protocols
IPsec Tunnel and Transport modes
Encapsulating Security Payload (ESP)
Confidentiality, integrity, replay protection and authentication (GCM-AES-ESP)
Integrity without confidentiality (AES-GMAC)
Both 32-bit Sequence Number and 64-bit Extended Sequence Number (ESN)

The HSC Subsystem supports only ESP and does not support Authentication Header (AH) or AH-ESP protocols for IPsec.

The HSC Subsystem does not process IP headers (other than the ESP header). For the encryption path, the user logic is required to remove any IP headers from the packet before presenting the payload to the HSC Subsystem. User logic is also required to re-insert the IP headers into the packet once it emerges from the HSC Subsystem. On the decryption path, any IP headers (other than the ESP header) must similarly be removed by the user logic before the packet enters the HSC Subsystem.

Note: For the encryption path, the HSC Subsystem can handle a minimum ESP payload size of 0 byte. This represents an IP packet which only includes IP header. On the decryption path, the minimum ESP packet that can be handled by the HSC Subsystem is 36 bytes. You must filter mis-constructed ESP packets which are smaller than 36 bytes before sending to the HSC Subsystem.

When encryption and authentication are enabled, the ESP packet contains both confidentiality-covered and integrity-protected fields. The following figure shows the format of the ESP packet in that case.

Figure 1. ESP Packet Format for 32-bit SN: Encryption with Authentication

The ESP header consists of the Security Parameter Index (SPI[31:0]) and Sequence Number (SN[31:0]). The SPI is an arbitrary 32-bit value that is used by a receiver to identify the Security Association (SA) to which an incoming packet is bound. The SN is an unsigned 32-bit field that contains the lower 32 of a counter value that increases by one for each packet sent, i.e., a per-SA packet sequence number. The SN is used at the receiver for replay protection. When an SA is established, the packet counter at the sender is set to 0 and is incremented for each packet. This means that the first packet sent using a given SA has a sequence number of 1. If replay protection is enabled, the transmitted sequence number must never be allowed to cycle. For example, when 32-bit sequence numbering is used, SA must be established prior to the transmission of 2³² packets.

The ESP payload begins with the Initialization Vector (IV[63:0]) and follows with a number (including 0) of remaining payload bytes. An optional Traffic Flow Confidentiality (TFC) Padding may be included to conceal the characteristics of certain traffic flows.

Note: The HSC Subsystem does not insert TFC padding bytes. If needed, user logic must add TFC padding bytes to the ESP payload before presenting it to the HSC Subsystem.

This is followed by the ESP trailer which includes Padding to ensure that the Integrity Check Value (ICV[127:0]) is aligned on a 4-byte boundary. The Pad Length (PadLength[7:0]) and Next Header (NextHeader[7:0]) fields are also part of the ESP trailer that precedes the ICV. On the encryption path, the HSC Subsystem supports a maximum of three Padding bytes. This is the minimum number of bytes required to ensure that ICV is aligned on a 4-byte boundary. On the decryption path, the HSC Subsystem can handle up to 16 Padding bytes.

On the encryption path, user logic is responsible for providing the SPI[31:0] on the enc_igr_prtif_macsec_sectag_ssci_p0 through enc_igr_prtif_macsec_sectag_ssci_p3 input ports. Likewise, the SN[31:0] is provided on enc_igr_prtif_crypto_pkt_num_p0 through enc_igr_prtif_crypto_pkt_num_p3 ports. The Salt[31:0] and ESP IV[63:0] are provided on the enc_igr_prtif_crypto_iv_salt_p0 through enc_igr_prtif_crypto_iv_salt_p3 input ports. All of these inputs are provided to the HSC Subsystem along at the beginning of the packet. The NextHeader[7:0] is provided on the enc_igr_prtif_macsec_sectag_shortlen_p0 through enc_igr_prtif_macsec_sectag_shortlen_p3 input ports which are not used for MACsec SecTAG when IPsec is enabled.

Note: When a packet is decrypted, if PadLength[7:0] is greater than 16, or PadLength is greater than the number of remaining ESP payload bytes, or ESP payload is not a multiple of four bytes, that packet is marked as error and the dec_egr_axis_tuser_err<M> signal corresponding to its EOP is asserted.

When HSC Subsystem encryption and authentication are enabled, ESP uses the GCM-AES-ESP algorithm. In the context of GCM-AES-ESP, the GCM-AES IV is called a nonce. It is defined as follows:

Nonce = {Salt[31:0], IV[63:0]}

The Additional Authenticated Data (AAD) is defined as:

AAD = {SPI[31:0], SN[31:0]}

The Plaintext is defined as:

Plaintext = { Rest Of Payload Data, TFC Padding, Padding, PadLength[7:0], Next Header[7:0] }

On the encryption path, the HSC Subsystem encrypts the Plaintext. It also creates gaps in the data stream and inserts the ESP header, ESP IV[63:0], ESP trailer, and ICV. As part of the ESP trailer, the HSC Subsystem calculates the required number of Padding bytes and sets the Pad Length field appropriately. Note that the ESP IV[63:0] value is not encrypted nor is it included in the ICV computation.

On the decryption path, user logic provides the SPI[31:0], SN[31:0], and IV[63:0] in-band on the AXI4-Stream interface data bus. The Salt[31:0] is provided on the enc_igr_prtif_crypto_iv_salt_p0 through enc_igr_prtif_crypto_iv_salt_p3 input ports at the beginning of the packet.

The HSC Subsystem extracts the ESP IV[63:0] from the packet, decrypts the Ciphertext, extracts the NextHeader[7:0] field from the packet, and places it on the dec_egr_prtif_ipsec_next_header_p0 through dec_egr_prtif_ipsec_next_header_p3 output ports as the last cycle of the packet emerges from the HSC Subsystem. The HSC Subsystem indicates whether the ICV check failed on the dec_egr_prtif_crypto_icv_chk_fail_p0 through dec_egr_prtif_crypto_icv_chk_fail_p3 ports. To protect against attacks, the HSC Subsystem decryption path implements a replay protection (anti-replay) mechanism. When replay protection is enabled, the HSC Subsystem maintains the lower and upper bounds of the anti-replay window as well as the corresponding bit sequence of the anti-replay window for each SA. Once the validation of the packet has been done by the Cipher Suite, HSC Subsystem performs the anti-replay check which may result in the packet being marked for discard.

Note: The HSC Subsystem only supports replay protection if the SA is stored internally. When the replay protection is enabled, the anti-replay window can be up to 128 packets for each internal SA.

A Cipher Suite specifies the cryptographic algorithms together with the values of parameters (for example, key size) to be used by those algorithms. The HSC Subsystem supports the IPsec Cipher Suites listed in the following table. This includes use of these Cipher Suites for authentication-only (integrity protection) as indicated by the enc_igr_prtif_crypto_auth_only_p0 through enc_igr_prtif_crypto_auth_only_p3 (dec_igr_prtif_crypto_auth_only_p0 through dec_igr_prtif_crypto_auth_only_p3) input ports.

Table 1. Supported IPsec Cipher Suites
Cipher Suite	prtif_crypto_suite[1:0]
GCM-AES-ESP-128	2'b00
GCM-AES-ESP-256	2'b01
GCM-AES-ESP-ESN-128	2'b10
GCM-AES-ESP-ESN-256	2'b11

Note: In the previous table, prtif_crypto_suite refers in the encryption path to enc_igr_prtif_crypto_cipher_suite_p0[1:0] through enc_igr_prtif_crypto_cipher_suite_p3[1:0] and in the decryption path to dec_igr_prtif_crypto_cipher_suite_p0[1:0] through dec_igr_prtif_crypto_cipher_suite_p3[1:0].

When encryption is disabled and authentication-only is enabled, the ESP packet contains only integrity-protected fields. This uses the AES Galois Message Authentication Code (GMAC). The following figure shows the format of the ESP packet in that case.

Figure 2. ESP Packet Format for 32-bit SN: Authentication-Only

When authentication-only is selected, ESP AES-GMAC sets the nonce as follows:

Nonce = {Salt[31:0], IV[63:0]}

The Additional Authenticated Data (AAD) is defined as:

AAD = {SPI[31:0], SN[31:0], IV[63:0], Rest Of Payload Data, TFC Padding, Padding, PadLength[7:0], Next Header[7:0] }

The Plaintext is defined as:

Plaintext = { }

Note: The ESP IV[63:0] is included in the ICV computation when encryption is disabled and authentication-only is enabled.

For high-speed IPsec applications, a 64-bit Sequence Number may be used. However, only the lower 32 bits of the SN are transmitted in the ESP header of each packet. The higher 32 bits are maintained as part of the SN counter by both transmitter and receiver and are included in the computation of the ICV.

When encryption and authentication are enabled the ESP packet contains both confidentiality-covered and integrity-protected fields. The following figure shows the format of the ESP packet when Extended Sequence Number (ESN) is enabled.

Figure 3. ESP Packet Format for 64-bit SN: Encryption + Authentication

When encryption and authentication are enabled and Extended Sequence Number (ESN) is enabled, the nonce is defined as:

Nonce = {Salt[31:0], IV[63:0]}

With ESN enabled, the Additional Authenticated Data (AAD) is defined as:

AAD = {SPI[31:0], SN[63:0]}

The Plaintext is defined as:

Plaintext = { Rest Of Payload Data, TFC Padding, Padding, PadLength[7:0], Next Header[7:0] }

When Extended Sequence Number (ESN) is enabled, user logic provides all bits of the SN[63:0] on enc_igr_prtif_crypto_pkt_num_p0 through enc_igr_prtif_crypto_pkt_num_p3 ports.

Note: The ESP IV[63:0] value is not encrypted nor is it included in the ICV computation. Also, note that the SN[63:31] bits are not transmitted with the ESP packet.

On the decryption path, the HSC Subsystem maintains the upper and lower bounds of the anti-replay window for each SA on the decryption path. This allows it to determine SN[63:32] for any packet that belongs to a Security Association (SA) that is stored internal to the HSC Subsystem. When ESN is selected and the frame belongs to an external SA, you are responsible for providing SN[63:32] on the dec_igr_prtif_crypto_icv_p0 through dec_igr_prtif_crypto_icv_p3 inputs (which are not used for ICV purposes for IPsec).

When the validation of the packet has been done, the HSC Subsystem performs an anti-replay check which may result in the packet being marked for discard.

Figure 4. ESP Packet Format for 64-bit SN: Authentication-Only

When authentication-only is selected and Extended Sequence Number (ESN) is enabled, ESP AES-GMAC sets the nonce as follows:

Nonce = {Salt[31:0], IV[63:0]}

With ESN enabled, the Additional Authenticated Data (AAD) is defined as:

AAD = {SPI[31:0], SN[63:0], IV[63:0], Rest Of Payload Data, TFC Padding, Padding, PadLength[7:0], Next Header[7:0] }

The Plaintext is defined as:

Plaintext = { }

Note: The ESP IV[63:0] is included in the ICV computation. Also, due to ESN, SN[63:32] is included in the ICV computation, but those bits are not transmitted on the encryption path or received on the decryption path.