Chapter 1

Introduction to IP security

1.1 IP Security (IPSec)

IP Security shall be used to extend the IP communications protocol, providing end-to-end
confidentiality for data packets traveling over the Internet. The appropriate mode of IPSec shall
be used commensurate with the level of security required for the data being transmitted: sender
authentication and integrity without confidentiality or sender authentication and integrity with
confidentiality. IP security uses industry-standard encryption algorithms and a comprehensive
security management approach to provide security for all TCP/IP communications on both
sides of an organization’s firewall. The result is a Windows, end-to-end security strategy that
defends against both external and internal attacks.
IP security is deployed below the transport layer, sparing network managers (and
software vendors) the difficulty and expense of trying to deploy and coordinate security
one application at a time. By simply deploying Windows IP security, network managers
provide a strong layer of protection for the entire network, with applications automatically
inheriting from IPSec-enabled servers and clients.
In today’s world information has become of much concern. Whether it be business transactions,
letters, business secrets, or any other kind of sensitive information it has all become stored
digitally somewhere on a storage device. This raises a big concern among the owners of that
information because of the risk of it being intercepted by users who have no authority to access
that information. Before the internet people did not need to worry about information being stolen
through wired cables because we used physical means of sending that information. Either or
other more reliable sources, we were more concerned on whether the information would Get to
it’s destination on time than on its integrity because if someone were to open the envelope or cut
the box open it would be evident. We were not concerned much with the authentication of the
information because we had a signature which would prove who was the author of that
information. In today’s world things have totally shifted. We have made some serious changes
because of the way the Internet works. Today the basic three components of information secure
delivery have become confidentiality, integrity, and availability. This is where IPSec Virtual
Private Networks (VPNs) play an important role. IPSec VPNs to many people usually means

-1-
encryption and because the IP protocol lacks intrinsic security we need a way to secure the
transmission of data between two endpoints. This is where IPsec can prove to be effective. IPSec
is a security protocol that was designed to provide authentication and encryption over the
internet. If you break down IPsec to its most critical elements there is really only three main
Technologies.

1.2 Features of IP Security

IPsec security services are offered by means of two dedicated extension headers, the
Authentication Header (AH) and the Encapsulating Security Payload (ESP), and through the use
of cryptographic key management procedures and protocols. The AH header was designed to
ensure authenticity and integrity of the IP packet. It also provides an optional antireplay service.
Its presence guards against illegal modification of the IP fixed fields, packet spoofing and,
optionally, against replayed packets. On the other hand, the ESP header provides data
encapsulation with encryption to ensure that only the destination node can read the payload
conveyed by the IP packet. ESP may also provide packet integrity and authenticity, and an anti-
reply service. The two headers can be used separately or they can be combined to provide the
desired security features for IP traffic. Each header can be used in one of the two defined
modalities: transport mode and tunnel mode.
1.2.1.Data integrity—This is data integrity mechanisms, through the use of secret-key based or
public-key based algorithms, that allow the recipient of a piece of protected data in order to
verify that the data has not been modified in transit.
1.2.2. Data confidentiality—this is the method where protected data is manipulated so that no
attacker can read it. This is commonly provided by data encryption and keys that are only
available to the parties involved in the communication.
1.2.3. Data origin authentication—this is a security service where the receiver can verify that
protected data might have originated only from the sender. This service requires a data integrity
service plus a key distribution mechanism, where a secret key is shared only between the sender
and receiver.
1.2.4. Data Encryption Standard (DES)—The DES was published in 1977 by the National
Bureau of Standards and is a secret key encryption scheme based on the Lucifer algorithm from

-2-
IBM. The contrast of DES is public-key. Cisco uses DES in classic crypto (40-bit and 56-bit key
lengths), IPSec crypto (56-bit key), and on the PIX Firewall
1.2.5. Multivendor—Since the IPSec framework is standardized; customers are not locked into
any specific vendor product. IPSec is found on routers, firewalls, and client desktops (Windows,
Mac, and so forth).
1.2.6. Scalability—IPSec is designed with large enterprises in mind. Therefore, it has built-in
key management.

1.3 Attacks in IP Communication

TCP/IP networks are plagued with security problems because they have been designed to work
in a friendly environment, with physically secure connections. When these assumptions are no
more valid - as it is nowadays - the many security weaknesses of TCP/IP become manifest and
can be easily exploited. In general, IP communications are exposed to several types of attack:
1.3.1. Packet sniffing: due to network topology, IP packets sent from a source to a specific
destination can also be read by other nodes, which can then get hold of the payload, example
which may contain passwords or other private information)
1.3.2. IP spoofing: IP addresses can be very easily spoofed both to attack those services whose
authentication is based on the sender’s address (as the rlogin service or several WWW servers)
and to supply wrong information to subvert the logical organization of the network (for example,
by forging false ICMP messages of the type”destination unreachable” or”redirect”);
1.3.3. Connection hijacking: whole IP packets can be forged to appear as legal packets coming
from one of the two communicating parties, the goal of the attack being to insert wrong data in
an existing channel. Effective solutions to these and other attacks are not always available. When
countermeasures do exist, they are usually placed at the application level.
The IPSec protocol is used as a means of secure encryption. Although there are two protocols
that are available in the IPSec suite only ESP is usually used. This is because ESP offers message
authentication, integrity, and confidentiality. One of the great features of IPsec is that it can be
used with many other applications not just VPNs.. This ensures that IPSec will be around in the
future as the Internet continues to grow and become popular

-3-
 Chapter 2
Literature Survey
2.1 Security Architecture

The IP Security architecture (IPsec) defines basic security mechanisms at the network level, so
that they can be available to all the layered applications. The security techniques adopted in
IPsec have been designed. Somebody can question if it is right to locate the security functions at
the network level. Quite obviously there is not a definitive answer, because in general the
security of a system is not based on a single element, rather it is the result of a combination of
several ones. The IP level is surely the right one to block many low-level attacks, as
Those mentioned at the beginning of this section that account for a large percentage of all the
network attacks due to their simple implementation. On the other hand, IPsec is not a complete
solution when the applications to be protected are user-oriented (as in the case of electronic mail)
rather than network-oriented.
The IPsec suite is an open standard. IPsec uses the following protocols to perform various
functions:
i. Authentication provide connectionless integrity and data origin authentication for IP
datagram’s and to provide protection against replay attacks
ii. Encapsulating Security Payloads (ESP) provide confidentiality, data origin authentication,
connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited
traffic flow confidentiality
iii. Security associations (SA) provide the bundle of algorithms and data that provide the
parameters necessary to operate the AH and/or ESP operations. The Internet Security
Association and Key Management Protocol provides a framework for authentication and key
exchange, with actual authenticated keying material provided either by manual configuration
with pre-shared keys, Internet Key Exchange Kerberized Internet Negotiation of Keys DNS
records.
This document specifies the base architecture for Internet Protocol Security (IPSec) as shown in
Figure, compliant systems it describes how to provide a set of security services for traffic at the
IP layer environments. IPSec is a set of protocols operating at the OSI architecture model
Network Layer three by extending the IP packet header to support secure exchange of packets.

