IP SECURITY

Introduction

IPsec (IP security) is a standardized framework for securing Internet Protocol (IP)

communications by encrypting and/or authenticating each IP packet in data stream. IPsec

supports two encryption modes: Transport and Tunnel. Transport mode encrypts only the

data portion (payload) of each packet, but leaves the header untouched. The more secure

Tunnel mode encrypts both the header and the payload. On the receiving side, an IPSec-

compliant device decrypts each packet.

For IPsec to work, the sending and receiving devices must share a public key.

This is accomplished through a protocol known as Internet Security Association and Key

Management Protocol/Oakley (ISAKMP/Oakley), which allows the receiver to obtain a

public key and authenticate the sender using digital certificates.

In the early 1980's, specifications were finished for the TCP and IP

protocols. These two protocols could be considered the most important in the world today

- they are the basis of the Internet. Over the past decade, the Internet has grown from a

small network connecting a small community of researchers to its present state - a

gigantic global network connecting people of all types. The huge success of the Internet

has, for the most part, been quite beneficial. The Internet has evolved from a specialized

project to a general-purpose tool. TCP and IP protocols were designed when the Internet

was small, and users generally trusted each other. The protocols lack many features that

are desirable or needed on an insecure network.

However, the growth of the Internet has created problems with security.

The TCP and IP protocols were designed when the Internet was small, and users

generally trusted each other. The protocols lack many features that are desirable or

needed on an insecure network. TCP/IP is the backbone of the internet today. Comprised

of two protocols, TCP and IP, the TCP/IP protocol suite is one of the most widely used.

The TCP/IP protocols, the basis for today's Internet, lack even the most basic

mechanisms for security, such as authentication or encryption. As usage of the Internet

and TCP/IP protocols increases, their lack of built-in security has become more and more

problematic.

Internet Protocol

The Internet Protocol (or IP as it generally known), is the network layer of

the Internet. IP provides a connection-less service. The job of IP is to route and send a

packet to the packet's destination. IP provides no guarantee whatever, for the packets it

tries to deliver. The IP packets are usually termed datagrams. The datagrams go through a

series of routers before they reach the destination. At each node that the datagram passes

through, the node determines the next hop for the datagram and routes it to the next hop.

Since the network is dynamic, it is possible that two datagrams from the same source take

different paths to make it to the destination. Since the network has variable delays, it is

not guaranteed that the datagrams will be received in sequence. IP only tries for a best-

effort delivery. It does not take care of lost packets; this is left to the higher layer

protocols. There is no state maintained between two datagrams; in other words, IP is

connection-less.

Transmission Control Protocol

Transmission Control Protocol (TCP) runs on top of IP, and provides a

connection oriented service between the sender and the receiver. TCP provides

guaranteed delivery, and ensures that the packets are delivered in sequence. The

underlying network IP, is highly unreliable and does not provide any guarantee for TCP.

In order to provide reliability between the sender and the receiver, TCP uses various

mechanisms, such as sequence numbers, acknowledgments, 3-way handshakes and

timers.

A TCP connection is identified by the 4-tuple ((destination-ip-address,

destination-port), (source-ip-address, source-port)). Ports are the actual end-points of

the TCP connection. The working of TCP could be described using a TCP state machine.

Transitions to different states are based on events received in the form of TCP segments.

The TCP states are very closely associated with timers. There are various timers

associated with connection establishment (or termination), flow control, and

retransmission.

In order to understand the security problems associated with TCP, it is

necessary that we look at the state-machine in detail. It is also important to get an

overview of TCP implementations, and how they implement the TCP state-machine, the

state-transitions and the associated timers.

The TCP layer on either end maintains table entries corresponding to the

4-tuple (remote-ip-address, remote-port, source-ip-address, source-port). This 4-tuple

uniquely identifies a connection. For every connection, the end-systems implementing

TCP need to keep the TCP state information for the duration of the connection.

IPSec Implementation Methods

Three different implementation architectures are defined for IPSec in RFC

2401. Which one we use depends on various factors including the version of IP used, the

requirements of the application and other factors. These in turn rest on a primary

implementation decision: whether IPSec should be programmed into all hosts on a

network, or just into certain routers or other “intermediate devices”.

This implementation decision is one that must be based on the

requirements of the network. There are two options: to implement IPSec in end hosts, or

in routers.

End Host Implementation

Putting IPSec into all host devices provides the most flexibility and

