Socket API Extensions to Extract Packet Header Information List (PHIL)

(1)

RAVINDRA NARAYAN. Socket API extensions to extract Packet Header Information List (PHIL). (Under the direction of Dr. S. Felix Wu.)

(2)

(3)

BIOGRAPHY

Narayan Ravindra, was born August 4th 1974, in Karnataka, India. He received

his elementary and secondary education in Bijapur, India. He completed his

under-graduate studies with a major in Electronics and Communications Engineering from

Regional Engineering College, Surathkal, India in 1996.

(4)

DEDICATION

(5)

ACKNOWLEDGEMENTS

I am grateful to Dr. Felix Wu, My advisor for his patience, continued support and

advise during the last two years of my fruitful association with him. I thank Dr.

Nilsson and Dr. Viniotis for serving on my thesis committee.

I thank Ho-Yen Chang, my SHANG colleague for his inputs on the DECIDUOUS

project. I thank Chandru Sargor of MCNC for providing stimulating discussions and

feedback on the PHIL API.

My due thanks are to Dr. Cli Wang, Jim Hackett and John Crawbuck of NHD IBM

(RTP), for providing the opportunity to work with them and survey the IP Security

scenario in the Industry currently.

(6)

ACRONYMS

ACL

Access Control List

AH

Authentication Header

API

Application Program Interface

ASIS

Attack Source Identication System

BITS

Bump In The Stack

CAT

Common Authentication Technology

CBC

Cyclic Block Chaining

DECIDUOUS

Decentralized Identication of Intrusion Sources

DES

Data Encryption Standard

DOI

Domain of Interpretation

DNSSEC

Domain Name System Security

ESP

Encapsulation Security Payload

IDS

Intrusion Detection System

IETF

Internet Engineering Task Force

IKE

Internet key Exchange

IP

Internet Protocol

IPSEC

IP Security

ISAKMP

Internet Security Association and Key Management Protocol

LCD

Local Conguration Datastore

(7)

MIB

Management Information Base

MLS

Multi Level Sensitivity

MPS

Message Processing System

PDU

Protocol Data Unit

PHIL

Packet Header Information List

PKIX

Public Key Infrastructure X.509

RFC

Request For Comments

SA

Security Association

SADB

Security Association Database

SHA

Secure Hash Algorithm

SKIP

Simple Key Internet Protocol

SNMP

Simple Network Management Protocol

SPDB

Security Policy Database

SSL

Secure Socket Layer

TCP

Transmission Control Protocol

TLS

Transport Layer Security

UDP

User Datagram Protocol

(8)

List of Figures

1.1 Security threats . . . 3

1.2 Various IPSEC Components and their locations . . . 4

2.1 How the AH and ESP encapsulation look . . . 8

2.2 How the SA information Looks in an SADB . . . 9

2.3 Transport and Tunnel Modes . . . 10

2.4 Overview of Security Architecture . . . 14

3.1 Using SA's to establish path . . . 18

4.1 TCP client-server based on PHIL API . . . 25

5.1 Split View of the Kernel . . . 39

5.2 System call architecture in Linux . . . 40

5.3 Input packet path in Linux IPsec Kernel . . . 43

5.4 Input packet path through the socket layer . . . 44

5.5 Output packet path through the Socket Layer and Kernel . . . 45

7.1 the SNMP example . . . 58

7.2 The PHIL Kernel Interface . . . 59

7.3 The DECIDUOUS Architecture . . . 60

8.1 SNMP Version 3 Manager Entity . . . 63

8.2 SNMP Version 3 Agent Entity . . . 64

8.3 SNMP Over IPSEC . . . 66

(11)

Chapter 1

Introduction

1.1 The IPSEC World

With the advent and growth of the Internet a multitude of networks comprising of public and proprietary protocols have come to co-exist on the present day, ever growing Internet. At the same time the incidents of security breaches also mount as each day passes, the Internet has become a haven to the innocuous hacker and to the hard-core criminal as well. With TCP/IP trac forming a major component of the Internet trac one of the chief security concerns has been the security of the TCP/IP data trac over the Internet. This chapter discusses the motivation behind the security protocols such as IPSEC.

1.1.1 Why IPSEC

The TCP/IP trac on the Internet is vulnerable to plenty of security attacks, the next two subsections briey introduce the kind of security threats that exist on the Internet and the Security Services that are needed to counter these,

Security Threats

There are four general categories of attack when it comes to the ow of information on a network ;

1. Interruption:

(12)

communi-cation channel partially or totally, this is an attack on availability. Examples include cutting of a communication line, etc.

2. Interception:

An unauthorized party gains access to the information ow, this is an attack on the condentiality, the examples of such attacks include wiretapping, etc.

3. Modication:

An unauthorized party rst intercepts the normal ow and then tampers with it to suit its own purposes. This is an attack on the Integrity of the information ow. Examples include altering the contents of packets that are buered temporarily at some Router on the way to their nal destination.

4. Fabrication:

An unauthorized party creates counterfeit packets and tries to pass them on to the network as genuine packets, this is an attack on the Authenticity of the information ow.

These attacks are summarized in the gure 1.1

Security Services

Some of the broadly required security services on the Internet are as following; 1. Condentiality :

Condentiality is the security requirement against any possible interception that may exist on the network, this is typically achieved through encryption of the information ow.

2. Authentication :

The function of the Authentication service is to assure the recipient that the message is from the source that it claims to be from.

3. Integrity :

(13)

NORMAL FLOW

INTERRUPTION _INTERCEPTION

MODIFICATION _FABRICATION

Figure 1.1: Security threats

4. Non Repudiation

Non repudiation prevents either sender or receiver from denying a transmitted mes-sage. Thus, when a message is sent, the receiver can prove that the message was in fact sent by the alleged sender. Similarly, when a message is received, the sender can prove that the message was in fact received by the alleged receiver.

1.1.2 What is IPSEC

(14)

this thesis, we address the IPSEC protocol family, their framework, components, usage and possible shortcomings. We further propose an addendum to the existing socket API to let the application programs utilize the most of what the existing IPSEC framework has to oer.

