|IPSec Suite - How IPSec works|
|Written by Administrator|
|Sunday, 30 September 2001 08:48|
Page 2 of 4
How IPSec embeds encryption in the ESP
IPSec handles the encryption at the packet level. The protocol it uses is called ESP. ESP also offers some Authentication as in the AH but the ESP authentication doesn’t authenticate the new IP header in front of the packet – in contrast to AH. The ESP (see below) follows the standard IP header in a IP datagram. It contains all the data and the higher level protocols relying on IP for routing. The figure below does not show the IP header.
The ESP contains six parts. The first two parts are not encrypted but are authenticated.
For the authentication field, see "Authentication within ESP"
The ESP header is added after a standard IP header. The IP header specifies in the next header field with a certain number that an ESP header will follow (instead of a TCP header). Every standard IP router can forward this packet because it uses a standard IP header.
Encryption algorithms supported by ESP
ESP can support any number of encryption algorithms. It is up to the user which algorithm to use. You can even use different protocols for each party with whom you are communicating.
Tunneling with the ESP
Tunneling takes the original IP packet (with header) and encapsulates it in the payload of the ESP. It then adds to the packet a new IP header with a destination address of a VPN gateway.
Tunneling allows you to pass illegal IP addresses trough a public network (the Internet for example).
Note: Keep in mind that the tunneling mode generates more overhead as opposed to the transport mode because transport mode doesn’t need a new IP header. Transport mode, therefore, cannot be used with private IP addresses over a public network.
Another advantage of tunneling is, that the original source and destination addresses are hidden from users on the public network. This defeats or at least reduces the power of traffic analyses attacks. An attacker doing traffic analyses doesn’t know what is being said, but does know how much is being said.
Authentication within the ESP
The authentication field in the ESP contains something called an ICV (Integrity Check Value). In other words, this is a digital signature computed over the ESP minus the authentication field itself. It may also be omitted entirely if the authentication field isn’t checked for use or if you want to use the Authentication Header (AH).
The ICV is calculated on the ESP once encryption is complete. The source encrypts a hash of the data payload and attaches this value as the authentication data. The recipient confirms that there has been no tampering and that the payload did come from the expected person.
AH - Authentication Header
AH provides authentication without confidentiality. The IPSec suite’s second protocol, the AH, provides authentication services but does not address confidentiality. The AH may be applied alone, in concert with the ESP or in a nested fashion when using tunnel mode.
Like the ESP, the AH can be used to implement tunneling mode. Also, as in the ESP, IPSec requires specific algorithms to be available for implementing in the AH. All IPSec implementations must support at least HMAC-MD5 and HMAC-SHA-1 for a minimum interoperability. HMAC is a symmetric authentication scheme supported by MD5 and SHA-1 hashes.
AH and ESP – two parts in the puzzle
You can name the AH and ESP to be as the building blocks of the IPSec suite. These two protocols provide such important services as authentication, confidentiality and integrity.All the services mentioned above rely on a secure key exchange. The encryption services provided by the ESP and AH represent a powerful technology to keep your data secret, for verifying its origin, and for protecting it from undetected tampering. But they mean little without a wisely designed infrastructure to support them, to distribute keys, and to negotiate security parameters between communicating parties.
So, the next part of this document discusses the key distribution service in IPSec, provided by the IKE protocol.
How many keys do you need?
Imagine twenty people need to exchange data on a secure way. They want to talk to each other on a secure and safely way trough the public network.
Obviously, this is not practical. The first thing we can do in that situation is to change from symmetric to asymmetric encryption. With asymmetric encryption, each person issues a public key to all the others. Every user has his own private/public key pair – so every user needs to remember twenty keys (nineteen public, plus the own private key). Key exchanging in this example is much more easily compared to the first example – still complicated, but getting easier.
The above example illustrates two important things:
So just because a system says it does encryption, that alone doesn’t mean that it is going to be appropriate for your needs. Any proposed VPN solution is only as good as it’s method of key distribution.
|Last Updated on Monday, 11 June 2012 10:56|