-4-
This provides the ability to encrypt any higher level messaging. Figure defines how the various
components of IPSec interact.

Architecture

ESP Protocol AH Protocol

Encryption Authentication
Algorithm Algorithm

Domain of
Implementation
(DOI)

Key
Management
Figure 2.1 - IPSec roadmap

IPSec supports two security services: Authentication Header (AH) and Encapsulating Security
Payload (ESP) the former provides authentication of the sender and the latter provides both
authentication of the sender and encryption of the data.
IPSec supports two encryption modes: Transport and Tunnel. The Transport mode encrypts just
the upper layer headers and data payload of each packet. The more secure Tunnel mode encrypts
the IP header, upper layer headers, and data payload.
In order for IPSec to function properly, the sender and receiver must share a public key. This is
done through a protocol known as Internet Key Exchange The protocol allows the receiver to get
a public key and authenticate the sender.
A fundamental construct in IPSec is the Security Association (SA), which establishes a basic
connection with security services. An SA is specified at a minimum with a 32-bit Security
Parameter Index (SPI).

-5-
IPSec has been deployed widely to implement Virtual Private Networks (VPNs) (an example of
current VPN technology. As such, segmented links may be securely networked with IP using
encrypted tunnels. Since the routers perform the encryption/decryption, the secure applications
need no local cryptographic support.
The three main elements of IPsec are Internet Key Exchange (IKE), Authentication Header
(AH), and Encapsulating Security Payload (ESP). These three protocols are used to provide
security when exchanging information from eavesdroppers or from outsiders trying to tamper
with the information. Another goal of IPsec Suite is to provide a standard for secure
interoperability between multiple vendors so that all the products of each vendor will work
correctly together without any problems. IPSec-based security starts with the forming of a
security association (SA) between two parties. A security association (SA) is an agreement
between two parties or entities that will say how they will support secure communication
between each other. The great thing about IPSec is that it not only supports multiple protocols,
but that it also allows for various encryption algorithms and different hash types. In order for a
secure communication to be established between two entities the encryption method and the hash
type must be negotiated. Without this prior negotiation we might have one end using a different
encryption algorithm than the entity on the other side of the communication channel. This would
result in a break down of the communication because the data would not be decrypted correctly.
Therefore, all the details must be decided before the information is sent across the medium.

2.1.1 Authentication Header (AH)

The AH service is used to provide data integrity, data source authentication, and replay
protection capability. The entire packet is authenticated. The authentication header format is
0 78 15 16 31
Next Header Length Reserved
Security Parameter Index (SPI)
Sequence Number
Authentication data

Figure2.2 – Authentication Header

-6-
The Next Header is an 8-bit field that specifies the type of data contained in the payload. The
Length field specifies header size in 32-bit words, minus two, and the reserved field is set to
zero. The Security Parameter Index is a 32-bit number that provides the SA related to this
packet. The Sequence Number keeps track of the number of packets incrementing by one for
each packet. The Authentication Data is a variable length field that contains the Integrity Check
Value (ICV). The field size must be a multiple of 32-bits and may contain padding as needed.
The sender authentication header works by calculating the ICV based on the payload, portion of
the IP header, a secret authentication key, and a hash function. The receiver performs the same
calculation, and if the two values match, integrity is verified. In addition, the source address
provides authentication, and the sequence number replay protection.
Authentication Header (AH) is a member of the IPSec protocol suite. AH guarantees
connectionless integrity and data origin authentication of IP packets. Further, it can optionally
protect against replay attacks by using the sliding window technique and discarding old packets
In Ipv4, the AH protects the IP payload and all header fields of an IP datagram except for
mutable fields (i.e. those that might be altered in transit). Mutable (and therefore
unauthenticated) IP header fields are DSCP/TOS, ECN, Flags, Fragment Offset, TTL and Header
Checksum.
In Ipv6, the AH protects the AH itself, the Destination Options extension header after the AH,
and the IP payload. It also protects the fixed Ipv6 header and all extension headers before the
AH, except for the mutable fields: DSCP, ECN, Flow Label, and Hop Limit.
The following AH packet diagram shows how an AH packet is constructed and interpreted
Authentication Header format
Offset Octet1
0 1 2 3
s 6

Octet1
Bit10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
6

0 0 Next Header Payload Len Reserved

4 32 Security Parameters Index (SPI)
8 64 Sequence Number
C 96 Integrity Check Value (ICV)
… … …
Figure: 2.3 Authentication Header format
1. Next Header (8 bits)

-7-
Type of the next header, indicating what upper-layer protocol was protected. The value is taken
from the list of IP protocol numbers.
2. Payload Len (8 bits)
The length of this Authentication Header in 4-octet units, minus 2 (a value of 0 means 8 octets, 1
means 12 octets, etcetera). Although the size is measured in 4-octet units, the length of this
header needs to be a multiple of 8 octets if carried in an Ipv6 packet. This restriction does not
apply to an Authentication Header carried in an IPv4 packet.
3. Reserved (16 bits)
Reserved for future use (all zeroes until then).
4. Security Parameters Index (32 bits)
Arbitrary value which is used (together with the source IP address) to identify the security
association of the sending party.
5. Sequence Number (32 bits)
A monotonic strictly increasing sequence number (incremented by 1 for every packet sent) to
prevent replay attacks. When replay detection is enabled, sequence numbers are never reused
because a new security association must be renegotiated before an attempt to increment the
sequence number beyond its maximum value.
6. Integrity Check Value (multiple of 32 bits)
Variable length checks value. It may contain padding to align the field to an 8-octet boundary for
2.1.1.1. Authentication techniques
Data integrity in telecommunication systems is normally ensured by computing and checking the
value of a suitable cryptographic function of the data, often called Message Digest (MD).
Effectively perform their task when data modifications are due to random errors, but they are
completely inadequate to protect the packets against deliberate modifications. In this case, a
reasonable degree of protection can be ensured only by better digest algorithms, such as MD5 It
is important to note that data integrity without origin authentication is completely useless.
Therefore, digest algorithms are normally applied in a way to include some parameters useful to
simultaneously provide a proof of the sender’s identity. Quite often this is achieved by using
public-key encryption algorithms. Unfortunately, they are computationally much heavier than
digest algorithms. Since speed is a premium in computer networks,

-8-
 Figure2.4. Procedure to verify the authenticity of a packet protected by the AH header.
The default authentication techniques chosen for IPsec are keyed authentication algorithms. They
are based on the use of the HMAC authentication algorithm in conjunction with the hash
function corresponding to a message digest algorithm, is a mechanism for message
authentication which uses cryptographic hash functions. Any iterative cryptographic hash
function can be used in combination with a shared secret key. It is important to mention that the
cryptographic strength of HMAC depends on the properties of the underlying hash function.
2.1.2 Encapsulating Security Payload
Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. In IPsec it
provides origin authenticity, integrity, and confidentiality protection of packets. ESP also
supports encryption-only and authentication-only configurations, but using encryption without
authentication is strongly discouraged because it is insecure. Unlike Authentication Header
(AH), ESP does not protect the IP packet header. However, in Tunnel Mode, where the entire
original IP packet is encapsulated with a new packet header added, ESP protection is afforded to

-9-
 the whole inner IP packet (including the inner header) while the outer header remains
unprotected. ESP operates directly on top of IP, using IP protocol number 50.
The following ESP packet diagram shows how an ESP packet is constructed and interpreted:
Encapsulating Security Payload format
Offset Octet1
0 1 2 3
s 6

Octet1
Bit10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
6

0 0 Security Parameters Index (SPI)

4 32 Sequence Number
C 96
Payload data
… …
… …
… … Padding (0-255 octets)
… … Pad Length Next Header
… … Integrity Check Value (ICV)
… … …
Figure2.5:-Encapsulating security payload format
Security Parameters Index (32 bits)
Arbitrary value which is used (together with the source IP address) to identify the security
association of the sending party.
1. Sequence Number (32 bits)
A monotonically increasing sequence number (incremented by 1 for every packet sent) to protect
against replay attacks. There is a separate counter kept for every security association.
2. Payload data (variable)
The protected contents of the original IP packet, including any data used to protect the contents
(e.g. an Initialization Vector for the cryptographic algorithm). The type of content that was
protected is indicated by the Next Header field.
3. Padding (0-255 octets)
Padding for encryption, to extend the payload data to a size that fits the encryption's cipher block
size, and to align the next field.
4. Pad Length (8 bits)
Size of the padding in octets.
5. Next Header (8 bits)

- 10 -
Type of the next header. The value is taken from the list of IP protocol numbers.
Integrity Check Value (multiple of 32 bits)
6. Variable length checks value. It may contain padding to align the field to an 8-octet boundary
for IPv6, or a 4-octet boundary for IPv4.
The ESP service is used to provide data confidentiality, data integrity, data source authentication
and anti-play capability. The data and inner headers are encrypted and the entire packet is
authenticated, with the exception of the external IP header.
The Security Parameter Index is a 32-bit number that associates the inbound SA with this packet.
The sequence number is incremented by one for each packet in the SA. The Initialization Vector
is provided if needed by the encryption algorithm. The Padding field can vary in length from 0 to
255 bytes. The Authentication data contains the integrity check vector for the header and
payload. Encryption is applied first then authentication takes place. The ESP does basically what
the AH does except that it does not authenticate the outer IP header. In addition, it encrypts the
payload using a secret key. Hence, only those who know the key can read the data, thus
providing confidentiality.
The Encapsulating Security Payload is identified by the value 52 in the Protocol field of the IP
header. When used, this block must always be the last header because it completely hides both
the upper level payload and all the next headers The ESP header itself is only partly in clear it
consists of an integer number of 32-bit blocks, with the first one containing the SPI to select the
SA to be used in decrypting all other blocks in the packet, and the second one containing the
sequence Number. Normally the IV value is either a 64-bit number generated by a pseudo-
random number generator, or it is a 32-bit number generated in a similar way which is then
extended to 64 bits by concatenating it to its complement. In the DES-CBC mode, the encrypted
portion of the ESP header begins with an initialization vector composed of an integer number of
32-bit words. The IV is followed by the encrypted payload which is padded with blocks to
ensure that the total dimension of the ESP header be a multiple of 64 bits. The byte before the
last one in the ESP header contains the padding length (expressed in bytes) while the last byte
contains the payload type. The minimum length of the padding varies between 0 and 7 bytes, but
it is legal to use a longer padding (up to 255 bytes) to hide the real length of the encrypted data.
The DES-CBC algorithm must be supported by all IPsec standard implementations. Since the

- 11 -
DES algorithm can be regarded at best as a moderately difficult algorithm to be broken, it is very
likely that in the near future other algorithms be standardized for use in IPsec. And is already
provided in many IPsec distributions. This technique is based on the repeated application of the
DES transformation to the same data block with three different keys, and it is cryptographically
stronger than plain DES because it is equivalent to an encryption algorithm which uses a 112-bit
Key). The authentication data included in the ESP payload is a variable-length field containing
an ICV computed over the ESP packet minus the authentication data field itself. The length of
the field is specified by the authentication function selected. This field is optional, and is
included only if the authentication service has been selected for the ESP SA in question.
2.1.3 Security association
The IP security architecture uses the concept of a security association as the basis for building
security functions into IP. A security association is simply the bundle of algorithms and
parameters that is being used to encrypt and authenticate a particular flow in one direction.
Therefore, in normal bi-directional traffic, the flows are secured by a pair of security
associations. Security associations are established using the Internet Security Association and
Key Management Protocol ISAKMP is implemented by manual configuration with pre-shared
secrets, Internet Key Exchange Kerberized Internet Negotiation of Keys (KINK), and the use of
IPSECKEY DNS records. In order to decide what protection is to be provided for an outgoing
packet, IPSec uses the Security Parameter Index (SPI), an index to the security association
database (SADB), along with the destination address in a packet header, which together uniquely
identify a security association for that packet. A similar procedure is performed for an incoming
packet, where IPsec gathers decryption and verification keys from the security association
database. For multicast, a security association is provided for the group, and is duplicated across
all authorized receivers of the group. There may be more than one security association for a
group, using different SPIs, thereby allowing multiple levels and sets of security within a group.
Indeed, each sender can have multiple security associations, allowing authentication, since a
receiver can only know that someone knowing the keys sent the data. Note that the relevant
standard does not describe how the association is chosen and duplicated across the group; it is
assumed that a responsible party will have made the choice. Both AH and ESP exploit the
concept of “security association”