As of now many of the underlying IPSEC protocols have either been standardized or are in the process of being standardized (including those for IPSecond). As per the existing framework, various components of the security architecture occupy dierent loca-tions in the TCP/IP protocol stack. While the basic security mechanisms of Authentication header (AH) and Encapsulation Security Payload (ESP) have been incorporated into the native kernel IP stack or else where in the kernel as Bump In The Stack (BITS) or Bump In The Wire (BITW) implementations, the vital tasks of security association establishment, key exchange and key management have been relegated to the application layer protocols such as ISAKMP/IKE [5] or SKIP. The framework for security policy establishment and policy management are still evolving. (E.g., BBN's PBSM [28] , Cisco/IBM's VPN Schema, AT&T/UPenn's key note system). The Public Key Infrastructure is being integrated into the IPSEC mechanisms through the proposed standards of the PKIX working group for purposes of certicate creation, management and revocation, [27]. These components and their place with respect to each other is shown in the gure 1.2.

U S E R S P A C E K E R N E L S P A C E

l s S e cu r i t y P r o t o c o

A H && E S P

S e c u r i t y

D a t a b a s e s SADB && SPDB S A E s t a b l i s h,

K e y E x c h a n g e, K e y M a n a g e m e n t

I S A K M P / S K I P

C e r t i f i c a t e M a n a g e m e n t P r o c e s s, P K I X

(15)

1.2 What More Do We Want

In this thesis we propose extensions to the existing standard socket API to facili-tate the applications to better utilize the IPSEC capabilities. This API extension aims to provide the following additional features to the applications :

1. Extraction of the security information such as the security aorded to a particular segment of data received at the application layer from the kernel. This information is formally referred to as the Packet Header Information List (PHIL) and the API extension is henceforth referred to as the PHIL-API.

2. Interaction with the kernel's SAdb and SPdb to nd more about the existing SAs and the security level aorded to their outgoing data. Investigate the exibility that the SPdb provides in possibly overriding the default security policy.

3. Demonstrate the use of ne grained SA's through the usage of more selector elds in the IPSEC framework and the possibility of applications multiplexing their data over several security channels which fulll dierent requirements.

This proposed API extension investigates the Host-to-Host Security framework either in tunnel or transport mode, The PHIL is instrumental in providing the above de-scribed services and many more services which are discussed throughout this thesis. This thesis is an introduction to the PHIL API and its usage within the framework of Host-to-Host security model, the usage of PHIL in the VPN environment and the methods to realize the retrieval of PHIL in the VPN scenario are out of the scope of this thesis.

1.3 Thesis Outline

The thesis is outlined as following

fchapter 2 g Describes the current IPSEC scenario, as regards to the standards and its

(16)

discusses the uidity of the IPSEC standards currently and airs some concerns. fchapter 4

gProvides a detailed description of the API calls that have been implemented on the Linux

operating system in combination with the FreeSwan IPSEC package by RSA (freely available on the web). fchapter 5 g Discusses the Design and implementation issues involved in

realizing the PHIL API.fchapter 6gProvides some sample results of the PHIL information

and presents the performance impact of the PHIL API, this chapter concludes the thesis and discusses the future work following this thesis. fchapter 7 g Explains in detail the

DECIDUOUS project which utilizes the PHIL API and thus instantiates the practical usage of the PHIL API.fchapter 8gThe usage of PHIL API is further accentuated by proposing a

model for SNMP over IPSEC to fulll SNMP security requirements. fAppendices gProvide

(17)

Chapter 2

Existing IPSEC Scenario

2.1 The Underlying Protocols

The Security Architecture document [1] describes the overall framework for the IP security. It introduces the concept of a simplex security association (SA) as a unique triplet of

f

IP ADDRESS, SECURITY PROTOCOL, SPI

g

,

where IP ADDRESS is the address of the target (which could be the host itself), the SECURITY PROTOCOL is either AH or ESP, these two security protocols are described in detail in the RFC's [2, 3]

AH - RFC 2402 ESP - RFC 2406

(18)

are as shown in the gure. The authentication data in the AH header can range from 16 bytes (minimum) to any length xx bytes depending on the authentication algorithm.

I P H e a d e r

S e c u r i t y P a r a m e t e r I n d e x ( S P I ) S e q u e n c e N u m b e r F i e l d

I P P a y l o a d

16 - xx Btes 4 B t e s 4 B t e s

2 0 B t e s N e x t P r o t ( 1 ) _{L e n ( 1 )} _{R s v d ( 2 )}

A U T H D a t a - S u c h A s S i g n a t u r e V a r i a b l e

I P H e a d e r 2 0 B t e s

S e c u r i t y P a r a m e t e r I n d e x ( S P I ) 4 B t e s S e q u e n c e N u m b e r F i e l d 4 B t e s

P a d

(0 - 255) _{L e n ( 1 )} P a d

P r o t ( 1 ) N e x t I P W i t h A H - T r a n s p o r t

I P W i t h E S P - T r a n s p o r t

A u t h D a t a - O p t i o n a l

E n c r y p t e d D a t a

Figure 2.1: How the AH and ESP encapsulation look

(19)

192.168.3.2

Host B Host A

192.168.3.4

SA :

Dest Addr : 192.168.3.4 Sec Proto : IPPROTO_ESP SPI : 0x165

Algo : DES-CBC

SA :

Sec Proto : IPPROTO_ESP Dest Addr : 192.168.3.4

SPI : 0x165 Algo : DES-CBC Key : KeyString Key : KeyString Selectors and Other info Selectors and Other info

SA Direction

Figure 2.2: How the SA information Looks in an SADB

The depicted SA encrypts all the packets going from A to B using the DES-CBC algorithm (and using the Key "KeyString"). To encrypt the data from B to A, a similar SA with a dierent SPI value should be setup on both A and B. The Selector and other information contain details of the selector values (such as port values, transport protocol etc) and the algorithm dependent parameters such as the initial vector (IV) for the DES-CBC algorithm.

2.2 Security Modes

The AH and ESP security protocols can be employed in one of the following two modes :

(20)

In Transport Mode the AH/ESP headers appear immediately before the transport layer headers and do not protect the IP header completely, only AH aords some security to the IP header while ESP does not protect the IP header in any way. In Tunnel Mode the Entire IP packet is secured by the AH/ESP and an additional IP header is appended outside the AH/ESP headers for the sake of routing. The following gure illustrates an IP packet secured in Transport mode and Tunnel mode respectively.

TRANSPORT MODE

TUNNEL MODE IP

Header

AH Header

ESP Header

Transport

Header Payload data

ESP Trailer

Outer IP

Header AH_Header _HeaderESP _HeaderIP Transport_Header Payload data _TrailerESP Figure 2.3: Transport and Tunnel Modes

2.3 Security Databases

(21)

processing, the SAdb is searched rst based on the SPI carried in the IPSEC headers. Then, the SPdb is consulted through a back pointer to the SPdb from the SAdb, if every step goes ne, it is ensured that the incoming packet does not violate the security requirements being specied for this networking system. It may be noted here that most of the current implementations of IPSEC are based on the notion that the applications will directly request the SA managing entity to setup an SA but as the trend hints this model is to be replaced by a completely trac driven SA establishment approach in which the SA's will be established based on the requests from the policy engine.

2.4 SA management, Key Exchange and Key Management

As per the requirement of security architecture the following modes of SA estab-lishment and key management MUST be supported.

a) Manual Techniques