security. It enables “end-to-end” security between any two devices on the network.

However, there are many hosts on a typical network, so this means far more work than

just implementing IPSec in routers.

Router Implementation

This option is much less work because it means we only make changes to

a few routers instead of hundreds or thousands of clients. It only provides protection

between pairs of routers that implement IPSec, but this may be sufficient for certain

applications such as virtual private networks (VPNs). The routers can be used to provide

protection only for the portion of the route that datagrams take outside the organization,

leaving connections between routers and local hosts unsecured (or possibly, secured by

other means).

Modes of IPsec operation

There are two modes of IPsec operation: transport mode and tunnel mode.

In transport mode only the payload (message) of the IP packet is encrypted. It is

fully-routable since the IP header is sent as plain text; however, it can not cross NAT

interfaces, as this will invalidate its hash value. Transport mode is used for host-to-host

communications over a LAN.

In tunnel mode, the entire IP packet is encrypted. It must then be encapsulated

into a new IP packet for routing to work. Tunnel mode is used for network-to-network

communications (secure tunnels between routers) or host-to-network and host-to-host

communications over the Internet.

IPsec is implemented by a set of cryptographic protocols for (1) securing packet flows

and (2) Internet key exchange. Of the former, there are two:

Authentication Header (AH) :which provides authentication, payload (message) and IP

header integrity and with some cryptography algorithm also non-repudiation , but does

not offer confidentiality

Encapsulating Security Payload (ESP) :which provides data confidentiality, payload

(message) integrity and with some cryptography algorithm also authentication.

In some countries message encryption is prohibited by law and ESP protocol can not be

used. In this case AH provides entire IPsec functionality without confidentiality.

Originally AH was only used for integrity and ESP was used only for encryption;

authentication functionality was added subsequently to ESP. Currently only one key

exchange protocol is defined, the IKE (Internet Key Exchange) protocol.

IPsec protocols operate at the network layer, layer 3 of the OSI model. Other Internet

security protocols in widespread use, such as SSL and TLS, operate from the transport

layer up (OSI layers 4 - 7). This makes IPsec more flexible, as it can be used for

protecting both TCP and UDP-based protocols, but increases its complexity and

processing overhead, as it cannot rely on TCP (layer 4 OSI model) to manage reliability

and fragmentation.

Current status as a standard

IPsec is an obligatory part of IPv6, and is optional for use with IPv4. While the

standard is designed to be agnostic to IP versions, current widespread deployment and

experience concerns IPv4 implementations. IPsec protocols were originally defined by

RFCs 1825–1829, published in 1995. In 1998, these documents were obsoleted by RFCs

2401–2412. 2401–2412 are not compatible with 1825–1829, although they are

conceptually identical. In December 2005 a third generation documents RFCs 4301–

4309, were produced. They are largely a superset of 2401–2412.

It is unusual to see any product that offers RFC1825–1829 support. "ESP" generally

refers to 2406, while ESPbis refers to 4303.

Design intent

IPsec was intended to provide either transport mode: end-to-end security of

packet traffic in which the end-point computers do the security processing, or tunnel

mode: portal-to-portal communications security in which security of packet traffic is

provided to several machines even to whole LANs by a single node.

IPsec can be used to create Virtual Private Networks (VPN) in either mode, and

this is the dominant use. Note, however, that the security implications are quite different

between the two operational modes.

End-to-end communication security on an Internet-wide scale has been slower to

develop than many had expected. Part of the reason is that no universal, or universally

trusted, Public Key Infrastructure (PKI) has emerged (DNSSEC was originally

envisioned for this); part is that many users understand neither their needs nor the

available options well enough to promote inclusion in vendors' products.

Since the Internet Protocol does not inherently provide any security capabilities, IPsec

was introduced to provide security services such as:

1. Encrypting traffic (So it can not be read in its transmission)

2. Integrity validation (Ensuring traffic has not been modified along its path)

3. Authenticating the Peers (Both ends are sure they are communicating with a

trusted entity the traffic is intended for)

4. Anti-Replay (Protect against session replay)

Technical details

Authentication Header (AH)

One of the two core security protocols in IPSec is the Authentication

Header (AH). This is another protocol whose name has been well chosen: AH is a

protocol that provides authentication of either all or part of the contents of a datagram

through the addition of a header that is calculated based on the values in the datagram.

