Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
|
NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
|
|
|
|
IPSec Encapsulating Security Payload (ESP)
(Page 1 of 4)
The IPSec Authentication
Header (AH) provides integrity authentication
services to IPSec-capable devices, so they can verify that messages
are received intact from other devices. For many applications, however,
this is only one piece of the puzzle. We want to not only protect against
intermediate devices changing our datagrams, we want to protect against
them examining their contents as well. For this level of private communication,
AH is not enough; we need to use the Encapsulating Security Payload
(ESP) protocol.
The main job of ESP is to provide
the privacy we seek for IP datagrams by encrypting them. An encryption
algorithm combines the data in the datagram with a key to transform
it into an encrypted form. This is then repackaged using a special format
that we will see shortly, and transmitted to the destination, which
decrypts it using the same algorithm. ESP also supports its own authentication
scheme like that used in AH, or can be used in conjunction with AH.
Encapsulating Security Payload Fields
ESP has several fields that are the
same as those used in AH, but packages its fields in a very different
way. Instead of having just a header, it divides its fields into three
components:
- ESP Header: This contains two fields,
the SPI and Sequence Number, and comes before the encrypted
data. Its placement depends on whether ESP is used in transport mode
or tunnel mode, as explained in the
topic on IPSec modes.
- ESP Trailer: This section is placed
after the encrypted data. It contains padding that is used to align
the encrypted data, through a Padding and Pad Length field.
Interestingly, it also contains the Next Header field for ESP.
- ESP Authentication Data: This field
contains an Integrity Check Value (ICV), computed in a manner
similar to how the AH protocol works, for when ESP's optional authentication
feature is used.
There are two reasons why these fields
are broken into pieces like this. The first is that some encryption
algorithms require the data to be encrypted to have a certain block
size, and so padding must appear after the data and not before it. That's
why padding appears in the ESP Trailer. The second is that the ESP
Authentication Data appears separately because it is used to authenticate
the rest of the encrypted datagram after encryption.
This means it cannot appear in the ESP Header or ESP Trailer.
If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support! |
|
|
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.
|