:-In this case the system administrator manually congures each system with the keying material and the security association management data so that an SA comes into existence. This scheme seems feasible with smaller networks but becomes cumbersome when we need to establish numerous SAs at once and manage them.

b) Automated SA and Key Management

:-This is required for on-demand creation of SAs and to facilitate the anti-replay features of AH and ESP. This is where the Internet Security Association and Key Manage-ment Protocol (ISAKMP/IKE) comes into picture. This protocol is described in detail in the RFC - 2408 ISAKMP and a set of associated RFC's.

(22)

new SAs through ISAKMP daemon is not standardized (i.e it is implementation dependent). We have come across the following three mechanisms among the various products we have looked at

1. Using a Non-standard Port

The ISAKMP daemon could possibly listen on one of the non standard UDP ports for requests to establish an SA. The user applications will then send their requests to this port, for example in the FreeSwan package the ISAKMP daemon listens on port 501 for requests to setup an SA.

2. Trac Driven

The policy engine (which resides in the kernel) dynamically checks each outgoing packet against the security policy of the system to see if any security should be pro-vided, in case a packet requires security and no SA exists to provide the required security then the policy engine will prompt the ISAKMP daemon to setup an SA. This is an important feature of IPSEC framework.

3. ISAKMP Start up

The other way is to setup the ISAKMP conguration parameters such that at the start up time the ISAKMP daemon will automatically negotiate the SA with the peer daemon.

The overall Security Architecture picture is shown in the gure 2.4.

At the end of an SA negotiation between two ISAKMP daemons, both of the ISAKMPd's possess the IPSEC SA management information which is written into the ker-nel SAdb (Security Association Database). Once the SA management information is in place in the kernel SAdb the newly established SA comes into existence and all the further IP trac that comes under the purview of this SA will be secured as per the requirements put down in the SAdb (i.e the encryption and authentication algorithms such as DES and SHA will be employed as a part of AH, ESP or both).

SA Lifetime and Tear down

(23)

(24)

ISAKMP Daemon

TCP/UDP

IP

Socket Layer

Link Layer Protocol

Application Protocol A P I

SADB SPDB

Engine & Policy

IPSEC Definition

DOI

Certificate Management Process

Request SA Key Exchange Definition

Application Program

Policy Management Process

Interact With Policy Server Peer to Peer

ISAKMP Traffic on UDP port 500

(25)

Chapter 3

Motivation

The currently available IPSEC based solutions in the market are predominantly Virtual Private Networks (VPNs). VPNs provide Network-to-Network security by setting up SAs in the tunnel mode between Gateways of the networks, and these tunnels secure the aggregate data that ows from one network to another through these gateways. On the other hand, the IPSEC capabilities in providing host-to-host security have remained largely untapped and undeveloped. Here we investigate the options of bringing the transport and tunnel mode capabilities of the IPSEC one step closer to the user applications in the host-to-host security framework and the implications of developing "security and policy conscious" applications based on the IPSEC in the coming years.

Apart from the inter-network security concerns between the gateways, we also have the inter-host OR inter-application security concerns. For applications and protocols such as email, SNMP, LDAP and several others, the application-to- application security is a chief concern. Also the home PC owners and mobile hosts will have requirements dierent from those of organizations and corporations securing their data through trusted subnetworks and VPN's. For users such as the home PC owners, the nancial transactions through the web, or purchases through the web require assured security between the end applications.

(26)

protocols with the proposed extension to the socket API. As the mood in the Industry is to suit the already existing applications such as telnet to work in combination with the security protocols (e.g telnet over TLS). It can be safely assumed that sooner or later most of the applications will be re-engineered to adapt to the security situations. We expect that the applications make use of the API extensions proposed here instead of other redundant security protocols.

These discussions make it clear that one of the main motivations for proposing the extension to the API are to overcome the duplication of security services at every network layer and for every new application (this is the current trend in IETF, e.g Transport Layer Security is handled separately and SNMP security is handled separately), hence this thesis is an eort toward demonstrating that the IPSEC is sucient in providing security services for all ap-plications with the proposed Socket API extensions. Also more importantly the following sections describe the shortcomings of the IPSEC functionality from the point of view of certain classes of application programs and users, and this becomes the prime motivation for this API extension.

3.1 The In bound Trac Model

At the time of processing the in bound IPSEC trac, all the IPSEC headers are discarded at the IP layer, And When the applications do receive data, the data is devoid of all IPSEC headers, thus there is no way of knowing whether the incoming packets were secured. If the packets were secured, then it is also hard to gure out what level of security was aorded and which end host or Security Gateways provided the security.

(27)

Under normal circumstances it is hard to trust the source address in an IP packet be-cause this can be easily tampered with and attacks such as denial of service attacks can be launched on application servers under the pretext of false IP addresses, the proposed extension helps in cases such as these in the following two ways ;

1. Filtering out attack packets:

With PHIL API in place an application program can issue commands on an opened socket to prevent packets from certain addresses to reach it, these could be the packets that could be choking the server performance. With the PHIL information at hand an application can decisively know who or at least from which nearest router the unwanted packets emerge.

2. Source Address Tracking:

The retained PHIL information can be utilized by next generation security systems such as the attack source detection (a prototype of this is discussed in the chapter 7 of this thesis) systems to track down the source of attack by dynamically setting up security associations.

