Ip sec

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
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
Next Header
Payload
Length
RESERVED
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).
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
Sequence Number
Payload * (variable)
Padding (0-255 bytes)
Pad Length Next Header
Authentication Data (variable)
Field meanings:
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.

Ip sec

More Related Content

What's hot (19)

Similar to Ip sec (20)

More from Shiva Krishna Chandra Shekar (20)

Recently uploaded (20)

Ip sec