What parts of the datagram are used for the calculation, and the placement of the header,

depends on the mode (tunnel or transport) and the version of IP (IPv4 or IPv6).

The operation of the AH protocol is surprisingly simple—especially for

any protocol that has anything to do with network security. It can be considered

analogous to the algorithms used to calculate checksums or perform CRC checks for

error detection. In those cases, a standard algorithm is used by the sender to compute a

checksum or CRC code based on the contents of a message. This computed result is

transmitted along with the original data to the destination, which repeats the calculation

and discards the message if any discrepancy is found between its calculation and the one

done by the source.

This is the same idea behind AH, except that instead of using a simple

algorithm known to everyone, we use a special hashing algorithm and a specific key

known only to the source and the destination. A security association between two devices

is set up that specifies these particulars so that the source and destination know how to

perform the computation but nobody else can. On the source device, AH performs the

computation and puts the result (called the Integrity Check Value or ICV) into a special

header with other fields for transmission. The destination device does the same

calculation using the key the two devices share, which enables it to see immediately if

any of the fields in the original datagram were modified (either due to error or malice).

It's important that I point out explicitly that just as a checksum doesn't

change the original data, neither does the ICV calculation change the original data. The

presence of the AH header allows us to verify the integrity of the message, but doesn't

encrypt it. Thus, AH provides authentication but not privacy.

An AH packet diagram:

0 1 2 3

0 1 2 3 4 5 6

70 1 2 3 4 5 6 7

0 1 2 3 4 5 6

7

0 1 2 3 4 5 6

7

Next HeaderPayload

LengthRESERVED

Security Parameters Index (SPI)

Sequence Number

Authentication Data (variable)

Field meanings:

Next Header 

Identifies the protocol of the transferred data.

Payload Length 

Size of AH packet.

RESERVED 

Reserved for future use (all zero until then).

Security Parameters Index (SPI) 

Identifies the security parameters in combination with IP address.

Sequence Number 

A monotonically increasing number, used to prevent replay attacks.

Authentication Data 

Contains the data necessary to authenticate the packet.

Encapsulated Security Payload (ESP)

The Encapsulating Security Payload (ESP) extension header provides

origin authenticity, integrity, and confidentiality of a packet. Unlike the AH header, the

IP packet header is not accounted for. ESP operates directly on top of IP using IP

protocol number 50. 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.

ESP has several fields that are the same as those used in AH, but packages its fields in a

very different way

An ESP packet diagram:

0 1 2 3

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

Security Parameters Index (SPI)

Sequence Number

Payload * (variable)

  Padding (0-255 bytes)

    Pad Length Next Header

Authentication Data (variable)

Field meanings:

Security Parameters Index (SPI) 

Identifies the security parameters in combination with IP address

Sequence Number 

A monotonically increasing number, used to prevent replay attacks.

Payload Data 

The data to be transferred.

Padding 

Used with some block ciphers to pad the data to the full length of a block.

Pad Length 

Size of padding in bytes.

Next Header 

Identifies the protocol of the transferred data.

Authentication Data 

Contains the data used to authenticate the packet.

Implementations

IPsec support is usually implemented in the kernel with key management and

ISAKMP/IKE negotiation carried out from user-space. Existing IPsec implementations

tend to include both of these functionalities. However, as there is a standard interface for

key management, it is possible to control one kernel IPsec stack using key management

tools from a different implementation.

Because of this, there is confusion as to the origins of the IPsec implementation

that is in the Linux kernel. The FreeS/WAN project made the first complete and open

source implementation of IPsec for Linux. It consists of a kernel IPsec stack (KLIPS), as

well as a key management daemon (pluto) and many shell scripts. The FreeS/WAN

project was disbanded in March 2004. Openswan and strongSwan are continuations of

FreeS/WAN. The KAME project also implemented complete IPsec support for NetBSD,

FreeBSD. Its key management daemon is called racoon. OpenBSD made its own

ISAKMP/IKE daemon, simply named isakmpd (that was also ported to other systems,

including Linux).

However, none of these kernel IPsec stacks were integrated into the Linux kernel.

Alexey Kuznetsov and David S. Miller wrote a kernel IPsec implementation from scratch

for the Linux kernel around the end of 2002. This stack was subsequently released as part

of Linux 2.6, and is referred variously as "native" or "NETKEY".

Therefore, contrary to popular belief, the Linux IPsec stack did not originate from

