ESP ( Encapsulated Security Payload )

• SPI, Security Parameters Index

32 bits. An arbitrary value that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the SA for this datagram. The set of SPI values in the range 1 through 255 are reserved for future use. A reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC . It is ordinarily selected by the destination system upon establishment of an SA. This field is mandatory. The value of zero is reserved for local, implementation- specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.


• Sequence number

32 bits, unsigned. This field contains a monotonically increasing counter value. It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of this field is at the discretion of the receiver. The sender MUST always transmit this field, but the receiver need not act upon it. The sender's counter and the receiver's counter are initialized to 0 when an SA is established. The first packet sent using a given SA will have a Sequence number of 1. If anti-replay is enabled (the default), the transmitted Sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA.


• Payload data

Variable length. Contains the data described by the Next header field. This field is mandatory and is an integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), then this data MAY be carried explicitly in the Payload data field. Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length, any structure for such data, and the location of this data as part of an RFC specifying how the algorithm is used with ESP. If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the RFC .


• Padding

Variable length, 0 to 255 bytes. Padding may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4 byte boundary. Specifically, the Pad length and Next header fields must be right aligned within a 4 byte word to ensure that the Authentication data field, if present, is aligned on a 4 byte boundary.


• Pad length

8 bits. The Pad Length field indicates the number of pad bytes immediately preceding it.


• Next header

8 bits. An IPv4/IPv6 protocol number describing the format of the Payload data field.


• Authentication data

Variable length. Contains an ICV computed over the ESP packet minus the Authentication data. The length of the field is specified by the authentication function selected. This field is optional, and is included only if the authentication service has been selected for the SA in question. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.

• IPv4


Before Applying ESP


orig IP hdr(any options)

TCP

Data


After Applying ESP


            -------------------------------------------------

            |orig IP hdr  | ESP |     |      |   ESP   | ESP|

            |(any options)| Hdr | TCP | Data | Trailer |Auth|

            -------------------------------------------------

                                |<----- encrypted ---->|

                          |<------ authenticated ----->|




• IPv6


Before Applying ESP


orig IP hdr

ext hdrs if present

TCP

Data



After Applying ESP


            ---------------------------------------------------------

            | orig |hop-by-hop,dest*,|   |dest|   |    | ESP   | ESP|

            |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth|

            ---------------------------------------------------------

                                         |<---- encrypted ---->|

                                     |<---- authenticated ---->|

• Reassembly

If required, reassembly is performed prior to ESP processing. If a packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the Flow ID.


• Security Association Lookup

Upon receipt of a (reassembled) packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (ESP), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will be checked, whether the Authentication Data field should be present, and it will specify the algorithms and keys to be employed for decryption and ICV computations (if applicable).


• Sequence Number Verification

All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.)


• Integrity Check Value Verification

If authentication has been selected, the receiver computes the ICV over the ESP packet minus the Authentication Data using the specified authentication algorithm and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below.

If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the cleartext Flow ID.

■ Parent layer
■ Child layer

IP

ESP