IPsec Framework

IPSEC, short for IP Security, is a suite of protocols, standards, and algorithms to secure traffic over an untrusted network, such as the Internet. IPSEC is supported on both Cisco IOS devices and PIX Firewalls.
IPsec is not a single protocol, but a framework for securing IP communications.

IPsec Overview

• We can add IPsec to IPv4 or IPv6 by using additional headers.
• IPsec can then both encrypt and authenticate each IP packet of a session between hosts on a LAN or across the internet.
• If we look at security tools in the TCP/IP stack, we see that IPsec provides security at the network layer and can protect a much wider range of application than SSL.

IPsec has four main components:

• Security protocols:
• The security protocols include the Authentication Header (AH). Now this provides support for data integrity and authentication of IP packets.
• And the Encapsulating Security Payload (ESP) provides a combination encryption and authentication of IP packets.
• Key Management:
• Key management can either use manual, which is practical for small static environments, or automated using the Internet Key Exchange (IKE) in an enterprise network.
• Security Associations:
• Security Associations is a relationship between two entities and describes the components for the entities including the security protocols, algorithms, and keys required for the services requested for either the Encapsulating Security Payload protocol or the Authentication Header process.
• Algorithms:
• Now, within the security association, you see several different algorithms.
• Algorithms are essential in providing the following: Key exchange, integrity, encryption, and authentication.

IPsec Benefits

• IPsec provides flexibility in how it’s set up and what level of security is required.
• IPsec can protect one or more paths that include host to host, gateway to gateway, and outside host to the gateway.
• Services IPsec can provide include access control, integrity, authentication, preventing replay attacks, and confidentiality.
• IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services.
• IPsec can be used to protect one or more "paths" between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.

IPsec Framework

• On the left-hand side, we see the encapsulating security payload protocol which includes encryption algorithms such as AES cipher-block chaining mode.
• On the right, we see the authentication header protocol, which includes authentication algorithms such as SHA-256.
• And because cryptographic techniques and algorithms rely on keys, encompassing all of this thing is key management.

IPsec is an internet exchange taskforce standard that outlines how we can configure a VPN to secure traffic across an insecure network.
Because IPsec works at the network layer, it can then protect upper layer traffic.

The IPSEC standard is outlined in RFC 2401.

IPsec services

IPsec provides many services. IPSEC provides below four core services:

• Confidentiality – prevents the theft of data, using encryption. By encrypting our data, nobody except the sender and receiver will be able to read our data.
• Integrity – ensures that data is not tampered or altered, using a hashing algorithm. We want to make sure that nobody changes the data in our packets. By calculating a hash value, the sender and receiver will be able to check if changes have been made to the packet.
• Authentication – confirms the identity of the host sending data, using pre-shared keys or a Certificate Authority (CA). The sender and receiver will authenticate each other to make sure that we are really talking with the device we intend to.
• Anti-replay – prevents duplication of encrypted packets, by assigning a unique sequencing number. Even if a packet is encrypted and authenticated, an attacker could try to capture these packets and send them again. By using sequence numbers, IPsec will not transmit any duplicate packets.

It provides:

• Confidentiality using encryption
• Integrity using hash algorithms
• Authentication using key exchange
• Secure key exchange using Diffie-Hellman.

Confidentiality and Encryption

Data sent in clear text across the Internet can easily be intercepted and stolen. Because of this, sensitive data should be encrypted when sent across an untrusted network or domain. Keys are generated values used to both encrypt and decrypt data. The longer the key, the more secure that key is. The length of a key is measured in bits.

Two types of keys exist:

• Symmetric keys can be used to both encrypt and decrypt data. More specifically, the same key is used to both encrypt a packet (at the sending device) and then decrypt that packet (at the receiving device). 
• Symmetric key encryption is efficient but does not scale well in large environments.
• Symmetric keys are not openly shared during data transmit and must instead be installed on each machine prior to the transfer of data. 
• This can be accomplished using a variety of (inefficient and insecure) methods: email, sneaker-net, and even snail-mail. 
• Each device on a network would require every other device’s symmetric key, and thus the lack of scalability.
• Asymmetric keys require a separate key for encryption (the public key) and decryption (the private key). 
• Public keys are openly exchanged between devices to encrypt data during transfer. 
• Private keys are never exchanged. Only the private keys can decrypt the data.
• Thus, even if the data and the public keys were intercepted, confidentiality is ensured.