- 12 -
(SA) to agree upon the security algorithms, transforms and parameters shared by the sender and
the receiver of a protected traffic flow. Each IP node manages a set of SAs, at least one SA for
each secure communication. The SAs currently active are stored inside a database, known as the
Security Association Database (SAD). An entry in the SAD (i.e., a security association) is
uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination
Address, and a security protocol (AH Or ESP) identifier. The Security Parameter Index (SPI) is
transmitted inside both the AH and ESP headers, since it used to choose the right SA to be
applied for decrypting and/or authenticating the packet. In unicast transmissions, the SPI is
normally chosen by the destination node and sent back to the sender when the communication is
set up. In multicast transmissions, the SPI must be common to all the members of the multicast
group. Each node must be able to correctly identify the right SA by combining the SPI with the
multicast address. The negotiation of a SA (and the related SPI) is an integral part of the protocol
for the exchange of security keys. Specific security requirements are defined at each node
usually by means of an ordered list of admission rules (or policies), which form the node’s
Security Policy Database (SPD). The protection provided to each incoming/ outgoing traffic flow
is verified/decided by consulting the SPD. In general, packets are selected for one of three
processing modes based on IP and transport layer header information matched against entries in
SPD. Each packet is either afforded IPsec security services, discarded, or allowed to bypass
IPsec, based on the applicable policies found in the database.