When there are SA bundles that have secured an IP packet the IPSEC headers provide more then security to the IP packets, the IPSEC headers in fact reveal the path traversed by the IP packet and this is a major attraction to the Attack analysis and attack source detection applications because now we have a trusted path or route discovery mechanism on a packet by packet basis. The following is an SA conguration example (see gure 3.1) where the packets path of traversal is revealed from its IPSEC headers at router 4 (R 4). router 4 can exactly determine whether the packet at hand came through R2 or R3 (in this example it is possible to determine the same by the network interface through which the packets arrived, but this is useful only for those routers that are one hop away, for routers at more then one hop away a better mechanism such as usage of SA's is needed).

(28)

R 1

R 2

R 3

R 4 S A 1

SA 2 _{SA 3}

SA 1 : R1 - R4 SA 2 : R2 - R4 SA 3 : R3 - R4

Figure 3.1: Using SA's to establish path

The above features of the extended API can be put to use in many ways, typically a TCP application such as Telnet can be altered to accept a login session only if the incoming login request packets are authenticated, thus a mobile user can be forced to conform to security requirements even if the Gateway of his/her current network does not have IPSEC capabilities. Such a capability would potentially thwart stray hackers from breaking in from obscure locations even when they know the passwords.

(29)

3.2 The Out bound Trac Model

The IPSEC security architecture document describes the usage of the following selector elds in uniquely identifying an SA,

1. Source and Destination IP address 2. Source and Destination Port numbers 3. Transport protocol in use

4. SPI (security parameters index) 5. User ID

6. Data Sensitivity Label

Although the RFC species six usable selector elds the VPN requirements do not need all the above selectors, most of the IPSEC products that we have surveyed (which aim at VPN capability) make use of only the rst four selector elds, even the FreeSwan IPSEC package uses only the rst four selectors in its implementation, also the way these selectors are made use of is implementation specic. One common diculty in incorporating all the six selectors is that the user ID and the data sensitivity level do not form a part of any of the transport headers and thus it is not easy to convey these elds to the IP layer where the IPSEC processing is carried out. And this is precisely the missing link to make an SA bind to a particular socket and we have implemented this feature into the FreeSwan IPSEC implementation thus completing the application-to-application security model.

Although the security Architecture document proposes the usage of the data sensi-tivity selector it is only mandatory to environments providing multi-level sensisensi-tivity (MLS) to information ow, the provision of this sensitivity level would help in the following sce-nario's

(30)

2. When the sensitivity of an application's data varies over a sessions lifetime, such applications might want to encrypt only a small portion of their data which is sensitive in nature while letting the most of the trivial data pass as clear text, this could save a lot of CPU cycles which otherwise would be wasted securing the trivial data. This could apply to database servers which need to transfer large amounts of data (of which only a marginal portion of data is sensitive in nature), so the choice of security properties can be left to the discretion of the application.

for example, the selective encryption scheme for MPEG streams will only be possible if we have such mechanism. (please note that the MPEG example might potentially save a lot of bandwidth. But, it involves "multi-casting" for pay-per-view.)

Related to DiServ, I might want to distinguish between my data such that some part will receive a better service (AF-11, e.g.,) which may less likely to be dropped. But all the packets will share the same per-ow info/header. Without dierent SAs, all my packets will receive the same level of service.

3. Since "encryption" consumes a lot of CPU cycles it may be worthwhile to let the ap-plication decide when it wants to use "heavy encryption" as against "light encryption" thus providing a dynamic option of varying its security properties within a marginal exibility that the SPdb may provide, this in turn could help tune the system perfor-mance under heavy loads.

4. When the session priority varies depending on who the user is. An FTP server might wish to transmit the data in clear text for anonymous FTP sessions but for the non-anonymous FTP sessions it might wish to send the data securely thus choosing the security properties based on the request at hand.

(31)

be achieved simply by extending the socket API and a moderately exible security policy. This socket API extension applies both to the UDP and TCP trac, we make it explicit where the UDP and TCP dier in the PHIL API context. Also, it is clear that the incoming IPSEC packets are processed based on the SPI information carried in the IPSEC headers and hence there will not be any confusion as to which SA was employed for a particular packet (from among several possible SAs). That is, the use of multiple SAs does not pose a problem while processing the in bound trac.

3.3 SPDB and its Flexibility

Since an SPDB is the underlying security backbone for a systems security policy here we discuss about what an SPDB is and about the repercussions of having a stringent security policy versus that of a exible one.

An SPDB is essentially the description of the systems security policy in terms of a policy specication language (such as the one described by draft-ietf -ipsec-spsl-00.txt). The security policy is interpreted by several system entities (such as rewall mechanisms and IPSEC) dynamically during their operation and any trac not conforming to the security policy is not entertained. Therefore it is important to describe the security policy in such a way that the system performance is ne tuned. A rigid and myopic security policy can cause system performance degradation, for example specifying that all trac between two host systems be secured strictly would mean even trivial trac such as anonymous FTP would be secured thus degrading system performance, what is in eect best is a ne blend of exible security policy and good discretion of application programs in choosing their security properties.

Typically a security policy rule (which describes an SA) in terms of the speci-cation language will consist of the attributes representing the "selectors" and the "action" associated with these selectors, as a simple example to specify a policy that all outgoing trac from source IP address X to destination Y and with source and destination ports being A and B respectively be encrypted with DES we would enter the following policy;

(32)

xport-proto: 6

ipsec-action: esp cipher des

In case we need another SA to aord Authentication then we would add another action attribute such as

ipsec-action: ah integrity md5

In this case both the ipsec actions would be treated as a "bundle" and the above trac will be aorded both Encryption and Authentication.

Providing the SA granularity up to the port level does not necessarily provide the best system performance tuning. This is because we might want to thwart trac analysis by multiplexing application data over several SAs or provide a choice of multiple SAs for a client and server on the same port and same host pairs (for reasons already mentioned in sec 3.1). An additional prospect is the possibility of several applications sharing a bank of SAs between two end systems, it is possible to describe such situations using the policy language as we will describe in the following (some what hypothetical example).

Consider an FTP server on the host with IP address X , if a lot of users on host Y log onto host X for FTP operations and if the FTP server wishes to distinguish among the users based on the users priority (and hence the security level) associated, then this can be achieved by the following:

policy-name: policy2 src: X port 20 dst: Y

xport-proto: 6

ipsec-action: esp cipher des ipsec-action: esp cipher idea

(33)

SAs that form an SA bundle and those that form a "set" from which at least one SA is to be chosen, such a exibility will be great help in ne tuning the system performance.

(34)

Chapter 4

Proposed Extensions to the Socket

API

4.1 Objectives

The objective is to propose API functions as extensions to the current set of socket API calls to retain the information about the IPSEC headers on a packet by packet basis and thus accomplish the trusted path discovery mechanism. The following extensions to the socket API are intended to be used with either UDP/TCP sockets for retrieval of IPSEC header information. From the framework of IPSEC we realize that it is sucient if we can link the data received at the application layer with some particular SPI value or values in the SADB. Thus the design is based on the logic that the SPI value/values of the SAs over which the data was received are all that is needed at the application layer , the rest of the information such as the destination address can be retrieved from the kernel SADB through system calls. The extended socket API calls apply both to TCP and UDP sockets until unless it is stated to be for either one of them specically, there are some peculiarities about the way TCP works and these shall be discussed at length.

4.2 API Extensions

(35)

because the need for security in a lot of cases could be uni-directional (actually this was the motivation for dening SIMPLEX SA's in the rst place), also it is perfectly possible to use dierent security protocol and algorithms in either direction, therefore receive operations and send operations on a socket are treated separately in the following two subsections respectively. Figure 4.1 shows the broad perspective in which the PHIL API is intended to be used, it depicts a simple TCP client-server mechanism which has been modied to make use of PHIL mechanism.

socket ( )

bind ( )

listen ( )

phil_enable ( )

phil_accept ( )

phil_sendto ( ) phil_recvfrom() connect ( )

phil_recvfrom() phil_sendto ( )

socket ( )

phil_enable ( )

close ( )

close ( ) phil_recvfrom() PHIL Socket functions for

elementary TCP client - server

phil_enable ( )

child sock parent sock

establish connection

data

close connection

(36)

4.2.1 API Functions for the Incoming Trac

x1. A TCP or UDP socket opened with a socket system call should rst be enabled to

receive the PHIL information along with the application data. This enabling is carried out by the following function call

int phil enable( int sockfd, int mode )

Input:

It takes the socket descriptor value sockfd and integer mode as input parame-ters

Returns:

It returns a non zero error value if the call failed otherwise it returns a value ZERO.

Description:

(37)

x2. At any point during a session a socket which was PHIL enabled can be disabled by

the following function call

int phil disable( int sockfd )

Input:

It takes the socket descriptor value as an input parameter Returns:

It returns a non-zero error value if the call failed otherwise it returns a value ZERO.

Description:

Disabling a socket will revert a socket to its normal mode of reception wherein no PHIL information is retained and passed up the kernel network stack. Is-suing a phil disable() call on a socket which was not enabled priorly has no eect on the socket. some of the other phil functions can be continued to be used after a disable call and these functions will behave similar to the normal API calls.

x3. To receive PHIL information in a full edged mode a socket which is already PHIL

enabled can be set to EXHAUSTIVE(in case the NON EXHAUSTIVE mode was set in the rst place) mode in which the PHIL information consists of all the selector elds that were processed in the IPsec layer. To set the EXHAUSTIVE mode the following call should be made

int phil set xmode(int sockfd)

Input:

socket descriptor value Returns:

A non-zero value on error and a ZERO value on success Description:

(38)

x4. To revert a socket from EXHAUSTIVE to NON EXHAUSTIVE mode the following

call is issued;

int phil reset xmode(int sockfd)

Input:

Socket descriptor value Returns:

A non-zero value on error and a ZERO value on success Description:

Sets the phil receive mode to NON EXHAUSTIVE mode.

x5. Every socket that is open has the option of rejecting data that arrived without being

secured in any way, such data can be forced to be ltered out at the kernel level by setting the socket receive mode to SECURE mode, this is done through the following PHIL call

int phil secure(int sockfd)

Input:

A non-zero error value on error and ZERO value on success Description:

Forces the socket to receive data that was secured in some way, all the other un-secured data is discarded at the kernel. This checking is enforced before the packets are queued at the socket queue and this saves both system resources and time that would otherwise be spent in processing the unsecured packets.

x6. A socket that was set to receive only secured data can be reset to normal mode of

receiving all data by the following PHIL call

(39)

Input:

A non-zero error value on error and ZERO value on success Description:

Undoes the action of the phil secure call, after a phil secure call the normal API functions will also be aected such that they will now receive only secured data, to undo this eect unsecure call should be used rst.

x7.

int phil accept(parameters to accept(), char *phil buf,

int phil len)

Input:

The parameters of the corresponding standard socket API call accept() and additionally the phil buf buer and its length phil len.

Returns:

In addition to the return values of the corresponding normal API call accept() this call returns phil buf, which is a character buer that contains the PHIL information.

Description:

A phil accept() call is intended to be used by TCP servers operating in the concurrent mode. The phil accept() call used over the parent socket will pro-vide information about the peer party which can be trusted based on the PHIL information. The server can then decide whether or not it should accept the new request (based on some policy).

x8. The following call is a modication of data receive call, this call returns The data

received plus the PHIL of the SA over which the data was received.

int

(40)

Input:

The parameters of the corresponding standard socket API call recvfrom() and additionally the phil buf buer and its length phil len and integer pointer dsegs.

Returns:

In addition to the return values of the corresponding normal API call recvfrom() this call returns phil buf, which is a character buer that contains the PHIL information, the integer value dsegs is the number of TCP data segments that constitute the total data bytes that were read from this call.

Description:

A phil recvfrom() call is intended to be used in place of a recvfrom() call to retrieve the data plus PHIL, this call is to be used by both UDP and TCP ap-plications. The phil buf points to one of the two PHIL information structures depending on the receive mode that was set, it points to the following PHIL information structure when the PHIL mode is NON EXHAUSTIVE

typedef struct phil ne

f

unsigned int nos;

unsigned long spi[nos] ;

g

phil ne ;

(41)

typedef struct phil e

f

unsigned int nos;

spi struct ssp[nos];

g

phil e ;

where ssp is an array of spi structs where each spi struct represents the fol-lowing set of information

typedef struct spi struct

f

unsigned long spi ;

unsigned long dst addr ;

unsigned long src addr ;

unsigned short dst port ;

unsigned short src port ;

unsigned short xprot ;

unsigned int data len ;

unsigned int sec proto ;

spi struct *next ssp ;

g

(42)

data len represents the number of data bytes that are covered by the above phil information, in case of UDP each recvfrom() call dequeues exactly one packet from the sockets input queue and passes it up and therefore the data len value matches the total number of bytes that were read, in case of TCP the recvfrom() call returns as many bytes as it can from the outstanding packets that are in the sockets receive queue, which means there is a kind of data merging across the packets of a TCP application and it is quite possible that each of these packets could have been secured in a dierent way because of the dierent routes that these packets followed, in such a case the dsegs parameter gives the number of data segments that were merged together to form the data that was returned from this call. When the value of dsegs is more then one (possible only for TCP), the phil information has dsegs number of phil e structures one following the other and each phil e structure itself contains nos number of spi structs, and data len associated with each spi struct represents the portion of the data covered by this particular SA. The sample results in chapter 8 show the detailed phil information for both TCP and UDP.

x9. For applications which need to lter out the incoming trac as per some rules can do

so with the help of the following PHIL call

int phil set lter(int sockfd,rule * rp, int size, int op )

Input:

Socket descriptor value sockfd, lter rule structure rp, size of the lter rules and the operation to be carried out.

Returns:

A non-zero value on failure to set the lter and a ZERO value on success. Description:

(43)

from specic SA's. An UDP application server can set the lters to selectively accept requests from the clients, in case of TCP, the concurrent server should set the appropriate lter on the parent socket descriptor value to selectively entertain connection requests. Each socket has a lter table associated with it to which new lter rules can be added as and when needed and occasionally the lter table can be ushed, the op parameter in the set lter() should be set to OP ADD while adding a rule and should OP FLUSH to ush the lter table. The lter rule structure is as following.

typedef struct RULE

f

unsigned int act;

unsigned long src addr;

unsigned short src port;

struct RULE *nr;

g

rule ;

the act parameter describes the action to be associated with the source address and port given by src addr and src port elds, the action currently permitted are ACT DISALLOW to forbid any network transactions with the specied address or port.

4.2.2 API Functions for the Outgoing Trac

x1. For a socket, the outgoing data can be directly linked to one or more SA's by binding

the spi values of these SA's to the socket, this achieves the main purpose of associating an SA to a socket thus providing socket layer security which is the main concern of many applications , this binding is carried out through following bind call;

(44)

Input:

Socket descriptor value and the spi array and its size. Returns:

ZERO on success and non zero error value on failure Description:

The bind call merely records a possible set of SPI's that could be used by this socket in its sessions, the actual and specic value for each send operation can be dierent and should be specied at the time of a send call, also specifying a set of SPI's through the phil bind() call does not mandate a socket to send its data securely all the time.

x2. The bind operation can be undone by

int phil unbind(int sockfd)

Input:

ZERO on success and non zero error value on error Description:

This call is similar to a ush operation and clears any association of a socket with SPI's, this call can be used before re binding a socket with new SPI values.

x3. The following call is a modication to the data output call.

int phil sendto(parameters to sendto(), long *spi arr , int size)

Input:

In addition to the corresponding normal API call sendto() an array of long numbers representing the spi and the size of the array are passed.

Returns:

(45)

Description:

The spi arr array describes the SPI value of our preference over which to send our data (in the case where we have a choice of sending the data over several possible SAs). If the application is not aware of the possible SAs over which it could send its data then it can query the SADB for the SPI values through the query spi() call described in the next section. The value of the SPI's should be a subset or equal to the SPI values that were bound to the socket using the phil bind() call, if we choose only one spi among all the spi's that were bound then the outgoing packet will be applied security mechanisms that correspond to that spi. The spi eld can be used to specify an SA of our preference or to choose an SA among several possible SAs. Through this output call it is possible to multiplex the data from an application over several SAs thus providing dierent levels and features of security to dierent data types. Here it is emphasized that the applications preference of sending its data over an SA will be honored only if it conforms to the SPDB. In case of conict between SPDB and an applications preference the data will not be sent and the user should be notied.

4.2.3 Miscellaneous Calls

x1. The following function is helpful for debugging

int phil debug(int action)

Input:

Integer value which describes the action Returns:

ZERO on success and non zero error value on failure Description:

(46)

o by setting the action to PHIL DEBUGOFF. When in on mode the kernel prints out a lot of PHIL related activities that go on at the kernel level.

x2. From the previous function calls it is realized that an application might want to know

the availability of an SA and their SPI values before they send the data. The following call lls the need for such a request.

int phil qspi (struct sockaddr* src, struct sockaddr * dst,

char * buf, int size, int *num)

Input:

Source and destination addresses and size of the buer to hold the spi values Returns:

ZERO on success and non zero error value on failure, on success it returns the spi values in the buer and the number of spi's returned in the integer num Description:

When no SA's exist to protect the data between the given source and desti-nation address an error is returned. Since the SA's are simplex in nature to query the outgoing SA's the destination address is that of the remote host, to query the incoming SA's the destination address is that of the local host itself. It may be noted that in case of VPN s the source ip address is most likely to be that of the security gateway on which the application is running. If there are one or more SAs that match the source and destination IP addresses then they are returned through the spi structure as a linked list. The security protocol and the spi value returned in the spi struct will help the application in deciding which SA to use.

x3. Based on the SPI values that the input functions return , the applications can query

the SADB for the source of authentication, this way the application can arrive at trusted route discovery for a particular data element.

(47)

Input

Returns

ZERO on success and non zero error value on failure, on success it returns the SA information in the buer.

Description

This function is used to query the SADB for detailed information about the SA that is represented by the spi value which is passed as a parameter.

4.2.4 Error Values Returned

When the phil xxx() calls fail in the kernel due to any reason then they return a negative error value, each of the error value is representative of the anomalous condition that occurred in the kernel. The following are the possible error values that could be returned. -P BADF A bad le descriptor was passed.

-P NOSOCK No socket corresponding to the socket descriptor exists. -P INVAL An invalid buer size was passed.

-P VER AREA Buer passed has inconsistency (check log messages). -P SIZ Size error, see error messages.

-P K2U Kernel to user space memory transfer failed. -P U2K User to Kernel space memory transfer failed. -P NO EROUTE No eroute entry exists in the eroute table. -P NO TDB No tunnel descriptor block exists in the kernel.

-P BIND phil bind() call was used again without un binding rst. -P BUF Buer size is inadequate.

(48)

Chapter 5

Design, Implementation and

Performance of PHIL API

5.1 Linux Operating System

Linux operating system is a avor of Unix and is freely available for down loads from the world wide web, the Linux kernel code is very stable and plenty of news groups and mailing lists on the web provide helpful information about the operating system and this was why we chose Linux as our platform for Implementing the PHIL API, besides we have a fairly good Implementation of IPSEC for Linux by RSA. The kernel version 2.0.35 was made used on a PC with Intel Pentium 2 processor.

5.1.1 System Call Architecture in Linux Kernel

The range of functions in the operating system is made available to the processes by means of system calls. A system call works on the basis of dened transition from User Mode to System Mode. In Linux, this is realized through the usage of interrupts and a dedicated interrupt (number 0x80 )is used for this purpose. Figure 5.2 illustrates what goes on in the Operating System when a system call (such as a sendto( ))is issued.

5.1.2 Memory Management in Linux Kernel

(49)

User Programs & Applications

Application Level Kernel Level

Hardware Level System Calls

Process Management Management Memory File Systems Device Control Networking Architecture dependent Code Memory Manager

FS types

Block Devices

Character Devices

Network Subsystem

IF Drivers

CPU RAM Disks &

CDs Console Network Interfaces Concurrency Multitasking Virtual Memory

Files & Directories

TTY & Device Access

Connectivity

Kernel parts

Features Implemented Software Support Hardware Control Hardware

Figure 5.1: Split View of the Kernel

(50)

I n t e r r u p t 0x 8 0

S w i t c h to k e r n e l M o d e S A V E

U S E R M O D E K E R N E L M O D E

s y s __ s e n d t o ( )

s y s __s o c k e t c a l l ( SYS__SENDTO ) s e n d t o ( )

s o c k e t c a l l ( SYS_SENDTO, a r g s [ ] )

C O N T E X T

{ }

s e r v i c e p r o g r a m

R E S T O R E

Figure 5.2: System call architecture in Linux

1.

skb alloc()

Allocates the memory for an sk bu, it allocates a control block plus a data block whose size is specied at the time of the call.

2.

skb reserve()

This call prepares the data block of sk bu for writing the data.

3.

skb put()

This call writes the data bytes to the data block.

4.

skb clone()

This call creates another sk bu by copying only the control information of another sk bu (which is passed as a parameter), after cloning both sk bus point to the same data block.

5.

skb copy()

(51)

unique but have the same contents.

5.2 Implementation

In implementing the PHIL API the following approach has been followed, for the incoming trac the IPSEC implementation has been a BITS ( bump in the stack implementation) and therefore the security headers are stripped before the packet is handed over to the IP layer, which motivates one to create the PHIL information at the time of verifying and decrypting a secured packet in the BITS implementation. Since all the memory management at the Linux Kernel is handled within the "sk bu" structures, it is convenient to modify this structure to include the PHIL related information, since the same sk bu traverses the entire network stack up to the socket layer it is convenient to copy back the PHIL information from the sk bu to the user buer at the same time when the user socket data is being copied from the sk bu into the user buer. With this motive a pointer to the PHIL information structure called the spi info has been appended to the sk bu structure, Since the Number of SA's that could exist between a pair of transport hosts is not xed the memory for each element holding information about a particular SA is dynamically allocated at the time of processing an IPSEC header, and the "spi info" pointer in the sk bu structure is the starting point for the singly linked list of these memory elements called as "spi structs", the order of these spi structs in the single linked list determines the order in which the SA's were applied on the packet. This approach optimizes the memory allocation and does not burden the sk bu structure unnecessarily when no SA's exist.

5.2.1 Input Packet Processing in IPSEC Linux Kernel

The following control ow explains the processing of an incoming secured UDP packet and it also indicates the functions where modications have been carried out to incorporate the PHIL features.

(52)

the interrupt call ei interrupt() and before returning from this interrupt call a bit in the network implementations bottom half mask called as "bh mask" is set. The way bottom half functions work is explained now, the kernel checks the bh mask regularly when there are no system calls and interrupts to handle and if any of the bh mask bits is set then the service function corresponding to the set bit is called through the function do bottom half(), and this function in our case is the net bh() function. The net bh() function de-queues the packets from the input queue and passes it to the ip rcv() function where the de multiplexing of the packet to any of the transport layer receive functions takes place. In the case of ah and esp processing the packet is queued again into the system input queue after the ah or esp processing is done(to be picked up by the net bh() function again), as per this implementation a packet with multiple SA's will suer severe queuing delays at the input. The transport layer receive function will enqueue the packet into the appropriate sockets receive queue, it may be noted that for an UDP server socket the receive queue is ONLY ONE whereas in case of TCP server every client will have a dedicated receive queue at the server socket.

When the user issues a recvfrom() system call to the socket, the call handling function in the kernel locates the appropriate socket and dequeues the packet from the queue to copy the data to the user buer and return. If the phil recvfrom( ) is used instead then the PHIL associated with the data is also passed up to the application in addition to the user data. The PHIL information associated with a sk bu in the kernel is destroyed at the time of releasing the memory of an sk bu.

5.2.2 Outgoing Packet Processing in IPSEC Linux Kernel

(53)

ETHERNET e i__i n t e r r u p t ( ) e i__r e c e i v e ( ) n e t i f__r x ( ) I N P U T Q U E U E

n e t__b h ( )

d o__b o t t o m_ h a l f ( )

b h_m a s k

s e t

t r i g g e r i p __r c v ( ) t c p__r c v ( )

a h __r c v ( ) e s p__r c v ( )

R E Q U E U E

P k t F i l t e r i n g and S e c u r e O n l y c h e c k

P H I L

C r e a t e d H e r e S o c k e t

R e c e i v e Q u e u e

u d p__r c v ( )

s k b__q u e u e__t a i l ( R E C V__Q )

Figure 5.3: Input packet path in Linux IPsec Kernel

(54)

u d p__ r e c v m s g ( )

s k b__d e q u e u e ( RECV__Q )

S o c k e t R e c e i v e Q u e u e

i n e t __r e c v m s g ( ) r e c v__f r o m ( )

s y s__r e c v f r o m ( )

D e - Q u e u e

s k b__q u e u e__t a i l ( ) E n - Q u e u e

P H I L

T r a n s f e r r e d U s e r A r e a

Figure 5.4: Input packet path through the socket layer

5.2.3 Evaluation

Size of Code The implementation of PHIL API over Linux 2.0.35 and FreeSwan IPSEC ca-pability involved the following code development (only the les to which more then 25 lines of code were added are mentioned here).

Kernel Level Files :

phil API.h - 100 lines socket.c - 550 lines udp.c - 50 lines tcp.c - 50 lines ipsec ah.c - 25 lines ipsec esp.c - 25 lines

TOTAL Kernel Code - 800 lines.

Application Level Files :

(55)

sendto ( )

sys__sendto ( )

inet__sendmsg ( )

udp__send ( )

ip__build_xmit ( )

dev_queue_xmit ( )

dev->hard_start_xmit ( skb, dev )

ah__output ( ) ipsec_tunnel_do_xmit ( )

esp__output ( )

User Space

Choose SA Here

To Device

dev == ipsec / eth ) (

Kernel Space

Socket Layer

UDP Layer

IP Layer

ETHER Layer

Figure 5.5: Output packet path through the Socket Layer and Kernel

udp server.c - 140 udp client.c - 60 tcp server.c - 150 tcp client.c - 75

tpt.cnfg (shell script) - 100

(56)

Chapter 6

Sample Results, Conclusion and

Future Work

6.1 Sample Results

(57)

6.1.1 UDP Server output

Received 175 bytes of data from Client: The 175 bytes of data follow:

**Data Starts Here**

This piece of data is expected to test t he UDP server with PHIL API enabled, the UDP server should be able to display th e PHIL Information for this data along w ith this data.

**Data Ends Here**

PHIL Information for the above 175 bytes starts here No of SAs Associated = 3

---*****SA no 1 *****

SPI = 167

Source Address = 192.168.3.2 Destn Address = 192.168.3.4 Source Port = 1043

Destn Port = 6000

Transport Protocol = 17 Security Protocol = 51 *****SA no 2 ***** SPI = 166

Destn Port = 6000

Transport Protocol = 17 Security Protocol = 51 *****SA no 3 ***** SPI = 165

Destn Port = 6000

Transport Protocol = 17 Security Protocol = 50

(58)

6.1.2 TCP Server output

Received 306 bytes of data from Client: The 306 bytes of data follow:

**Data Starts Here**

Now this sentence forms the data segment ONE for the TCP server which is PHIL en abled.

And this sentence forms the data

segment TWO for the TCP server, both ONE and TWO were received at the IP layer a s separate segments but were merged by t he TCP layer, but still PHIL should be able to distinguish this.

**Data Ends Here**

PHIL Information for the above 306 bytes starts here Data Segment No = 1

No of Bytes Associated = 87 No of SAs Associated = 3

---*****SA no 1 ***** SPI = 167

Destn Port = 9500 Transport Protocol = 6 Security Protocol = 51 *****SA no 2 ***** SPI = 166

(59)

Data Segment No = 2

No of Bytes Associated = 219 No of SAs Associated = 3

---*****SA no 1 ***** SPI = 167

Destn Port = 9500 Transport Protocol = 6 Security Protocol = 50

(60)

6.2 Conclusion

This thesis surveyed the current IPSEC scenario and proposed an extension to the the existing socket API which we referred to as PHIL API, this PHIL API is aimed at boosting the usage of IPSEC in a multitude of applications and thus try to look at IPSEC from the applications point of view and encourage the evolution of security and policy conscious applications. This is aimed at eliminating a lot of duplicity in providing security features in the network stack (such as TLS, SSL etc).

The Out bound and In bound trac model in the presence of PHIL API were presented and a variety of situations that would benet from the API were discussed.

We also looked at what would be the implications of developing such a full edged API on the Security Policy of the System and we concluded that we expect the security policy to provide some degree of exibility depending on the application in question, we also illustrated with an example that this need not be a severe compromise on the security policy of the system. We stress the fact that the API is aimed at providing greater choice to applications and not at hindering the security policy from exercising its control.

A detailed description of a prototype implementation of the PHIL API was pre-sented for the Linux operating system and the associated design issues were discussed.

The PHIL API is also intended to be a powerful aid in the development of next generation security applications such as attack analysis and attack source detection. An attack source detection mechanism (DECIDUOUS) was explained and the usage of PHIL for its purpose was discussed in detail.

6.3 Future Work

(61)

Chapter 7

Example Application - 1 :

DECIDUOUS

7.1 What is DECIDUOUS

DECIDUOUS is a security management framework for identifying the sources of network-based intrusions. The rst key concept in DECIDUOUS is dynamic security asso-ciations, which eciently and collectively provide location information for attack sources. DECIDUOUS is built on top of IETF's IPSEC/ISAKMP infrastructure, and it does not introduce any new network protocol for source identication in a single administrative domain. It denes a collaborative protocol for inter-domain attack source identication. The second key concept in DECIDUOUS is the management information integration of the intrusion detection system (IDS) and attack source identication system (ASIS) across dierent protocol layers. For example, in DECIDUOUS, it is possible for a network-layer security control protocol (e.g., IPSEC) to collaborate with an application-layer intrusion detection system module (e.g., IDS for the SNMP engine). In this chapter, we present the motivations, design, preliminary prototype implementation, and security analysis of the DECIDUOUS framework.

(62)

technolo-gies. These security services are very valuable in protecting hosts against network-based attacks launched remotely by an intruder. However, identifying the source of such attacks remains dicult. Today, a victim must rely on tools not intended for this purpose, such as

traceroute and finger, which are at best only minimally suitable for tracing an attack

source. The objective of the DECIDUOUS project is to securely, practically and systemat-ically identify attack sources by utilizing existing network security protocols and services. Specically, the IPSEC authentication and encryption services are used by the security management module to trace the source of an attack. The DECIDUOUS system deduces the source identication information from the end-point locations of the current security associations in the attacking packets. This leads to the concept of

dynamic security

associations (SAs)

in DECIDUOUS: in order to eciently identify the attack sources, DECIDUOUS will

dynamically decide

where and when to establish security associations through IPSEC/ISAKMP [5]. Thus, DECIDUOUS does not introduce any new protocol under a single administrative domain. And we only need to run DECIDUOUS as a daemon process on network entities we would like to protect.

7.2 Network-based Intrusions

(63)

expensive and usually slows down the network performance even when no attack exists. It is not uncommon for the intruder to simultaneously control many entities distributed over the whole network system, or even worse, across dierent administrative domains and legal systems. Under this situation, the attacker can coordinate all the compromised entities to collaboratively launch attack packets. For example, the TCP SynFlood attack against a web server running on a Linux PC requires about 200 vicious SynRequest packets being launched to the victim's port 80. With only one compromised network entity (i.e., only one attacking point), 200 attack packets, even with totally randomized source IP addresses, need to be sent from the same source (e.g., a network interface card). This burst of 200 attack packets, especially from the same source, might trigger the anomaly intrusion detec-tion module running on a neighboring network entity. On the other hand, if we have 20 compromised network entities, then each of the 20 entities only needs to inject 10 vicious packet in average. Clearly, the attack source(s) for the latter case, \i.e., a coordinated attack," is relatively harder to identify and isolate.

7.3 Intrusion Detection, Attack Source Identication and

Response

Currently, network based intrusions are not handled systematically, and usually human system administrators must be heavily involved. Typically, a system administrator, after hearing some complains over the phone or emails, needs to spend a signicant amount of time to check various log les. He then might use existing utilities like traceroute or tcpdump. If the suspected attack source is in another domain, he most likely will make a few more phone calls to get some help from the administrators in another organization. Even after all these eorts, it is still not always possible that the true attacker will be identied. In order to deal with network-based intrusions systematically, three logical system components need to be integrated and they must collaborate:

Intrusion Detection System (IDS):

The main objective of an IDS is to

decide

, maybe with a probability attribute, whether an observed network packet (or a sequence of observed network packets) forms an

attack instance

or not.

(64)

while another IDS may be in the application layer to identify attacks that can only be detected eciently in the application layer. A sophiscated IDS should be able to correlate intrusion information in dierent layers.

Attack Source Identication System (ASIS):

Under our DECIDUOUS framework, the IDS normally does not know the attack source(s) even after it detects the at-tack packets. The key problem is that the source IP address in general can not be trusted. The objective of an ASIS is to utilize the information provided by IDS mod-ules from dierent layers and to identify where the attacks were coming from. One unique feature about our approach is that our ASIS module tries to force the attacker to reveal some new location information about the attack sources themselves on ev-ery single attack instance being launched. In other words, if the attacker is forced to launch many attack instances (i.e., persistent attacks), the ASIS module can identify the source(s) very quickly.

Intrusion Damage Control System (IDCS):

The objective of an IDCS is to control and repair the damage caused by the attacks detected and identied by the IDS. The IDCS module is very important in handling with hit-and-run attacks. If the IDCS can repair the damage in real-time, then the attacker needs to either re-launch a similar attack or give up on attacking. If the attacker needs to frequently re-launch attacks from the same set of attacking points, we have forced the attacker to perform persistent attacks.