Diffie-Hellman (D-H) Public Key Exchange is the most common standard used to create and exchange keys across insecure mediums. D-H is not used to encrypt data, but rather to generate the keys that are used to encrypt and decrypt data.
A variety of popular standards and protocols utilize D-H key exchange, including SSL (Secure Socket Layer), SSH (Secure Shell), and IPSEC.
The generated public keys encrypt data payload using one of several available encryption algorithms:

• DES (Data Encryption Standard) – 56-bit key
• 3DES (Triple Data Encryption Standard) – 168-bit key
• AES (Advanced Encryption Standard) - 128, 192, or 256-bit key
• Blowfish – up to a 448-bit key

Additionally, the strength of a key is determined by the D-H group used to generate that key. There are several D-H groups:

• Group 1 – 768 bits
• Group 2 – 1024 bits
• Group 5 – 2048 bits

Data Integrity and Hashing

Data sent across the Internet can not only be stolen but can also be maliciously altered.
To combat this, a hashing algorithm computes and appends a specific hash value as each packet is sent. Once the data is received, it is run through the hashing algorithm again. If the hash value is different, the packet was altered in transit.
Hashed Message Authentication Code (HMAC) is used to perform this hashing function. HMAC utilizes a secret key when computing the hash value, thus preventing an attacker from altering the packet and then recomputing the correct hash.
Two HMAC algorithms are commonly used:

• HMAC-MD5 (Message-Digest 5) – 128-bit hashed key
• HMAC-SHA1 (Secure Hash Algorithm) – 160-bit hashed key

Authentication using key exchange

Another concern when sending data across the Internet is the source or origin of that data. 

It is possible to masquerade or spoof one’s identity or address.
For an IPSEC VPN tunnel to be established, both sides of the tunnel must be authenticated. 
To accomplish this, either pre-shared keys or RSA digital signatures are used.

• When using pre-shared keys, a secret string of text is used on each device to authenticate each other. This string must be pre-agreed upon and identical on each device. This string is then hashed into a digital signature.
• When using RSA Digital signatures, a Certificate Authority (CA) is used to apply a verified digital signature. 

One of the above options must be correctly configured before the VPN tunnel will become active.

Certificate Authorities

Remember, two methods exist to authenticate an IPSEC tunnel:

• When using pre-shared keys, a secret string of text is used on each device to authenticate each other. This string must be pre-agreed upon and identical on each device. This string is then hashed into a digital signature.
• When using RSA Digital signatures, a Certificate Authority (CA) is used to apply a verified digital signature. This provides a more scalable solution than pre-shared keys.

The certificate process works as follows:

1. First, a client creates a “blank” or unsigned certificate, and sends it to the CA. Included on this blank certificate is the client’s ID. This communication is secured using a D-H private/public key exchange.
2. Next, the CA computes an encrypted hash, which is applied to the blank certificate. Thus, the certificate is now signed with the CA’s digital signature. The signed certificate is sent back to the client, where it is stored until it is deleted or expires.
3. The client then sends the signed certificate, along with its keys, to any VPN peers, “authenticating” its origin.

REMEMBER: Digital signatures, and Certificate Authority servers, are not used to encrypt data. Instead, the digital signatures are used to authenticate a device’s keys. Essentially, the digital signature gives the key a stamp of authenticity.

Obviously, one must “trust” the CA that signs these digital certificates. This is why third-party CAs are often used, such as VeriSign or Entrust.
Cisco IOS devices can function with several CA vendors:

• Microsoft Windows Certificate Services
• Entrust
• VeriSign

Regardless of the vendor chosen, the CA must support the Simple Certificate Enrollment Protocol (SCEP) to work with Cisco IOS devices.
This is available on the server Resource Kit for Windows Certificate Servers.

Configure IPsec

• The network administrator has flexibility in the way they can configure IPsec.
• During configuration, when preparing the site for IPsec, the device will list the most current options. And then once the network administrator has made the selection, IPsec will then create the security association.
• A security association is a relationship between two entities and describes the components for the entities, including the security protocols, algorithms and key required for the services requested.
• And then both sides must share the same security association.

Final IPsec Frameworks

As a framework, IPsec uses a variety of protocols to implement the features as described above. Here’s an final overview:

IPsec can be used on many different devices, it’s used on routers, firewalls, hosts and servers. Here are some examples how you can use it:

• Between two routers to create a site-to-site VPN that “bridges” two LANs together.
• Between a firewall and windows host for remote access VPN.
• Between two linux servers to protect an insecure protocol like telnet.

Key Management

Now, key management is also another consideration, and, in most cases, the network administrator will opt for dynamic key exchange, and this allows the VPN servers on each end of the connection to negotiate new keys at specified intervals using internet key exchange.
Now, Internet Key Exchange (IKE) is a protocol used to setup security association in IPsec.
This provides a standard method for dynamically authenticating IPsec peers, negotiating security services and generating shared keys.

IKE Functions
Internet Key Exchange (IKE) has two distinct functions.

• ISAKMP (Internet Security Association and Key Management Protocol, defines procedures for authenticating a communicating peer, and the creation and management of security association key generation techniques.
• Oakley is a key distribution process that supports perfect forward secrecy. Oakley allows the devices to exchange keys using Diffie-Hellman key exchange algorithm.

Now you have an idea of the basics of IPsec.
Now, in later section will take a closer look at each of the different components.

IPsec Protocol

There are two main IPsec Protocols. These protocols are:

• AH (Authentication Header)
• ESP (Encapsulation Security Payload)

AH and/or ESP are the two protocols that we use to protect user data. Both can be used in transport or tunnel mode

AH (Authentication Header) is the first protocol of IPsec. It provides mainly source Authentication and data integrity. With this mechanism, various attacks are removed. It provides strong hashing algorithms to provide data integrity. But there is no encryption and no data confidentiality mechanisms. This is provided by ESP (Encapsulation Security Protocol).

IPsec Authentication Header

• The IPsec Authentication Header provides connectionless support for data integrity and authentication along with protection against a replay attack.
• The Authentication Header authenticates as much of the IP header as possible along with any upper-layer protocols.
• However, IPsec cannot authenticate any field values that change.
• The Authentication Header can be used alone or with the Encapsulating Security Payload protocol and may be used in either transport or tunnel mode.
• Prior to exchanging data, IPsec creates a security association between the two communicating entities. This provides the attributes necessary for the Authentication Header process.

The AH format is described in RFC 2402. The below shows the position of the Authentication Header fields in the IP packet.

• Next Header: It is an 8-bit field which identifies the type of what follows. This identifies the next protocol.
• Length: It is an 8 bits long field and contains the length of the AH header.
• Reserved: It is reserved for future use. Its length is 16 bits, and it is set to zero.
• SPI (Security Parameters Index): this is a 32-bit identifier, so the receiver knows to which flow this packet belongs.
• The Security Parameter Index is an essential part of IPsec as it distinguishes between the traffic streams that use different encryption rules and algorithms.
• The security association defines the Security Parameter Index and therefore only has local significance between the two entities.
• Sequence: The Sequence Number is a mandatory 32-bit field containing an incrementing counter value that supports anti-replay.
• The sender must always transmit this field, but the receiver doesn’t have to act on it.
• Both sender and receiver will initialize the counter to zero.
• When IPsec establishes a new security association, this will trigger the counter to reinitialize at zero.
• The Sequence Number must never recycle.
• Some vendors support the extended 64-bit Sequence Number, which is an extension to the 32-bit Sequence Number..
• ICV (Integrity Check Value): The Integrity Check Value is a variable field that contains the Integrity Check Value for the packet.
• The field must be a multiple of 32 bits in length and it may include some padding.
• The security association will specify the Integrity Check Value authentication algorithms, which include message authentication code using symmetric encryption, such as AES, or one-way hash function, such as SHA-256 or SHA-384.

The Authentication Header is an appropriate protocol to use when confidentiality is not required, such as providing assurance that a neighbor advertisement comes from an authorized router.
If encryption is required, the network administrator should use the Encapsulating Security Payload protocol. 

Encapsulating Security Payload

• The Encapsulating Security Payload provides confidentiality, authentication, integrity, and anti-replay service for IPv4 and IPv6.
• We can provide security services between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.
• During IPsec conversations, IPsec creates a security association that provides the necessary attributes for the Encapsulating Security Payload.
• The device adds the Security Parameter to the IP header, and that differentiates between the traffic streams using different encryption rules and algorithms.
• You can use the encryption-only feature to provide for confidentiality with the Encapsulating Security Payload. However, using encryption without integrity may leave the communication stream vulnerable to attacks.
• Best practice is to use an integrity method when using Encapsulating Security Payload protocol by using an integrity check value in the Encapsulating Security Payload header or providing authentication separately by adding an authentication header.

Top level format of an Encapsulating Security Payload packet:

The Encapsulating Security Payload has most of the same fields as the authentication header, but the fields are in three sections.

• ESP Header
• The header contains two fields, the Security Parameters Index, and a Sequence number, and comes before the encrypted data.
• Security Parameters Index (32 bits) - Identifies a security association. This field is mandatory. The value of zero is reserved for local, implementation- specific use and MUST NOT be sent on the wire. IPsec adds the security parameter index to the header as this distinguishes between traffic streams that use different encryption rules and algorithms.
• Sequence Number (32 bits) - The sequence number is a mandatory 32-bit field value that contains an incrementing counter value. When possible, use the extended 64-bit sequence number, which is an extension to the current 32-bit sequence number. A monotonically increasing counter value; this provides an anti-replay function, as discussed for AH. The first packet sent using a given SA will have a Sequence number of 1.
• Payload Data (variable) - The Payload data is a variable length field containing data from the original IP packet. This is a transport-level segment (transport mode) or IP packet (tunnel mode) that is protected by encryption. The type of content that was protected is indicated by the Next Header field.

The trailer goes after the encrypted data and may contain padding.

• Padding (0-255 bytes) − Padding for encryption, to extend the payload data to a size that fits the encryptions' cipher block size, and to align the next field.
• Pad Length (8 bits) − Indicates the number of pad bytes immediately preceding this field.
• Next Header (8 bits) − Identifies the type of data contained in the payload data field by identifying the first header in that payload.
• Authentication Data (variable) − A variable-length field (must be an integral number of 32-bit words) that contains the Integrity Check Value computed over the ESP packet minus the Authentication Data field. Authenticated data contains an integrity check value when using the optional authentication feature.

The Encapsulating Security Payload header can provide a mix of security services in IPv4 and IPv6.
The network administrator may choose to apply the Encapsulating Security Payload alone or in combination with the authentication header in a nested fashion.
Below is the Wireshark snap, where we see both the authentication header and the Encapsulating Security Payload.

• We use both because the authentication header ensures authentication and integrity but not confidentiality. 
• The Encapsulating Security Payload provides confidentiality, authentication, and integrity services. However, the field values that IPsec hashes are different.
• The authentication header hashes both the payload and header of a packet.
• The Encapsulating Security Payload uses a hash algorithm. 
• However, it doesn’t include the IP header of the packet in that, that IP header is a mutable field, meaning that it changes as it passes through a NAT device.
• We can use the Encapsulating Security Payload in either transport or tunnel mode.
• The set of services offered will depend on what options the network administrator selected and where on the network IPsec must travel.

Operating Modes
In IPsec, both authentication header and the encapsulating security payload support two modes, transport, and tunnel.

IP packet transformation when using the Authentication Header

• We see here first the original IP packet, and then the authentication header transport mode, which has the IP header first, and then the authentication header.
• In tunnel mode, you’ll see the authentication header and the IP header, but IPsec places a brand-new header around the entire packet and essentially treats the original packet as data.

IP packet transformation when using the encapsulating security payload.

• We see here the original IP packet and then the encapsulating security payload transport mode, where we see the encapsulating security payload header after the IP header.
• In tunnel mode, you’ll see the encapsulating security header and then the IP header, but IPsec places a brand-new header around the entire packet and essentially treats the original IP packet as data.
• Many times, when using encapsulating security payload, a data communication stream will use both transport and tunnel modes when travelling from point A to point B.

Transport mode encrypts only the data portion of each packet, yet leaves the header unencrypted.
We use transport mode when a device, such as a firewall, must see the source and destination address to route the packet and NAT must take place. After passing through the firewall and the NAT device, the packet then changes to a tunnel mode before been sent out onto a internet.

Tunnel mode protects the entire original IP packet by encrypting both the header and the data portion. Tunnel mode will add a new header to the IP packet. IPsec treats the original packet as the data portion. We use tunnel mode between the two gateways, where the gateway will most likely act as a proxy for the host behind the router.

So, imagine the packet is starting in the private network.

• The IP packet might start out in transport mode.
• And then, after passing through the firewall and NAT device, IPsec can add a header to be in tunnel mode as the packet travels across an insecure WAN.
• Coming in from the WAN, and then again through the firewall and NAT device, it’ll then again be safely in the private network on the other side.
• The device can then remove the tunnel mode header and deliver the payload.