| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
IPSec Encapsulating Security Payload (ESP) (Page 3 of 4) 2. Trailer Calculation and Placement The ESP Trailer is appended to the data to be encrypted. ESP then performs the encryption. The payload (TCP/UDP message or encapsulated IP datagram) and the ESP trailer are both encrypted, but the ESP Header is not. Note again that any other IP headers that appear between the ESP header and the payload are also encrypted. In IPv6 this can include a Destination Options extension header. Normally, the Next Header field would appear in the ESP header and would be used to link the ESP header to the header that comes after it. However, the Next Header field in ESP appears in the trailer and not the header, which makes the linking seem a bit strange in ESP. The method is the same as that used in AH and in IPv6 in general, with the Next Header and/or Protocol fields used to tie everything together. However, in ESP the Next Header field appears after the encrypted data, and so points back to one of the following: a Destination Options extension header (if present), a TCP/UDP header (in transport mode) or an IPv4/IPv6 header (in tunnel mode). This too is shown in Figure 124 and Figure 125. If the optional ESP authentication feature is used, the authentication field is computed over the entire ESP datagram (except the Authentication Data field itself, of course). This includes the ESP header, payload and trailer.
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||