Chapter 3
Existing work in the Field
3.1 Modes of operation
There are three basic IPSec modes the transport, the tunnel, and the nested. The transport mode
is used to protect the payload of the packet only. The authentication or encryption and

- 13 -
connection endpoints are the same. The tunnel mode is used to protect the entire packet, which
includes the header. The authentication or encryption and connection endpoints may or may not
be the same. The nested mode is a combination of two or more tunnel modes. Normally a host
can use transport or tunnel mode and a router can use only tunnel mode.

3.1 Transport Mode

In the transport mode of operation, the TCP and Application layer data are authenticated or
encrypted between two hosts. Hence the connection and security endpoints are identical. In
transport mode, only the payload (the data you transfer) of the IP packet is encrypted and/or
authenticated. The routing is intact, since the IP header is neither modified nor encrypted;
however, when the authentication header is used, the IP addresses cannot be translated, as this
will invalidate the hash value. The transport and application layers are always secured by hash,
so they cannot be modified in any way (for example by translating the port numbers). Transport
mode is used for host-to-host communications. A means to encapsulate IPsec messages for NAT
traversal has been defined by RFC documents describing the NAT-T mechanism. Figure below
illustrates the transport mode format using the ESP header.

IP Header ESP Header TCP (Encrypted) Data (Encrypted)

Figure 3.1 - Transport Mode Format

3.2 Tunnel Mode

In the tunnel mode of operation, the IP, TCP, and Application layer data are encapsulated and
authenticated or encrypted between two routers. A host is connected to each router that sends or
receives the authenticated or decrypted packet. The security and connection endpoints are
different. Figure 5 below illustrates the tunnel mode format using the ESP header. In tunnel
mode, the entire IP packet is encrypted and/or authenticated. It is then encapsulated into a new IP
packet with a new IP header. Tunnel mode is used to create virtual private networks for network-
to-network communications (e.g. between routers to link sites), host-to-network communications
(e.g. remote user access), and host-to-host communications (e.g. private chat). Tunnel mode
supports NAT traversal

- 14 -
 H Router Net Router H

Router ESP Header IP Header TCP Data

IP Header (Encrypted) (Encrypted) (Encrypted)

Figure 3.2 - Tunnel Mode Format

3.3 Nested Configuration:-

Nested configuration illustrates a tunnel mode established between two hosts connected to two
outer routers in a nested configuration for confidentiality. A second tunnel mode is established
between the two inner routers for integrity. As such the security and connection endpoints are
different.

H Outer Inner Inner Outer H

Net
Router Router Router Router

In Router AH Out Router ESP IP Header TCP Data

IP Header IP Header (Encrypted) (Encrypted) (Encrypted)

Figure 3.3 - Nested Configuration

There are two main modes which IPSec uses in order to operate. The first mode is transport
mode and the second is tunnel mode. Transport mode is used when an SA is made between two
hosts that usually reside in the same network. It’s usually referred to as host-to host. In this case
only the packet’s payload is encrypted. This mode can also be used when you don’t care whether
the IP addresses of the communicating parties are made public or not. Also, transport mode

- 15 -
Lacks the ability to participate in gateway-to-gateway communications. Tunnel mode is used
when an SA is made between two IPSec gateways. This is usually what is used in VPNs because
in tunnel mode not only is the payload encrypted but the entire original packet. This hides the IP
addresses of the source and destination of the IP packet. Another advantage of tunnel mode is
that it can occur not only with gateway-to-gateway, but also between host-to-host and
Host-to-gateway.

Figure3.4:- Transport mode & Tunnel Mode

The above image shows the difference between tunnel mode and transport mode. As you can see
in transport mode the original IP packet is used whereas in the tunnel mode a new IP header is
planted on the packet. The protocol that is the authenticator and negotiator of IPSec is the
Internet key exchange (IKE) protocol. It is what verifies whether your system has the right to
start an encrypted communication with the device in question. It then negotiates which
encryption algorithm will be used during the connection. There are two phases in the IKE
Transaction that support the creation of an SA between two parties. They are referred to as phase
1 and phase 2. Phase 1 begins when an initiator wants to begin a session with a VPN gateway
device. In this phase two things occur. One is the authentication of the remote client and the
other is to exchange public key information that will be used for the next phase. Various ways
Exist that can be used to verify authentication. Some of which are pre-shared keys which is a key
that has been pre-configured between the communicating devices. This is a very simple way of
Authentication however it does have many drawbacks because if the key is broken you must
reconfigure all the devices that used that key. The second method of authentication that can be
used is digital signatures also called digital certificates. In this case a Certificate Authority (CA)

