E.2.4 Tunnel Mode ESP
Here is an example of a packet with ESP applied:
Original Packet
IP Header
TCP
Data
Packet with IPSec Encapsulation Security Payload |
|
|
|
| |||||||||
|
|
|
|
|
|
|
|
|
|
|
|
| |
New IP Heade |
|
| ESP Header | Org IP Header | TCP |
|
| Data |
|
| ESP Trailer | ||
|
|
|
|
|
|
|
|
|
|
| |||
|
|
|
|
| encrypted |
|
|
|
|
| |||
|
|
|
|
|
|
|
|
|
|
| |||
|
|
|
|
| Authenticated |
|
|
|
|
|
ESP
Authentication
E.2.5 Internet Key Exchange (IKE)
Before either AH or ESP can be used, it is necessary for the two communication devices to exchange a secret key that the security protocols themselves will use. To do this, IPSec uses Internet Key Exchange (IKE) as a primary support protocol. IKE facilitates and automates the SA setup, and exchanges keys between parties transferring data. Using keys ensures that only the sender and receiver of a message can access it. These keys need to be
There are two phases to this process. Phase I deals with the negotiation and management of IKE and IPSec parameters. This phase can be carried out in either one of two modes: Main Mode or Aggressive Mode. Main mode utilizes three message pairs that negotiate IKE parameters, establish a shared secret and derive session keys, and exchange and provide identities, retroactively authenticating the information sent. This method is very secure, but when using the
176