the KAME project. As it supports the standard PF_KEY protocol (RFC 2367) and the

native XFRM interface for key management, the Linux IPsec stack can be used in

conjunction with either pluto from Openswan/strongSwan, isakmpd from OpenBSD

project, racoon from the KAME project or without any ISAKMP/IKE daemon (using

manual keying).

There are a number of implementations of IPsec and ISAKMP/IKE protocols. These

include:

1. NRL IPsec, one of the original sources of IPsec code

2. OpenBSD, with its own code derived from NRL IPsec

3. the KAME stack, that is included in Mac OS X, NetBSD and FreeBSD

4. "IPsec" in Cisco IOS Software

5. "IPsec" in Microsoft Windows, including Windows XP, Windows 2000, and

Windows 2003

6. SSH Sentinel provides toolkits

7. IPsec in Solaris

8. IBM AIX operating system

9. IBM z/OS

10. IPsec and IKE in HP-UX (HP-UX IPSec)

11. "IPsec and IKE" in VxWorks

IPSec General Operation, Components and Protocols

IPSec provides the tools that devices on a TCP/IP network need in order

to communicate securely. When two devices (either end user hosts or intermediate

devices such as routers or firewalls) want to engage in secure communications, they set

up a secure path between themselves that may traverse across many insecure

intermediate systems.

To accomplish this, they must perform (at least) the following tasks:

1. They must agree on a set of security protocols to use, so that each one sends data

in a format the other can understand.

2. They must decide on a specific encryption algorithm to use in encoding data.

3. They must exchange keys that are used to “unlock” data that has been

cryptographically encoded.

4. Once this background work is completed, each device must use the protocols,

methods and keys previously agreed upon to encode data and send it across the

network.

IPSec Key Exchange (IKE)

IPSec, like many secure networking protocol sets, is based on the concept

of a “shared secret”. Two devices that want to send information securely encode and

decode it using a piece of information that only they know. Anyone who isn't “in” on the

secret is able to intercept the information but is prevented either from reading it (if ESP is

used to encrypt the payload) or from tampering with it undetected (if AH is used). Before

either AH or ESP can be used, however, it is necessary for the two devices to exchange

the “secret” that the security protocols themselves will use. The primary support protocol

used for this purpose in IPSec is called Internet Key Exchange (IKE).

IKE is defined in RFC 2409, and is one of the more complicated of the

IPSec protocols to comprehend. In fact, it is simply impossible to truly understand more

than a real simplification of its operation without significant background in cryptography.

IKE Overview and Relationship to Other Key Exchange Methods

The purpose of IKE is to allow devices to exchange information required

for secure communication. As the title suggests, this includes cryptographic keys used for

encoding authentication information and performing payload encryption. IKE works by

allowing IPSec-capable devices to exchange security associations (SAs), to populate their

security association databases (SADs). These are then used for the actual exchange of

secured datagrams with the AH and ESP protocols.

IKE is considered a “hybrid” protocol because it combines (and

supplements) the functions of three other protocols. The first of these is the Internet

Security Association and Key Management Protocol (ISAKMP). This protocol provides a

framework for exchanging encryption keys and security association information. It

operates by allowing security associations to be negotiated through a series of phases.

ISAKMP is a generic protocol that supports many different key exchange

methods. In IKE, the ISAKMP framework is used as the basis for a specific key

exchange method that combines features from two key exchange protocols:

(1) OAKLEY: Describes a specific mechanism for exchanging keys through the

definition of various key exchange “modes”. Most of the IKE key exchange

process is based on OAKLEY.

(2) SKEME: Describes a different key exchange mechanism than OAKLEY.

IKE uses some features from SKEME, including its method of public key

encryption and its fast re-keying feature.

Conclusion

IPsec (IP security) is a standardized framework for securing Internet Protocol (IP)

communications by encrypting and/or authenticating each IP packet in data stream. IPsec

supports two encryption modes: Transport and Tunnel. Transport mode encrypts only the

data portion (payload) of each packet, but leaves the header untouched. The more secure

Tunnel mode encrypts both the header and the payload. On the receiving side, an IPSec-

compliant device decrypts each packet. IPsec was intended to provide either transport

mode: end-to-end security of packet traffic in which the end-point computers do the

security processing, or tunnel mode: portal-to-portal communications security in which

security of packet traffic is provided to several machines even to whole LANs by a single

node.