This service is free, however donations are welcome
Data Network Resource
       Earn on the Web

Home of a wide range of data and communications products!

IPsec


Background


Traditionally, remote working has been achieved by using private dial in networks consisting of remote users dialling in with modems across the PSTN or by using ISDN to connect with access servers that are situated at the organisation's central point. With the growth of the Internet until it is almost ubiquitous in its presence, technologies have been developed that allow users to connect to private networks across the public Internet. This is achieved via the use of Virtual Private Networks (VPN) (or Virtual Private Dialup Networks (VPDN)). A secure IP tunnel can be set up between the user and the central site. This tunnel looks like any other IP traffic on the public Internet using the public IP addresses, but contains encrypted IP conversations within the private IP address structure.

The 'umbrella' protocols used for these tunnels include Point-to-Point Tunnelling Protocol (PPTP) and the IPsec suite of protocols. These protocols have to deal with encrypting the data itself, hiding the private IP addresses, testing for authenticity and testing for reliability of the data i.e. its integrity. Other protocols used for specific tasks in VPNs include Secure Sockets Layer (SSL), Lightweight Directory Access Protocol (LDAP) (TCP 389) and RADIUS (UDP 1645) (RFC 2138).

Encryption


Encryption has its roots in mathematics and the history of encryption stretches back to the Greeks where the Greeks, when wanting to convey secret messages would shave their heads, write the message and allow the hair to grow back. The word 'encryption' comes from the Greek word 'crypto' meaning 'hidden'.

Encryption has been applied in many forms:
  • Transposition - rearranging text
  • Substitution - changing the text, code
  • Cipher - moving letters, a Crib is cipher text turned into plain text
  • Polyalphabetic - having many cipher alphabets for each message
  • Digraph - cipher of pairs of letters that are common
  • Nomenclature - substituting letters and words
  • One way pad - where a random key is used per sheet of a pad containing hundreds of sheets and both sender and receiver have the same pad.

Many of these techniques are being used in an extended fashion when encryting data in today's networks. Papers by Dr Horst Feistel (1970, DES), Diffie and Hellman (1976), Rivest, Shamir and Adleman (1977, RSA) and Zimmerman (1979, PGP) have formed the bedrock for encryption techniques used today. The basic idea is to encrypt data using an encryption key, send the ciphertext across a public domain and to decrypt the data using a decryption key.

You can have Symmetric encryption algorithms where the same key is used to encrypt and decrypt the data. These include DES, DES-3 (block ciphers), RC2, RC4, RC5 (stream ciphers), AES and Rijndael (up to 256 bits key length) and it can be fast, so it tends to be used for large volumes of data. The problems come when you want to share the key without compromising security. You can have Asymmetric encryption algorithms where the encryption keys and the decryption keys are different. Examples include RSA, Diffie Hellman and Elliptic Curves. Key lengths range from 512 bits to 2048 bits. Diffie Hellman is used specifically for key management. Asymmetric encryption algorithms are much slower and are therefore used for low volume encryption.

Key management is critical in the encryption environment, the security is only as good as its weakest point. It is no good sharing a key over the telephone or via E-mail if the conversation is prone to eavesdropping. Key management looks after the generation, storage, the exchange, verification and destruction of keys.

Random number generation is the basis of good key generation. Radioactive decay is one of the best sources of random numbers because the Keyspace (the number of possible keys) is very large. On average, you would have to search through half an algorithm's keyspace before finding the correct key. With symmetric algorithms, key lifetimes are typically short i.e. of the order of seconds or minutes, and 40/56 bit keys (e.g. DES) are now considered weak. 112/168 bit keys e.g. 3DES, are currently OK with 256 bit keys (e.g. AES) likely to be the norm in the future. With asymmetric algorithms 768/1024 bit keys are considered to be fine with a move towards 1536/2048 bit keys in the future. Asymmetric keys tend to last longer.

Data Encryption Standard (DES)


The DES algorithm takes a key and performs a series of simple logical operations on it. These include permutations, substitutions etc.. These operations are designed such that they can be implemented within hardware and therefore be fast.

