ESP

RFC1826 http://www.cis.ohio-state.edu/htbin/rfc/rfc1826.html
RFC1827 http://www.cis.ohio-state.edu/htbin/rfc/rfc1827.html
This RFC has been replaced by RFC
2406.
The information on this page will be updated to suit the new
RFC in the near future.

The IP Encapsulating Security Payload (ESP)
seeks to provide confidentiality and integrity by encrypting
data to be protected and placing the encrypted data in the data
portion of the IP ESP. Depending on the user’s security requirements,
this mechanism may be used to encrypt either a transport-layer
segment (e.g., TCP, UDP, ICMP, IGMP) or an entire IP datagram.
Encapsulating the protected data is necessary to provide confidentiality
for the entire original datagram.

ESP may appear anywhere after the IP header
and before the final transport-layer protocol. The Internet
Assigned Numbers Authority has assigned Protocol Number 50 to
ESP. The header immediately preceding an ESP header will always
contain the value 50 in its Next Header (IPv6) or Protocol (IPv4)
field. ESP consists of an unencrypted header followed by encrypted
data. The encrypted data includes both the protected ESP header
fields and the protected user data, which is either an entire
IP datagram or an upper-layer protocol frame (e.g., TCP or UDP).

Security association identifier
The SPI is a 32-bit pseudo-random
value identifying the security association for this datagram.
If no security association has been established, the value of
the SPI field is 0×00000000. An SPI is similar to the SAID used
in other security protocols. The name has been changed because
the semantics used here are not exactly the same as those used
in other security protocols.

Popularity: -0% [?]