- 16 -
remotely manages and administers each certificate. The CA is the center piece of the Public Key
Infrastructure (PKI) encryption method. In this concept the PKI is publicly available to Anyone
who wants it. They are typically available in certificates. Phase 2 of the IKE transaction deals
with the negotiation of the parameters of IPSec SAs. Once Phase 2 is complete IPSec SA is
Formed and the VPN connection is made. During the Phase 2 exchanges all the packets are
encrypted using whatever protocols were negotiated during Phase 1 and any other protection that
might be used are hashes that confirm the origin of the packets. The IPSec Security Protocols
that are used in IPSec are the Authentication Header (AH) and the Encapsulating Security
Payload (ESP). When creating an IPSec-based VPN you can choose to use either AH or ESP.
You also can use both of them at the same time depending on the needs of the users. Although
you are able to use either one the most popular security protocol that is being used is ESP.
Authentication Header (AH) protocol is IP protocol. It provides authentication and integrity, but
it does not offer confidentiality for the packet’s payload. That means that anyone will be able to
see the payload. This is a security limit that AH has and may not be suitable for most secure
communications. However, if your concern is confidentiality then AH can be used. AH
guarantees that the information it contains came from the person who claimed to have sent it. A
good characteristic of AH is that because it does not use complex encryption algorithms it has a
smaller size payload than ESP. This means that AH packets have a smaller processing burden on
the device that is sending the packet. There is no need to keep adding headers that take time to
encrypt and decrypt. When integrity and IP address authentication isn’t important and
performance is, and then AH would make a good solution.

Chapter 4
Proposed Work
4.1 Internet Key Exchange (IKE)
The IKE Protocol makes it possible for two nodes to negotiate a secure connection by creating a
SA. The SA set of parameters is only for one direction of data flow and for only one protocol.
During the negotiation, the IPSec protocols are agreed upon, the hash function, authentication

- 17 -
key, encryption algorithm, and encryption key data are exchanged, and the duration of security
association is set. The IKE protocol consists of two phases. During phase one, a security
association is established in order to protect the messages during the phase two exchanges.
During phase two, an IPSec SA is established. Correct application of both AH and ESP requires
that all the communicating parties agree on a common key o be used in computing and checking
the security headers. IPsec allows for key management to occur either out of-band or with
specifically crafted protocols. There are several groups within the Internet community which
have proposed different key management mechanisms, all of them stressing different
requirements, such as: fast key exchange, strong authentication, lightweight protocols, and
others. Even if no general agreement has yet been reached, the current work in this area is likely
to converge toward the Internet Key Exchange (IKE), which is a combination of the following
protocols: the Internet Security Association and Key Management Protocol (ISAKMP), and the
key exchange protocols Oakley and SKEME.
4.1.1. Manual key management
IPsec requires every implementation to allow for manual setting of the security keys, in case no
in-line key management technique is adopted or human-based security is desired. Obviously
manual keying is possible only if the security operators have separately agreed out-of-band on
The keys to be used, for example at a reserved meeting. This solution exhibits high personnel
costs and does not scale well, because it requires personal action of an operator on each network
device taking part to the secure channel. Additionally, it can generate a false sense of security: it
is worthwhile reminding the reader that human intervention does not automatically ensure a
higher level of security, due to untrusted operators and residual problems related to hardware and
software integrity of the device where the key is set. However, in spite of these disadvantages,
manual key management finds application in restricted environments, with a small number of
devices physically secured that, according to the security policy, can operate only when
explicitly enabled by human intervention.
4.1.2. Automated key management
An automated key management mechanism is required to allow the widespread deployment of
IPsec. Such support is essential for the use of the anti-replay features of AH and ESP, and to
accommodate on-demand creation of SAs (e.g., for user and session-oriented keying). The

- 18 -
default automated key management protocol selected for use with IPsec is IKE under the IPsec
Domain of Interpretation (IPsec DOI). Other automated key management protocols are also
permitted. IKE is a hybrid protocol which uses part of Oakley and part of SKEME in
combination with ISAKMP to provide authenticated keys for use with ISAKMP itself, AH and
ESP. ISAKMP defines a generic architecture for authenticated SA set-up and key exchange,
without specifying the actual algorithms to be used. Therefore, ISAKMP can support a large
variety of key exchange techniques. Oakley is a key-exchange protocol based on a modified
version of the Diffie-Hellman algorithm. Basically, Oakley describes a set of key exchange
methods, and the security services provided by each method

Figure: 4.1 Key management API: PF KEY.

Perfect forward secrecy for keys, identity protection for the negotiating parties, and
authentication. Oakley is one of the natural partners for ISAKMP. IKE is also using parts of the
flexible key exchange technique described by SKEME, which provides valuable security
features, such As: anonymity, non-repudiation, and quick key refreshment. ISAKMP operates at
the application layer, and is independent of the lower layer protocols. Moreover, ISAKMP is not
bound to a particular security protocol. It is meant as a generic SA and key management protocol
for the Internet Community. As such, it can negotiate authenticated keying material for any
security protocol (AH, ESP, TLS, OSPFv2 and any application layer security protocol). A
generic key management API that can be used by any of the mentioned security protocols has
already been standardized and is freely distributed with the most recent BSD and Linux OSs. PF
KEY is a new socket Protocol family used by privileged key management applications to
communicate with an operating system’s SA databases. The conceptual model is presented in