A 64-bit block of plaintext is split into a left-hand 32-bit block and a right-hand 32-bit block. Of the 64 bits 56 bits are used for encryption and the remaining 8 bits are used for parity (7 x 0's and the LSB for even parity). You can get 40 bit encryption with DES where a 40 bit key is used along with 16 known bits. A section of the key called the subkey is then input into a function along with the right-hand block. The function expands the 32-bit block into 48-bits and adds the subkey. The function then performs a substitution via the S-Box and then a transposition via the P-box resulting in a 32-bit block again. The right-hand and left-hand blocks are swapped around and the whole operation repeated on the new right-hand block. This continues for 16 rounds in total until the ciphertext is produced.

DES can operate in Electronic Code Book (ECB) mode where a message of 5 x 64 bit blocks is operated on block by block. Or DES can operate in Cypher Block Chaining (CBC) mode where the output from DES operating on the first 64 bit block (of five) is fed into the algorithm along with the second block, and so on, the initial number to start off the chain is a random value called the Initialisation Vector (IV).

3DES


3DES is much stronger than DES because 2 or 3 keys are used to increase key strength. Two keys give 112 bits (2 x 56) encryption, and three keys give 168 bits (3 x 56) encryption. 3DES works by using the first key to encrypt the blocks just as in DES. Then the second key is used to decrypt the blocks, followed by the third key that encrypts the blocks again. If only two keys are being used for 112 bit encryption, then the first and third keys are the same.

IPsec Architecture


As the Internet matures so the need for more security grows. IPsec has been developed to address the needs for data security, integrity, authentication and protection. A series of RFCs covers the IPsec framework and are structured as follows:
The ISAKMP protocol uses TCP/UDP port 500.

Benefits


With layer 2 encryption techniques, devices at the end of each link need to be capable of encrypting the frames. IPsec operates at layer 3 and so only the devices at the end of the IPsec tunnel need to have encryption capability.

Other benefits are that QoS is able to be applied to IPsec datagrams, applications do not have to be concerned with the encryption technologies and IPsec can be managed centrally on the devices such as routers, firewalls and servers where IPsec is implemented.

IPsec cannot be used to secure multicast or broadcast traffic as 'group key distribution' does not yet exist.

IPsec is sometimes used to refer to the whole security services which includes IKE, and other times the term IPsec is used to just reference the data security services.

Concepts of IPsec


IPsec encapsulates the concepts of Confidentiality, Integrity, Origin Authentication and Anti-Replay.

Confidentiality


Data is made private via the use of encryption such as Data Encryption Standard (DES) (RFC 2405), 3DES, International Data Encryption Algorithm (IDEA) and Blowfish (RFC 2406).

The concept of Feasibility is used to describe the difficulty of cracking a particular encryption algorithm. In the world of encryption nothing is considered to be impossible, however an algorithm is considered infeasible if it is considered to be complex enough not to be solved with current computer technology or techniques in a reasonable amount of time.

There are two methods of distributing keys used in encrypting and de-encrypting the data, the Shared Key method and the Public Key method.

Shared Key


In a shared key environment e.g. for symmetric encryption or for HMACs, a single key is used for encryption and decryption of the data, therefore both peers need to know this shared key. The problem with this method is that there has to be a way of making sure both peers know this key without compromising the security of this key. Using the telephone or mailing the key is not really that secure, plus it is not scalable for large secure networks where there are many peer to peer sessions each with different keys. There needs to be a way of securing key exchange over an insecure path.

Diffie-Hellman Key Exchange addresses this problem and Internet Key Exchange (IKE) (RFC 2409) uses this Diffie-Hellman to ensure that a shared key can be generated and shared across a public connection in a way that is infeasible for anyone to work out the key. This shared key can then be used with an encryption algorithm such as DES, 3DES, IDEA etc. A summary of how Diffie-Hellman operates is as follows:
  1. Peers P and Peer Q have been given the same publicly viewable numbers m and n.
  2. Peer P picks a very large secret random number x and calculates mxmod n to give P.
  3. Peer Q picks a very large secret random number y and calculates mymod n to give Q.
  4. Peer P and Peer Q exchange P and Q publicly, so anyone can see these numbers. The numbers x and y remain known only to the relevant peer and they are not transmitted.
  5. Peer P then performs the calculation Qxmod n to give the value K.
  6. Peer Q then performs the calculation Pymod n to give the value L.
  7. Now as it happens, Qxmod n gives the same value as mxymod n which is the same as Pymod n, so K and L are equal, therefore Peers P and Q have negotiated a shared secret that has not been transmitted.
The modulus arithmetic makes it very difficult for an attacker to find a value for either x or y especially if the numbers involved are very large. Calculating PBase m for instance, is not trivial when modulus is involved with large numbers. Instead an attacker will attempt to intercept the exchange and become an intermediary between the peers and negotiate two shared secrets with each of the peers and fool them into thinking that they are talking with each other.

Public Key Encryption


Each peer creates two keys, one private and one public. The public key is made available publicly and is used to encrypt data by anyone wishing to send you information. The private key is used by the receiver to decrypt the data. In a large secure environment, public keys are held in central locations for better management. It is considered infeasible to work out the private key from the public key.

Using a public/private key method to encrypt data is around 1000 times slower than using the shared key method, so the shared key method is good for large data volumes.

A popular public key encryption algorithm is Rivest, Shamir and Adleman (RSA) and is used in IKE. Key lengths can vary between 512 bits to 2048 bits.

The following is a list of Public Key Cryptography Standards (PKCS):
  • PKCS #1 Encryption that defines RSA DSS
  • PKCS #2 (ditto)
  • PKCS #3 (ditto)
  • PKCS #3 Diffie-Hellman Key Agreement (defines implementation)
  • PKCS #5 Password-Based Encryption (how to encrypt derived password)
  • PKCS #6 Extended Certificate Syntax (Extension Attributes, X.509v2)
  • PKCS #7 Cryptographic Message Syntax (Placement of Attributes)
  • PKCS #8 Private key Information Syntax (Placement of Keys)
  • PKCS #9 Selected Attribute Types (All Attribute types used in PKCS)
  • PKCS #10 Certificate Request Syntax (CMP)
  • PKCS #11 Cryptographic Token Interface (API, Cryptoki)
  • PKCS #12 Key Movement Exchange Syntax (Portable format of Keys)
  • PKCS #13 Elliptic Curve Cryptography
  • PKCS #14 Pseudo-Random Number Generation
  • PKCS #15 Cryptographic Token Information Syntax

Integrity


A check that ensures data has not been changed during transfer. This uses a unique hash value that acts like a fingerprint. This hash is calculated by the sender each time any data is sent, it is also calculated when received and the two values compared. MD5 hashing is used often here.

The two peers agree a hashing algorithm and use this to input the data and the shared key that they have agreed. This produces a hash value which is sent with the data. This hash value is one-way only, it is not like encryption where the resultant form can be decrypted! The receiving peer peforms the same hashing operation using the data and the shared key and if the hash value is the same the data is considered to be reliable. Using a shared key that is inputted into the hashing algorithm is called Keyed-Hashing for Message Authentication or Hash Message Authentication Code (HMAC) as detailed in RFC 2104. An HMAC combines hashing with authentication.

One of the most popular hashing algorithms, or HMACs, used today is Message Digest 5 (MD5). Whatever the size of the input data, the output has is always a 128-bit hashed value, even if the data is merely one character. If two very similar pieces of data are sent, the has values for each will be utterly different so that no pattern can be deduced, there is an avalanche effect, if the data changes a little, the digest changes alot.

The National Institute of Standards and Technology (NIST) designed another hashing algorithm called Secure Hash Algorithm (SHA-1) which is often used as well and produces a 160 bit hash.

Origin Authentication and Certification Authorities (CA)


The infrastructure that encompasses public key management is called the Public Key Infrastructure (PKI) and is explained in RFC 2510 and is to do with identifying the users rather than authenticating them. PKI servers called Certification Authority (CA) and Registration Authority (RA) servers form centres of trust for the users.

Certification Authority (CA)


We need to ensure that the public keys being used are genuinely from the sender i.e. that they are not being falsely produced by an intruder (Trust), and conversely the sender cannot get away with denying that the message came from them (Nonrepudiation). Origin authentication is about checking that the station with whom you are communicating is who they say they are. This stage uses Digital Signatures and the concept of a Certification Authority (CA) that assigns these digital signatures.

Typical well-known CAs used by e-commerce include the following:
  • VeriSign®
  • Entrust®
  • Netscape® iPlanet
  • Windows® 2000 Certificate Server
  • Thawte®
  • Equifax
  • Genuity
When a device (the subject) creates the private and public keys, the public key is sent along with the device details to the CA server and these are processed in a personal fashion so that they can be verified as genuine. Of course, this personal verification has to be very good for the CA to have credence. The CA is a trusted third party that hold the public keys, plus the CA produces a Digital Certificate that contains the sender's name (the subject), details such as serial numbers etc. and their public key. The X.509 standard for the certificate is that which the CA adheres to and gives you confidence that if that CA issues you somebody's public key, that the CA has verified that that certficate belongs to that somebody. X.509 is at version 3 i.e. X.509v3 and produces the certificate in one of three file formats:
  • Distinguished Encoding Rules (DER-encoded X509 certificate) - Binary format encoding of the certificate file in ASN.1. For example, an imported certificate from a Microsoft Windows NT IIS 4.0 server.
  • Privacy Enhanced Mail (PEM) - a base64 encoding of the certificate file (PEM-encoded X509 certificate). For example, an imported certificate from an Apache/SSL UNIX server.
  • PKCS12 - Standard from RSA Data Security, Inc. for storing certificates and private keys. For example, an imported certificate from a Microsoft Windows 2000 IIS 5.0 server.
The certificate contains the following:

  1. Serial number of subject device
  2. Issuer (CA) X500 name
  3. Valid period so that there is an expiration time
  4. Subject X500 name
  5. Subject public key
  6. Key and certificate usage
  7. Any extensions
  8. CA Digital Signature, either via RSA or DSA.
The CA uses its own private key with the first five components to produce the CA digital signature.

Once the certificate has been created, this can be downloaded from the CA in whatever format is suitable for the subject device, and stored and distributed by the owner. As described above, the certificate contains details about the owner, details about the certificate issuer, the owner's public key, validity, expiration dates, and associated privileges.

The CA digitally signs this certificate with its own private key, so that the subject device can then send this certificate to those that want its public key. Digital Signature Standard (DSS) with its Digital Signature Algortihm (DSA) and RSA Signatures are examples of algorithms used with digital signatures on the CAs. DSS was established to provide an alternative to RSA when signing certificates, this was because RSA is already use within the PKI for key exchange and it was felt a good idea to have a separate algorithm for digital signatures. As a consequence, DSS/DSA is purely used for signing certificates. Using the PKI public key cryptography, the CA keeps a private key and publishes a public key. The private key is used to encrypt the data. The receiver uses the CA's public key to decrypt the data and thereby verify it (note that this is the opposite to the earlier use of the public key to encrypt data!).

CA Servers are used to store these digital certificates and are publicly accessible. Those receiving data with the certificate need to obtain the CA's public key in order to verify the CA's signature and check that no alterations have occurred. Certification Authorities have Root CA Certificates. These root CA certificates are installed in releases of all the major web browsers such as Internet Explorer, Netscape, Opera, etc. When you use your browser you are automatically relying on a collection of root CA certificates that the browser vendor has deemed you can trust. If an SSL certificate is issued by one of the trusted root CAs to a subject device/server, then you will inherently trust that SSL certificate and the gold padlock will appear transparently during secure sessions. This eliminates the need for clients to have to go on to the Internet to obtain the CA's public key (particularly useful if the clients sit behind a firewall that denies them access to the Internet).

If the root certificate is not installed on the client's browser then the client will see a warning indicating the requirement to download a certificate because the browser does not have a certificate from the CA used to issue the device's certificate.

CA Warning

The clients and servers communicating with each other must have certificates digitally signed from the same CA or from the hierarchy of CAs that trust each other. A certificate is verified when the client checks it with the CA using the CA's public key within the PKI. Once verified, the client can trust the public key within the certificate for the server/subject device to which it wants to connect. The users trust the CA to distribute, revoke, and manage keys and certificates in such a way as to prevent any security breaches. Users need to be able to determine the degree of trust that can be placed in the authenticity and integrity of the public keys contained in the certificates. The information upon which such determinations can be made is documented in the Certificate Policy and the Certification Practice Statement of the CA.

In summary, the CA performs the following tasks:
  • Issues users with keys/Packet Switching Exchanges (PSEs) (though sometimes users may generate their own key pair, private and public keys)
  • Certifies users' public keys
  • Publishes users' certificates
  • Issues Certificate Revocation Lists (CRLs)
  • Generate the certificate based on a public key. Typically a Trust Center (SSL server or other SSL termination device offering content) generates the pair of keys on a smart card or a USB token or within the server itself.
  • Guarantees the uniqueness of the pair of keys and links the certificate to a particular user
  • Manages published certificates
  • Is part of cross certification with other trusted CAs in a hierarchy
Sometimes, the tasks of Certification and Registration are separated out and are carried out by different servers (Note: Entrust and Verisign do not do this!). Some CA servers use Lightweight Directory Access Protocol (LDAP) for certificate retrieval.

Registration Authority (RA)


The Registration Authority (RA) is responsible for recording and verifying all information the CA needs. In particular, the RA must check the user's identity to initiate issuing the certificate at the CA. This functionality is neither a network entity nor is it acting online. The RAs will be where users must go to apply for a certificate. A RA has two main functions:
  • Verify the identity and the statements of the claimant
  • Issue and handle the certificate for the claimant

Certificate Revocation List (CRL)


A CRL is a digitally signed list of revoked certificates that is issued by the CA. This list is updated on a scheduled basis and distributed to relying parties. Certificates have expiry times assigned to them and also some certificates become out of date due to device or personnel changes within an organisation. The CRL provides a means of revoking previously issued certificates. The older a certificate is, the more likely it is to be cracked, so it is good practice to renew certificates regularly.

Due to the latency involved in publishing a CRL, a relying party may not receive notification of a revoked certificate in time. On-line mechanisms may be used to communicate the current status of a certificate. A widely used standard for determining the on-line status of a certificate is the IETF Internet X.509 Internet Public Key Infrastructure Online Certificate Status Protocol (OCSP) (RFC 2560).

Some CAs operate a Certificate Revocation List (CRL) which is a list of certificates that have been revoked, e.g. because they have expired. The peers downloads this CRL and uses it as an added check to see if the other peer's certificate is still valid. CRLv2 has the following format:
  1. CRL Issuer
  2. This Update
  3. Next Update
  4. User Certificate serial number
  5. Date of Revocation
  6. User Certificate serial number
  7. Date of Revocation
  8. Reason for Revocation
  9. Digital certificate of CA that issued the CRL
The CRL issuer's digital certificate is generated from the first item down to the last listed user revoked plus the CRL issuer's private key.

Anti-Replay


Sequence numbers and authentication is used to ensure that duplicate packets and old packets are rejected. This prevents an intruder copying a conversation and using it to work out encryption algorithms.

Internet Key Exchange (IKE)


IKE is a hybrid protocol that uses SKEME and Oakley key exchanges inside a framework of ISAKMP and it can be used with protocols other than IPsec. When traffic wishes to use a tunnel then an IKE SA is set up before the data SAs (normally IPsec SAs) are set up. IKE provides authentication of the IPSec peers, negotiates IPSec Security Associations (SA), and establishes IPSec keys.

IKE uses UDP port 500 and is defined in RFC 2409 and is based on three key management protocols:
  • Internet Security Association and Key Management Protocol (ISAKMP) defined in RFC 2408.
  • Oakley key exchange, defined in RFC 2412
  • Secure Key Exchange Mechanism (SKEME)
IKE provides the following benefits when used with IPsec:
  • Dynamic SA establishment
  • Dynamic rekeying so that keys can be expired and recreated thereby reducing the chance of an attacker gaining advantage if they have managed to crack one key.
  • Protection from Replay attacks
  • Operation with CA servers.
  • Perfect Forward Secrecy (PFS) which ensures that keys are not derived from other keys, therefore each key is as difficult to crack as another key because they are not dependent on each other in any way.
When IKE is used a special SA is set up between peers that is bi-directional and is used for management i.e. negotiating IPsec SAs and exchanging keys. The IKE SA can be set up in one of two ways, Main Mode or Aggressive Mode. In Main Mode, the IKE SA is set up in the following manner:
  1. The initiating station sends transform(s) and a cookie that is a hash of the following items:
    • Destination IP address
    • Source IP address
    • Destination port
    • Source port
    • Nonce - a randomly generated number that the initiator sends. This nonce is hashed along with the other items using the agreed key and is sent back. The initiator checks the cookie including the nonce, and rejects any messages which do not have the right nonce. This helps prevent replay since no third party can predict what the randomly generated nonce is going to be.
    • Date
    • Time
  2. The responding station replies with the accepted transform plus the inititial cookie and its own cookie containing the same items as above but from the responding station's point of view.
  3. The initiating station then sends its own cookie, the respondent's cookie, its public key, its ID and its nonce which has been encrypted with the respondent's public key. The ID consists of the following:
    • IP address
    • DNS name
    • User name
    • IP address range
    • X500 name
    • X.509v3 certificate
  4. The respondent sends its own cookie, the initiator's cookie, its public key, its own ID and its nonce which has been encryted with the initiator's public key.
  5. The initiator then sends its own ID, the ID of the respondent, its own nonce, the respondent's nonce which has been encrypted with the respondent's public key and a value hashed with its own private key.
  6. Finally, the respondent replies with the ID of the initiator, its own ID, its own nonce encrypted with the initiator's public key and a value hashed with its own private key.
In Aggressive Mode, the IKE is set up as follows:
  1. The initiator sends its own cookie and the requested transforms, both of which are encrypted with its own private key. Plus the initiator sends its own ID, its nonce, the ID of the respondent and a value that is hashed with its own private key.
  2. The respondent then sends its own cookie, the initiator's cookie and the accepted transforms, all of which are encrypted with its own private key. Plus it sends its own ID, its nonce, the initiator's nonce, the initiator's ID and a value that is hashed with its own private key.
  3. Finally, the initiator replies with its cookie, an acknowledgement of the agreed transforms, all of which being encrypted with its own private key. Plus, the initiator sends its own ID, the respondent's ID, its nonce, the respondent's nonce, and a value that is hashed with its own private key.
IKE uses a keepalive to check that peers at each end are still up. The default timer is 600 seconds. If a keepalive does not receive a reply then 5 attempts are made at 2 second intervals. If there is still no reply, then the IKE SA is torn down along with any IPsec SAs that may be in place. New traffic will start negotiations again. There can be an issue with IKE if there is more than one path to a peer e.g. two pairs of routers. The IKE SA is set up between two routers on one of the paths. If one router should fail then although IP routing may be OK, a new IKE SA will not be set up until the old SA has timed out. The trick is to run the SA over the new path, HSRP/VRRP can help with this.

Operation of IPsec


IPsec uses the concept of point-to-point peers. These peers share Transform Sets with each other during the Security Association negotiation process, and these Transform Sets determine the character of the IPsec session that they share. A Transform Set consists of the following information:
  • The IPsec security protocol (AH or ESP)
  • Integrity/Authority algorithm (MD5, SHA-1)
  • Encryption Algorithm (DES, 3-DES), although strictly speaking, you do not have to use an encryption algorithm.
Peers may be from different manufacturers, so they use this negotiation process to work out the lowest common denominator with regards to the features that the peers have been configured to use. Bear in mind that these transform sets are configurable and operate on a session by session basis and they do not necessarily represent the full capabilities of the device. You may for instance configure a different transform set for one connection compared to a transform set for another connection.

Negotiation of the IPsec SAs occurs in Quick Mode and operates as follows:
  1. The initiator sends an SA offer with a nonce which has been encrypted with the respondent's public key and a value that has been hashed with its own private key.
  2. The respondent then sends an SA accepted message along with its own nonce which has been encrypted with the initiator's public key, and a value that has been hashed with its own private key.
  3. Finally, the initiator hashes its own nonce and the respondent's nonce with its own private key.
Once the lowest common denominator of features has been successfully established two uni-directional Security Associations (SA) are set up between the peers. An SA is a uni-directional logical tunnel between the peers that protects data using the features listed in the transform set. An SA contains the following information:
  • IP address
  • Security Protocol
  • Encryption algorithm
  • Key
  • Traffic flow description e.g. port numbers etc.
  • A 32-bit Security Parameter Index (SPI) that, along with the peer's IP address, identifies the SA. If you use IKE, then this is a randomly generated number.
  • Timers and counters that identify the lifetime of the SA. Using IKE with IPsec allows the SA to be refreshed.
  • 64-bit Sequence numbers that are used to detect Replay attacks.
There can be multiple SAs per peer pair and they can be manually set up or dynamically created via IKE. There are two types of SA:
  • Transport Mode SA - this operates between hosts and is not very secure because the original source and destination IP addresses are readable, i.e. the hosts do their own AH encapsulation of their data. A risk exists because the IPsec header sits within the original IP header. This allows an attacker to make intelligent guesses as to where servers are on a network (busiest IP addresses) and begin to build a picture of the network.
  • Tunnel Mode SA - this operates normally between routers/firewalls or router to host and are used in the VPN environment. These are often called Security Gateways or IPsec Gateways because the gateways are providing AH/ESP services to other hosts. This type of SA is more secure because a new IP header unrelated to the hosts using the tunnel, is created around the IPsec datagram. The original IP header is included within the encrypted IPsec datagram and so the originating devices addresses are hidden.
There are in fact two IPsec security services that are used for SAs and they operate in Transport or Tunnel mode. One is called Authentication Header (AH) and the other is called Encapsulated Security Payload (ESP).

Authentication Header (AH)


Authentication Header (AH) (RFC 2402) gives you integrity and authentication using HMACs such as MD5 and SHA-1. AH checks the integrity of the whole IP datagram including the IP header itself, it then adds an extra header containing the authenticated data (keyed digest of the whole datagram) within the existing IP datagram and uses the IP protocol number 51. AH checks for authentication, integrity and replay. AH is built into IPv6!

Because AH hashes on everything in the datagram including the destination and source IP addresses, you cannot use AH when you are using NAT because NAT changes the IP addresses after AH has done its bit so when the receiver does the AH hash, the value of the hash changes and therefore the packet is not authenticated.

Encapsulated Security Payload (ESP)


Encapsulated Security Payload (ESP) (RFC 2406) provides confidentiality in addition to integrity and authentication, however it does not check the integrity of the IP header ESP hashes on the payload only, so that integrity is checked on the payload only (thereby saving CPU time). ESP use IP protocol number 50.

When ESP is used in conjunction with NAT, NAT can change the IP addresses however NAT also modifies the checksum when it does this. The checksum is part of what ESP hashes on so authentication at the other end will fail. If NAT does NOT modify the checksum after changing the IP address, then TCP/UDP verificaton will fail. In this situation you have to find a way for the peers to ignore the checksums of the packets! As it happens ESP in combination with Tunnel Mode provides a solution because the checksum is ignored.

Some transform sets are set up to use both AH and ESP so that the benefits of both services can be realised. If a transform set specifies both AH and ESP then two pairs of uni-directional SAs will be set up because you cannot implement both AH and ESP on one SA. This is important when you are using certain IP protocols such as OSPF which uses a different IP protocol number (i.e. 89), the two protocols cannot therefore exist side by side, this is why IPsec cannot support broadcast and multicast traffic directly, routing protocols rely on broadcasts, so does DHCP/Bootp. The IP helper can be used to deal with DHCP requests and setting up an IP tunnel (using GRE) within the IPsec tunnel is a way around sending broadcast/multicast information through the IPsec tunnel.

Overview of IPsec and IKE operating together


Where IPsec and IKE are in operation a typical example of the steps involved could look like this:
  1. Peer P detects that traffic wishes to use an IPsec tunnel to peer Q.
  2. Peer P initiates an IKE SA with peer Q.
  3. A transform set is issued by peer P for the IKE SA
  4. A transform set is issued by peer Q for the IKE SA
  5. On agreement of the transform set, peer P sends their digital certificate across the IKE SA
  6. Peer Q sends their digital certificate across the same bi-directional IKE SA.
  7. Peer P and Peer Q then exchange Diffie-hellman numbers that are digitally signed so that they can establish a shared key that they can be confident genuinely comes from the other peer.
  8. Peers P and Q verify each other's signature using each other's public key.
  9. The shared key is calculated using the Diffie-Hellman numbers.
  10. The IKE SA is now established
  11. Peer P sends a transform set on the IKE SA.
  12. Peer Q sends a transform set on the IKE SA and peers P and Q decide the lowest common set.
  13. Peer P now initiates a uni-directional IPsec SA for data transfer
  14. If Peer Q needs to send data then peer Q initiates its own uni-directional IPsec SA.
  15. The Diffie-Hellman key exchange is used again for P and Q to negotiate a shared key, because IKE is being used, the shared key derived at this stage is totally independent of the IKE shared key.
  16. Data is now sent over the IPsec SAs.
  17. As the IPsec SAs near expiration as defined by their timers, IKE creates new IPsec SAs and data transfer continues seamlessly.
Home

Valid HTML 4.01 Transitional

Disclaimer



IntroDelta     Earn on the Web    


All rights reserved. All trademarks, logos, and copyrights are property of their respective owners.