- 19 -
Figure IKE instantiates ISAKMP for use with IPsec protocols, i.e., under the specific IPsec DOI.
A DOI defines the specific protocols, cryptographic algorithms and transforms identifiers; the
SA attributes to be negotiated, specific ISAKMP payload contents, and (if needed) additional
key exchange types.ISAKMP defines two”phases” of negotiation. In the first phase, two entities
(key management servers) agree on how to protect further negotiation traffic between them. The
result of this phase is the establishment of an ISAKMP SA. This security association is then used
To protect the negotiation for the required security protocol SA (for the IPsec DOI, an AH or an
ESP SA).ISAKMP also defines several types of payloads, which are used to transfer security
association and key exchange data in formats that are defined by the specific DOI. The number,
the types and the ordering of these payloads during a particular ISAKMP negotiation is specified
by the ISAKMP exchange type. Currently, there are seven types of exchanges defined, each of
which is designed to provide a particular set of security services. IKE defines two basic methods
for generating authenticated keys: main mode and aggressive mode. The former is mandatory for
a compliant IPsec-IKE implementation. In addition, the quick mode has to be implemented is
mandatory as a mechanism to negotiate non-ISAKMP SAs and to generate fresh keying material.
Basically, IKE defines four methods for the phase 1 authentication:
1. pre-shared keys
2. digital signatures
3. public key encryption
4. Revised public key encryption.
The selection of a particular authentication method depends on the security requirements of the
specific application using IPsec with IKE as the key management protocol. Authentication via
pre-shared keys is mandatory for any implementation. As far as the public key cryptography is
concerned, IKE imposes neither the use of a particular digital signature algorithm, nor a
particular key distribution method. ISAKMP, which defines a certificate payload as a means to
transport certificates via ISAKMP, mandates support for the following standards: DNS signed
key X.509 certificate (both for signature and key exchange) In addition to IKE, several different
solutions are being proposed. Currently, the major competitor is SKIP (Simple Key-management
for Internet Protocols) which bases its operations on the Diffie-Hellman algorithm. SKIP is
simple and addresses several problems of key management in high-speed networks, such as zero

- 20 -
message key set-up and update which permit fast dynamic re-keying frequent in-line change of
the security keys to avoid analytic attacks based on accumulation of cypher text encrypted with
the same key.
4.2 Software implementations
IPsec support is usually implemented in the kernel with key management and ISAKMP/IKE
negotiation carried out from user-space. Existing IPsec implementations often include both.
There exist a number of implementations of IPsec and ISAKMP/IKE protocols. These include:
NRL IPsec, one of the original sources of IPsec code.
1. The KAME stack, that is included in Mac OS X, Nets and FreeBSD.
2. "IPsec" in Cisco IOS Software
3. "IPsec" in Microsoft Windows, including Windows XP, Windows 2000Windows 2003,
Windows Vista, Windows Server 2008
4. IPsec in Windows Vista and later
5. Authentic QuickSec toolkits
6. IPsec in Solaris
7. IBM AIX operating system
8. IBM z/OS
9. IPsec and IKE in HP-UX (HP-UX IPsec)
10. The Linux IPsec stack written by Alexei Kuznetsov and David S. Miller.

4.3 Applications of IP security features

The AH and ESP headers can be used in different ways to protect IP communications. This
section briefly reviews some of the most interesting applications, with reference to the
corresponding weaknesses in IP.
4.3.1. Virtual Private Networks
Nowadays, technical and economical reasons are pushing implementation of corporate wide-area
networks to migrate from dedicated links and proprietary network technologies to solutions
based on public shared links and open network architectures. This achieves several advantages
but currently exhibits a serious drawback: there is a drastic reduction in intrinsic system security,
due to the use of shared channels and devices. To regain the same previous level of network

- 21 -
security while maintaining the economical advantages offered by public networks, one has to
succeed in separating and protecting his own data packets within the crowd of packets traveling
across the public links. Usually, this is achieved by establishing a Virtual Private Network
(VPN). This is commonly done by the IP tunneling technique: IP packets to be protected are
wrapped in a security envelope and encapsulated inside normal IP packets that are used just to
transport the original packets across the public network to their final destination. Often, the
endpoints of an IP tunnel are not the hosts wishing to exchange the data, rather two firewalls
Which protect the LANs from external attacks? VPNs can be created either by using one of the
AH and ESP headers, or both. As an example, with reference, let us suppose that a TCP channel
between a host H1 in the network N1 and a host H2 in the network N2 has to be protected only
against data manipulation and origin falsification, while data privacy is not required. In this case
The AH header can be used in the following way. Firewall FW1 gets the original packet and
modifies it by adding the authentication header before sending it to the other endpoint of the
secure channel (FW2), as shown When this packet reaches FW2, the firewall checks it for
integrity and origin authentication using the data in the AH header. If the check is successful,
then the IP header and the AH one are removed and the remaining data (i.e. the original packet)
is sent to the final destination. .
If the VPN is implemented by using only the AH header, then the attackers can neither alter the
transmitted packets nor insert forged packets in the channel. However they can still read the
content of the packets. To prevent disclosure of the payload, the ESP header has to be used too.
Simple use of AH and ESP does not completely protect the traffic: packets can be deleted by
intermediate nodes or recorded and later replayed. These attacks cannot be easily hindered at the
IP level: appropriate defenses (such as the use of unique packet identifiers and the generation of
heartbeat packets) are usually placed at some upper level in the network stack. A partial solution
at the IP level is offered by using the optional anti-replay service provided by both AH and ESP.
The sequence number generated by the sender has to be carefully checked by the receiver. This
method of creating VPNs, like any other technique based on IP encapsulation, brings some
fragmentation problems. If the packet to be transmitted already has the maximum dimension
allowed for an IP packet, and then it will not be possible to encapsulate it inside another IP
packet: fragmentation and reassembling will necessarily take place at the two endpoints of the

- 22 -
tunnel. As a consequence, the performance of the virtual channel can degrade down to 50% of
the normal throughput. The worst case takes place for larger packets, which are typically used in
transferring large data sets that - by contrast - would need no fragmentation to achieve maximum
speed. On the contrary, the best case occurs for small packets, such as those used in interactive
applications which - ironically – would better accept even a larger performance penalty, as long
as the total throughput remains compatible with the reaction time of the human operator. Last but
not least, it is interesting to realize that this VPN technique can be adopted even between a
firewall and a single external host (Figure 10). This case is of particular relevance to guarantee
security when a mobile host is used outside the protected network perimeter. The firewall would
act as home agent for HM in the procedure of neighbor discovery. HM will be assigned two
different IP addresses, one when it is connected inside the security perimeter, and the other when
it is outside of it. In this last case, the firewall would also act as a relay, by redirecting
The packets coming from inside the corporate network to the external address, after adding the
required headers (AH only, or AH plus ESP).
4.3.2. Application level security
Networked applications executing on top of an IP stack including IPsec may require usage of a
communication channel with specific features. In order to avoid duplication
Of functionality (and hence performance degradation), it is useful to be able to specify at the
transport layer the security attributes of the channel being created. In the first BSD-UNIX
implementations of IPsec, this effect can be obtained by properly using the setsocketoption ()
system call. Anyway, this is not a complete solution for application-level security because only a
partial protection is obtained: AH provides host-based authentication only, while applications
usually require user-based authentication.
Moreover, AH and ESP protect the data only during their transmission along the channel. Once
the data have been received, they are no longer protected in any way. This fact may not be
relevant if the receiving host is a secure one, but there is the additional implication that origin
authentication and data integrity properties are lost as well, so that formal non-repudiation cannot
occur after the data have been extracted from the secure channel. We can therefore draw the
conclusion that the security features of IPsec do not eliminate the need for other security
mechanisms that will probably be better placed at the application level.

- 23 -
4.3.3. Routing security
With the increasing use of Internet for commercial applications, the need for a reliable and
secure network infrastructure has become higher than ever. Since IPsec offers different network
level security services through a proper combination of AH and ESP headers, it is highly
desirable that they be applied to the messages exchanged

Figure 4.2. Tunnel between a firewall and a mobile host.

By routers. IPsec protection for routing protocols prevents attacks aiming to subvert the logical
architecture of the network. As an example, in IPv6 intra-domain routing protocols rely on the
security provided by the default AH and ESP support of IPv6 routers. The following types of
messages are protected:
i. Router advertisements, to ensure that they are originated by an authorized router;
ii. Neighbor advertisements, to ensure that they come from
Authorized hosts and to avoid the risk of somebody attaching a new host to the network without
proper authorization. The ICMP messages related to an unreachable host or network
(”destination unreachable”) or the one that indicates a better route (”redirect”) should also be at
least authenticated to ensure that these messages come from hosts or routers that were on the
original path of the packets. Securing these types of messages is surely not trivial.
For example, the routing advertisements are sent to a multicast group and therefore all the routers
in the group must know the (common) secret key to be used to verify and/or decrypt the
messages; but in turn this fact implies they can forge messages and impersonate any router in the
group.These and more others are common aspects that a reliable security mechanism for the
routing infrastructure has to address. Protection of the neighbor advertisements poses a serious
problem: these messages can be protected only after a SA has been created between the host and

- 24 -
the address distribution center. On the other hand, this SA can be created only after an address
has been assigned to the host, so we conclude that this is the typical chicken-and egg problem
which has no correct way to be solved. To break the loop, partial solutions are possible: for
example, priority can be given to the address assignment phase and SA setup can be permitted
only subsequently, but in this way the address assignment phase is not protected. Alternatively,
public-key authentication can be used: host is assigned a key pair and has to be pre-configured
with the public key of the authority which Signs the certificates of the routers and the address
distribution centers. The last alternative is to configure routers so that they do not advertise local
prefixes; by this way, each host is forced to contact a router first. Protection against false ICMP
messages requires that they use the authentication header, but it has the drawback to require the
establishment of a SA with each router and host on the path between the source and the
destination of the packets. With respect to the security of the messages used by the various
Routing protocols, they should always be exchanged only within the frame of a SA and be
protected by AH. For sake of generality, this solution is highly preferable to using authentication
mechanisms specific for each routing protocol.

Chapter 5
Conclusions

The IPSec modes described in this paper provide flexibility for authentication and encryption of
Internet packets that assure the integrity and confidentiality of the transported information from
source to destination. It is recommended that Subgroups N1 and N4 consider the findings of this
working paper for future analysis of ATN/IPS as a candidate for inclusion in the ATN/IPS
SARPsTCP/IP, as it exists today, has a general lack of security. Examples of implementations of
SYN flooding, IP Spoofing, Connection Hijacking, etc. show that this lack of security has lead
directly to the development of tools and techniques to exploit TCP/IP's weaknesses. Fixing some

- 25 -
of these flaws today is possible but these fixes are not always in widespread, everyday use - your
host may implement them, but host you want to communicate with may not. Thus, most
communication on today's Internet is still unsecured. Migrating to a new protocol suite, such as
IPv6, may be the only answer to fixing the flaws in TCP/IP for good. IPSec includes two
protocols, AH and ESP, which provide security for IP packets. The AH provides authentication,
integrity and replay protection. The ESP provides authentication, integrity, replay protection and
confidentiality. Authentication and integrity can be used with or without confidentiality and
vice-versa. These protocols need certain parameters in order to establish each connection. The
parameters are collected in an entity called security association or SA. When two nodes have
established matching SAs, sent and received packets can take advantage of the security services.
In the transport mode, the initial IP header is used to deliver the packets to the endpoints. In the
tunnel mode, the IP header provides the address of the router, while the endpoint addresses are
encrypted along with the payload. The transport mode of operation, IPSec supports AH alone or
ESP alone. Similarly, the tunnel mode IPSec supports AH alone or ESP alone. Typical
applications are end-to-end security, VPN support, nested tunnels, and remote access. The paper
describes the IPsec architecture including its defined security formats and the related key
management procedures. Common IPsec applications are also presented. Being initially designed
to work in a friendly environment, TCP/IP networks are now plagued due to their physically
insecure connections. This is why they are vulnerable to attacks like packet sniffing, IP spoofing
and connection hijacking. The IP Security (IPsec) architecture defines basic security mechanisms
at the network level, so that they can be available to all the layered applications.
IPsec security services are offered by means of two dedicated extension headers, the
Authentication Header (AH) and the Encapsulating Security Payload (ESP), and through the use
of cryptographic key management procedures and protocols. The AH and the ESP are inserted in
the body of the original IP packet to provide network level security. They are compatible with
both IPv4 and IPv6 packets.
The Authenticity and integrity of the IP packet are ensured with the AH header. The AH header
fixes the problems of illegal modification and packet spoofing. It also provides an anti-replay
security option. On the other hand, encryption and data encapsulation are provided by the ESP

- 26 -
header. On top of data confidentiality, it can also optionally provide the services of the AH
header.
Both AH and ESP exploit the concept of “security association” (SA) to agree upon the security
mechanisms to be used and their associated parameters. The active security communication
connections are stored in a Security Association Database (SAD). The entries in the SAD consist
of triples each called Security Parameter Index (SPI). The SPIs uniquely identify the right SA to
be used. Each node in the communication chain must have the right SPI in its SAD in order to
participate in the communication process. Both the AH and the ESP include the necessary SPI in
their body.
Both the AH and the ESP have a sequence number field which provides anti-replay service. Data
integrity of packets (optional for the ESP), is provided via the Integrity Check Value (ICV) also
known as Authentication Data field (AD). It holds a content digest of all immutable fields in the
packet. The payload is encrypted with padding in the ESP, which ensures both content and traffic
confidentiality. The authentication algorithm used in IPsec is HMAC in conjunction with a
message digest algorithm, such as MD5 or SHA-1. The default encryption algorithm is DES-
CBC, which must be supported by all implementation, although other algorithms could be used
as well.
Correct application of both AH and ESP requires that all communication parties agree on a
common key to be used in computing and checking the security headers. The IPsec definition
requires an allowance for manual key management in every implementation. Pure manual key
management, however, is not practical and could only be used in small physically secure
networks. For this reason automatic key management is essential in a wide spread deployment of
IPsec. The default automatic key management for IPsec is Internet Key Exchange (IKE),
although other key management protocols are also permitted.
IKE is a hybrid protocol, which uses part of Oakley and part of SKEME in combination with
ISAKMP. Oakley is a key-exchange protocol based on a modified version of the Diffie-Hellman
algorithm. It describes a set of key exchange methods and the security services provided by each
method. SKEME, on the other hand, provides valuable security features, such as anonymity,
non-repudiation, and quick key refreshment. ISAKMP operates at the application layer, and is
independent of the lower level protocols. It is implemented via a socket protocol family and it

- 27 -
defines two “phases” of negotiation. In the first phase the two communicating parties agree on
the algorithm to protect the future communication. In that way a SA is established. In the second
phase, under the protection of the ISAKMP SA, the two communicating exchange the session
key for each connection. Some applications of IPsec are virtual private networks (VPN),
application level security and routing security. IPsec lets us create a virtually private network by
use of a technique called IP tunneling, which lets us create secure channels between two secure
networks. To be protected, IP packets are wrapped in a security envelope and encapsulated into
normal IP packets. The receiving end verifies and UN-encapsulates the packets and then
forwards the original packets to their destination host on the LAN. To all the hosts inside the
secure LANs the packets they receive are as if sent through a private network. In other words any
host on the VPN is virtually local.
Application level security is very weak if only implemented with IPsec. For that after
verification and un-encapsulation there is no guarantee on the content of the packet. Therefore
higher-level security implementation is required for maintaining application level security. In
routing security IPsec doesn’t provide a complete solution. Other authentication methods are
required before an IPsec connection can be established.

Chapter 6
Future Scope

Enterprise connectivity is exploding, driven by globalization, convergence, virtualization and

social computing. As corporate perimeters dissolve, these securities focus switches towards
application and data-level security solutions. The question to ask is what are the longer-term
implications for network security? Will it become redundant or could it grow more powerful?
Only one thing seems certain: It will be different from today.

- 28 -
Who needs network security? Why don't we just build encryption and antimalware protection
into end-points and simply enjoy open networks? From a security perspective that's always best
and it's in line with the Jericho Forum vision. But in the real world it's not so simple. At the very
least we need protective measures in networks to guarantee availability and performance.
Beyond that there is huge potential to deliver value through security features in networks. In fact
there has always been more to network security than users realize. Fallback, monitoring and
filtering are ever-present but invisible to endpoints. Many application owners believe their
systems operate on top of a pure IP infrastructure, but nothing could be further from the truth
enterprise networks are heavily structured. Today's network products boast an impressive and
growing array of single-point security solutions, ranging from simple authentication mechanisms
to full-blown identity management. Taking advantage of network-based security features is
difficult in that geography and topology are major factors. They dictate ownership boundaries
and legal jurisdictions and it's hard to establish a set of choke points from which all network
traffic can be monitored or controlled. Management domains don't map neatly onto the precise
scope of application systems and legacy equipment presents local incompatibilities.
Nevertheless, gateway devices are a convenient point for securing central databases. And
complete network coverage is not always essential for value to be derived from security analysis
because useful intelligence can be derived from samples of Traffic. There are also distinct
advantages in locating security measures inside networks. You gain a richer picture of user
behavior, enabling individual user activities to be assessed in the context of a broader
community. In fact, visibility of events and understanding of context are the keys to effective
security and risk management. The significance and legality of user actions is dependent on
context, varying according to user authorization level, sensitivity of data, location of source,
method used, and time of day. As one of the 11 Jericho Forum principles states: "Assume
context at your peril."
One of the biggest security concerns today is the insider threat. In response to this, you can
deploy many interesting techniques in networks to detect anomalous user behavior. Valuable
intelligence can be derived by profiling, fusing and mining message content, traffic patterns or IT
activity. The future of network security might be far from clear-cut. One thing is clear - it will
certainly be richer and more sophisticated than we've seen so far. Determining how to plan for a

- 29 -
business environment in which everyone is connected and security expectations are high is not
trivial. We all have to do it. Security is one of the fastest moving areas in computer networks, as
it is vital to protect data and computer resources and to enable economical exploitation through
electronic commerce. IP security is not the exception to the rule: new extensions to IKE and
ISAKMP authentication modes have recently been defined, addressing the secure remote access
problem and trying to introduce in IPsec some user level authentication techniques at the same
time, IPsec is moving toward the integration with policy-based networks. A conceptual model
for a security policy-based networking environment is being defined for IPsec together with a
protocol which aims to provide policy discovery and policy resolution to IPsec nodes. Till now,
IPsec has found applicability in static network configurations and, in general, networks that are
under a common administration (VPNs and intranets).
The new mechanisms addressing policy management issues make IPsec scalable in general cases
and could contribute to the widespread deployment of this security technology in Internet. The
net benefit will be that more security will be already available at the network level and hence
applications will be able to concentrate on different security aspects, such as authorizations and
no repudiation.

Chapter 7
References

1. Michael Erschloe,"Information Warfare: How to Survive Cyber Attacks"

2. Brian Hatch, James Lee and George Kurtz "Hacking Linux Exposed"
3.Julia Allen, "CERT Guide to System and Network Security"
4. Richard E. Smith,"Authentication: From Passwords to Public Keys"
5. S. Kent, R. Atkinson, “Security Architecture for the Internet Protocol”,

- 30 -
6. B. Schneier, “Applied Cryptography, John Wiley & Sons”
7. Forouzan, Behrouz, 2006 “TCP/IP Protocol Suite, McGraw-Hill, New York”
8. Stephen, Northcutt, Lenny Zelster, Scott Winters, Karen Kent, Ronald Ritchey, 2005, “Inside
Network Perimeter Security”, Sams Publishing,

- 31 -