Majordoc Rev 6

1. INTRODUCTION

1.1 Network

In information technology, a network is a series of points or nodes interconnected by

communication paths. Networks can interconnect with other networks and contain sub

networks. The most common topology or general configurations of networks include the bus,

star, Token Ring, and mesh topologies. Networks can also be characterized in terms of

spatial distance as local area networks (LANs), metropolitan area networks (MANs), and wide

area networks (WANs). A given network can also be characterized by the type of data

transmission technology in use on it (for example, a TCP/IP or Systems Network Architecture

network); by whether it carries voice, data, or both kinds of signals; by who can use the

network (public or private); by the usual nature of its connections (dial-up or switched,

dedicated or no switched, or virtual connections); and by the types of physical links (for

example, optical fibres, coaxial cable, and Unshielded Twisted Pair). Large telephone

networks and networks using their infrastructure (such as the Internet) have sharing and

exchange arrangements with other companies so that larger networks are created. There

are many types of computer networks, including:

1.1.1 Local-area network (LAN):

A local area network (LAN) is a computer network covering a small physical area, like

a home, office, or small group of buildings, such as a school, or an airport. Current wired

LANs are most likely to be based on Ethernet technology, although new standards like ITU-T

G also provide a way to create a wired LAN using existing home wires (coaxial cables, phone

lines and power lines).

1.1.2 Wide-area network (WAN):

A wide area network (WAN) is a computer network that covers a broad area (i.e. any

network whose communications links cross metropolitan, regional, or national boundaries).

Less formally, a WAN is a network that uses routers and public communications links.

Contrast with personal area networks (PANs), local area networks (LANs), campus area

networks (CANs), or metropolitan area networks (MANs), which are usually limited to a room,

building, campus or specific metropolitan area (e.g., a city) respectively. The largest and

most well-known example of a WAN is the Internet. A WAN is a data communications

network that covers a relatively broad geographic area (i.e. one city to another and one

country to another country) and that often uses transmission facilities provided by common

Secure AODV VS Trusted AODV Protocols for MANET routing security 1

carriers, such as telephone companies. WAN technologies generally function at the lower

three layers of the OSI reference model: the physical layer, the data link layer, and the

network layer.

1.1.3 Campus-area network (CAN):

A campus area network (CAN) is a computer network made up of an interconnection

of local area networks (LANs) within a limited geographical area. It can be considered one

form of a metropolitan area network, specific to an academic setting. In the case of a

university campus-based campus area network, the network is likely to link a variety of

campus buildings including; academic departments, the university library and student

residence halls. A campus area network is larger than a local area network but smaller than

a wide area network (WAN) (in some cases).

1.1.4 Metropolitan-area network (MAN):

A metropolitan area network (MAN) is a network that connects two or more local area

networks or campus area networks together but does not extend beyond the boundaries of

the immediate town/city. Routers, switches and hubs are connected to create a metropolitan

area network.

1.1.5 Personal area network (PAN):

A personal area network (PAN) is a computer network used for communication

among computer devices close to one person. Some examples of devices that are used in a

PAN are printers, fax machines, telephones, PDAs and scanners. The reach of a PAN is

typically about 20-30 feet (approximately 6-9 meters), but this is expected to increase with

technology improvements.

1.1.6 Global area network (GAN):

A global area networks (GAN) specification is in development by several groups, and

there is no common definition. In general, however, a GAN is a model for supporting mobile

communications across an arbitrary number of wireless LANs, satellite coverage areas, etc.

The key challenge in mobile communications is "handing off" the user communications from

one local coverage area to the next. In IEEE Project 802, this involves a succession of

terrestrial WIRELESS local area networks (WLAN).


1.2 Computer Networks

A computer network is a group of two or more computers connected to each

electronically. This means that the computers can "talk" to each other and that every

computer in the network can send information to the others. Usually, this means that the

speed of the connection is fast - faster than a normal connection to the Internet. In fact, two

computers connected over the Internet are not considered a computer network. The

merging of computers and communications has had a profound influence on the way

computer systems are organized. The concept of the ''computer centre'' as a room with a

large computer to which users bring their work for processing is now totally obsolete. The

old model of a single computer serving all of the organization's computational needs has

been replaced by one in which a large number of separate but interconnected computers do

the job. These systems are called computer networks.

Communication among network devices like computers assumes the existence of

mutually understood protocols that comprise a set of rules and structural components.

Computers must use a common protocol in order to communicate. Underlying

communication in Windows Server 2003 enterprise is the default Transmission Control

Protocol and Internet Protocol, otherwise known as TCP/IP.

1.2.1 Open Systems Interconnect (OSI):

The Open Systems Interconnect (OSI) model defines network communication in a

sequential and hierarchical fashion. It consists of seven layers, a brief explanation of which

should provide a better understanding of its conceptual underpinnings. Protocols like TCP/IP

embrace only a portion of the total conceptual model.

1.2.1.1 Physical layer:

The physical layer is concerned with transmitting raw bits over a communication

channel. The design issues have to do with making sure that when one side sends a 1

bit, it is received by the other side as a 1 bit, not as a 0 bit. Typical questions here

are how many volts should be used to represent a 1 and how many for a 0, how

many nanoseconds a bit lasts, whether transmission may proceed simultaneously in

both directions, how the initial connection is established and how it is torn down

when both sides are finished, and how many pins the network connector has and

what each pin is used for. The design issues here largely deal with mechanical,


electrical, and timing interfaces, and the physical transmission medium, which lies

below the physical layer.

1.2.1.2 Data link layer:

The main task of the data link layer is to transform a raw transmission facility into a

line that appears free of undetected transmission errors to the network layer. It

accomplishes this task by having the sender break up the input data into data frames

(typically a few hundred or a few thousand bytes) and transmits the frames

sequentially. If the service is reliable, the receiver confirms correct receipt of each

frame by sending back an acknowledgement frame. Another issue that arises in the

data link layer (and most of the higher layers as well) is how to keep a fast

transmitter from drowning a slow receiver in data. Some traffic regulation mechanism

is often needed to let the transmitter know how much buffer space the receiver has

at the moment. Frequently, this flow regulation and the error handling are integrated.

Broadcast networks have an additional issue in the data link layer: how to control

access to the shared channel. A special sub layer of the data link layer, the medium

access control sub layer, deals with this problem.

1.2.1.3 Network layer:

The network layer controls the operation of the subnet. A key design issue is

determining how packets are routed from source to destination. Routes can be based

on static tables that are ''wired into'' the network and rarely changed. They can also

be determined at the start of each conversation, for example, a terminal session

(e.g., a login to a remote machine). Finally, they can be highly dynamic, being

determined anew for each packet, to reflect the current network load. If too many

packets are present in the subnet at the same time, they will get in one another's

way, forming bottlenecks. The control of such congestion also belongs to the network

layer. More generally, the quality of service provided (delay, transit time, jitter, etc.)

is also a network layer issue. When a packet has to travel from one network to

another to get to its destination, many problems can arise. The addressing used by

the second network may be different from the first one. The second one may not

accept the packet at all because it is too large. The protocols may differ, and so on. It

is up to the network layer to overcome all these problems to allow heterogeneous

networks to be interconnected. In broadcast networks, the routing problem is simple,

so the network layer is often thin or even nonexistent.


1.2.1.4 Transport layer:

The basic function of the transport layer is to accept data from above, split it up into

smaller units if need be, pass these to the network layer, and ensure that the pieces

all arrive correctly at the other end. Furthermore, all this must be done efficiently and

in a way that isolates the upper layers from the inevitable changes in the hardware

technology. The transport layer also determines what type of service to provide to

the session layer, and, ultimately, to the users of the network. The most popular type

of transport connection is an error-free point-to-point channel that delivers messages

or bytes in the order in which they were sent. However, other possible kinds of

transport service are the transporting of isolated messages, with no guarantee about

the order of delivery, and the broadcasting of messages to multiple destinations. The

type of service is determined when the connection is established. (As an aside, an

error-free channel is impossible to achieve; what people really mean by this term is

that the error rate is low enough to ignore in practice.) The transport layer is a true

end-to-end layer, all the way from the source to the destination. In other words, a

program on the source machine carries on a conversation with a similar program on

the destination machine, using the message headers and control messages. In the

lower layers, the protocols are between each machine and its immediate neighbors,

and not between the ultimate source and destination machines, which may be

separated by many routers.

1.2.1.5 Session layer:

The session layer refers to the connectivity and management of network

applications. TCP/IP does not directly map this OSI layer. The session layer allows

users on different machines to establish sessions between them. Sessions offer

various services, including dialog control (keeping track of whose turn it is to

transmit), token management (preventing two parties from attempting the same

critical operation at the same time), and synchronization (check pointing long

transmissions to allow them to continue from where they were after a crash).

1.2.1.6 Presentation layer:

The presentation layer establishes the data format prior to passing it along to the

network application's interface. TCP/IP networks perform this task at the application

layer. Unlike lower layers, which are mostly concerned with moving bits around, the

presentation layer is concerned with the syntax and semantics of the information


transmitted. In order to make it possible for computers with different data

representations to communicate, the data structures to be exchanged can be defined

in an abstract way, along with a standard encoding to be used ''on the wire.'' The

presentation layer manages these abstract data structures and allows higher-level

data structures (e.g., banking records), to be defined and exchanged.

1.2.1.7 Application layer:

The application layer processes data received or sent through the network. The

application layer contains a variety of protocols that are commonly needed by users.

One widely-used application protocol is HTTP (HyperText Transfer Protocol), which is

the basis for the World Wide Web. When a browser wants a Web page, it sends the

name of the page it wants to the server using HTTP. The server then sends the page

back. Other application protocols are used for file transfer, electronic mail, and

network news.

1.2.2 The Transmission Control Protocol

The Transmission Control Protocol (TCP) standard is defined in the Request for

Comment (RFC) standards document number 793 by the Internet Engineering Task Force

(IETF). The original specification written in 1981 was based on earlier research and

experimentation in the original ARPANET. The design of TCP was heavily influenced by what

has come to be known as the "end-to-end argument".

As it applies to the Internet, the end-to-end argument says that by putting excessive

intelligence in physical and link layers to handle error control, encryption or flow control you

unnecessarily complicate the system. This is because these functions will usually need to be

done at the endpoints anyway, so why duplicate the effort along the way? The result of an

end-to-end network then, is to provide minimal functionality on a hop-by-hop basis and

maximal control between end-to-end communicating systems.

The end-to-end argument helped determine how two characteristics of TCP operate;

performance and error handling. TCP performance is often dependent on a subset of

algorithms and techniques such as flow control and congestion control. Flow control

determines the rate at which data is transmitted between a sender and receiver. Congestion

control defines the methods for implicitly interpreting signals from the network in order for a

sender to adjust its rate of transmission.


The term congestion control is a bit of a misnomer. Congestion avoidance would be a

better term since TCP cannot control congestion per sec. ultimately intermediate devices,

such as IP routers would only be able to control congestion.

Congestion control is currently a large area of research and concern in the network

community. A companion study on congestion control examines the current state of activity

in that area.

Timeouts and retransmissions handle error control in TCP. Although delay could be

substantial, particularly if you were to implement real-time applications, the uses of both

techniques offer error detection and error correction thereby guarantee-ing that data will

eventually be sent successfully.

The nature of TCP and the underlying packet switched network provide formidable

challenges for managers, designers and researchers of networks. Once regulated to low

speed data communication applications, the Internet and in part TCP are being used to

support very high speed communications of voice, video and data. It is unlikely that the

Internet protocols will remain static as the applications change and expand. Understanding

the current state of affairs will assist us in understanding protocol changes made to support

future applications.

TCP is often described as a byte stream, connection-oriented, reliable delivery

transport layer protocol. In turn, we will discuss the meaning for each of these descriptive

terms.

1.2.2.1 Byte Stream Delivery:

TCP interfaces between the application layer above and the network layer below.

When an application sends data to TCP, it does so in 8-bit byte streams. It is then up

to the sending TCP to segment or delineate the byte stream in order to transmit data

in manageable pieces to the receiver1. It is this lack of 'record boundaries" which give

it the name "byte stream delivery service".


1.2.2.2 Connection-Oriented:

Before two communicating TCPs can exchange data, they must first agree upon the

willingness to communicate. Analogous to a telephone call, a connection must first be

made before two parties exchange information.

1.2.2.3 Reliability:

A number of mechanisms help provide the reliability TCP guarantees. Each of these is

described briefly below.

1.2.2.4 Checksums:

All TCP segments carry a checksum, which is used by the receiver to detect errors

with either the TCP header or data.

1.2.2.5 Duplicate data detection:

It is possible for packets to be duplicated in packet switched network; therefore TCP

keeps track of bytes received in order to discard duplicate copies of data that has

already been received.

1.2.2.6 Retransmissions:

In order to guarantee delivery of data, TCP must implement retransmission schemes

for data that may be lost or damaged. The use of positive acknowledgements by the

receiver to the sender confirms successful reception of data. The lack of positive

acknowledgements, coupled with a timeout period (see timers below) calls for a

retransmission.

1.2.2.7 Sequencing:

In packet switched networks, it is possible for packets to be delivered out of order. It

is TCP's job to properly sequence segments it receives so it can deliver the byte

stream data to an application in order.

1.2.2.8 Timers:

TCP maintains various static and dynamic timers on data sent. The sending TCP waits

for the receiver to reply with an acknowledgement within a bounded length of time. If

the timer expires before receiving an acknowledgement, the sender can retransmit

the segment.


1.2.3 TCP Header Format

Remember that the combination of TCP header and TCP in one packet is called a TCP

segment. Figure 1 depicts the format of all valid TCP segments. The size of the header

without options is 20 bytes. We will briefly define each field of the TCP header below.

1.2.3.1 Source Port:

A 16-bit number identifying the application the TCP segment originated from within

the sending host. The port numbers are divided into three ranges, well-known ports

(0 through 1023), registered ports (1024 through 49151) and private ports (49152

through 65535). Port assignments are used by TCP as an interface to the application

layer.

1.2.3.2 Destination Port:

A 16-bit number identifying the application the TCP segment is destined for on a

receiving host. Destination ports use the same port number assignments as those set

aside for source ports.

1.2.3.3 Sequence Number:

A 32-bit number identifying the current position of the first data byte in the segment

within the entire byte stream for the TCP connection, after reaching 232 -1, this

number will wrap around to 0.

1.2.3.4 Acknowledgement Number:

A 32-bit number identifying the next data byte the sender expects from the receiver.

Therefore, the number will be one greater than the most recently received data byte.

This field is only used when the ACK control bit is turned on.

1.2.3.5 Header Length:

A 4-bit field that specifies the total TCP header length in 32-bit words (or in multiples

of 4 bytes if you prefer) without options, a TCP header is always 20 bytes in length.

The largest a TCP header may be is 60 bytes. This field is required because the size

of the options field(s) cannot be determined in advance.

1.2.3.6 Reserved:


A 6-bit field currently unused and reserved for future use.

1.2.3.7 Control Bits:

Urgent Pointer (URG): If this bit field is set, the receiving TCP should

interpret the urgent pointer field (see below).

Acknowledgement (ACK): If this bit field is set, the acknowledgement field

described earlier is valid.

Push Function (PSH): If this bit field is set, the receiver should deliver this

segment to the receiving application as soon as possible.

Reset the Connection (RST): If this bit is present, it signals the receiver

that the sender is aborting the connection and all queued data and allocated

buffers for the connection can be freely relinquished.

Synchronize (SYN): When present, this bit field signifies that sender is

attempting to "synchronize" sequence numbers. This bit is used during the

initial stages of connection establishment between a sender and receiver.

No More Data from Sender (FIN): If set, this bit field tells the receiver that

the sender has reached the end of its byte stream for the current TCP

connection.

1.2.3.8 Window:

A 16-bit integer used by TCP for flow control in the form of a data transmission

window size. This number tells the sender how much data the receiver is willing to

accept. The maximum value for this field would limit the window size to 65,535

bytes; however a "window scale" option can be used to make use of even larger

windows.

1.2.3.9 Checksum:

A TCP sender computes a value based on the contents of the TCP header and data

fields. This 16-bit value will be compared with the value the receiver generates using


the same computation. If the values match, the receiver can be very confident that

the segment arrived intact.

1.2.3.10 Urgent Pointer:

In certain circumstances, it may be necessary for a TCP sender to notify the receiver

of urgent data that should be processed by the receiving application as soon as

possible. This 16-bit field tells the receiver when the last byte of urgent data in the

segment ends.

1.2.3.11 Options:

In order to provide additional functionality, several optional parameters may be used

between a TCP sender and receiver. Depending on the option(s) used, the length of

this field will vary in size, but it cannot be larger than 40 bytes due to the size of the

header length field (4 bits). The most common option is the maximum segment size

(MSS) option. A TCP receiver tells the TCP sender the maximum segment size it is

willing to accept through the use of this option. Other options are often used for

various flow control and congestion control techniques.

1.2.3.12 Padding:

Because options may vary in size, it may be necessary to "pad" the TCP header with

zeroes so that the segment ends on a 32-bit word boundary as defined by the

standard.

1.2.3.13 Data:

Although not used in some circumstances (e.g. acknowledgement segments with no

data in the reverse direction), this variable length field carries the application data

from TCP sender to receiver. This field coupled with the TCP header fields constitutes

a TCP segment.

1.2.4 Connection Establishment and Termination

TCP provides a connection-oriented service over packet switched networks.

Connection-oriented implies that there is a virtual connection between two endpoints. There

are three phases in any virtual connection. These are the connection establishment, data

transfer and connection termination phases.


In order for two hosts to communicate using TCP they must first establish a

connection by exchanging messages in what is known as the three-way handshake.

The diagram below depicts the process of the three-way handshake.

Host A Host B

Send SYN seq=x In the Internet

Receive SYN

Send SYN seq=y, ACK x+1

Receive SYN+ACK

Send ACK y+1

Receive ACK

Figure 1.2.4.1 TCP Connection Establishment

To start, Host A initiates the connection by sending a TCP segment with the SYN

control bit set and an initial sequence number (ISN) we represent as the variable x in

the sequence number field. At some moment later in time, Host B receives this SYN

segment, processes it and responds with a TCP segment of its own. The response

from Host B contains the SYN control bit set and its own ISN represented as variable

y. Host B also sets the ACK control bit to indicate the next expected byte from Host A

should contain data starting with sequence number x+1.

When Host A receives Host B's ISN and ACK, it finishes the connection establishment

phase by sending a final acknowledgement segment to Host B. In this case, Host A

sets the ACK control bit and indicates the next expected byte from Host B by placing

acknowledgement number y+1 in the acknowledgement field. In addition to the

information shown in the diagram above, an exchange of source and destination

ports to use for this connection are also included in each senders' segments.


Once ISNs have been exchanged, communicating applications can transmit data

between each other. Most of the discussion surrounding data transfer requires us to

look at flow control and congestion control techniques which we discuss later in this

document and refer to other texts. A few key ideas will be briefly made here, while

leaving the technical details aside.

A simple TCP implementation will place segments into the network for a receiver as

long as there is data to send and as long as the sender does not exceed the window

advertised by the receiver. As the receiver accepts and processes TCP segments, it

sends back positive acknowledgements, indicating where in the byte stream it is.

These acknowledgements also contain the "window" which determines how many

bytes the receiver is currently willing to accept. If data is duplicated or lost, a "hole"

may exist in the byte stream. A receiver will continue to acknowledge the most

current contiguous place in the byte stream it has accepted.

If there is no data to send, the sending TCP will simply sit idly by waiting for the

application to put data into the byte stream or to receive data from the other end of

the connection. If data queued by the sender reaches a point where data sent will

exceed the receiver's advertised window size, the sender must halt transmission and

wait for further acknowledgements and an advertised window size that is greater

than zero before resuming.

Timers are used to avoid deadlock and unresponsive connections. Delayed

transmissions are used to make more efficient use of network bandwidth by sending

larger "chunks" of data at once rather than in smaller individual pieces.

In order for a connection to be released, four segments are required to completely

close a connection. Four segments are necessary due to the fact that TCP is a full-

duplex protocol, meaning that each end must shut down independently.

Notice that instead of SYN control bit fields, the connection termination phase uses

the FIN control bit fields to signal the close of a connection.


Host A Host B

Send FIN seq=x In the Internet

Receive FIN

Send ACK x+1

Receive ACK Send FIN seq=y, ACK x+1

Receive FIN+ACK

Send ACK y+1

Receive ACK

Figure 1.2.4.2 TCP Connection Termination

To terminate the connection in our example, the application running on Host A

signals TCP to close the connection. This generates the first FIN segment from Host A

to Host B. When Host B receives the initial FIN segment, it immediately acknowledges

the segment and notifies its destination application of the termination request. Once

the application on Host B also decides to shut down the connection, it then sends its

own FIN segment, which Host A will process and respond with an acknowledgement.

1.2.5 Sliding Window and Flow Control

Flow control is a technique whose primary purpose is to properly match the

transmission rate of sender to that of the receiver and the network. It is important for the

transmission to be at a high enough rates to ensure good performance, but also to protect

against overwhelming the network or receiving host.

The flow control is not the same as congestion control. Congestion control is primarily

concerned with a sustained overload of network intermediate devices such as IP routers.

TCP uses the window field, briefly described previously, as the primary means for

flow control. During the data transfer phase, the window field is used to adjust the rate of

flow of the byte stream between communicating TCPs.


In simple example, there is a 4-byte sliding window. Moving from left to right, the

window "slides" as bytes in the stream are sent and acknowledged. The size of the window

and how fast to increase or decrease the window size is an area of great research.

1.2.6 Congestion Control

TCP congestion control and Internet traffic management issues in general is an active

area of research and experimentation. This final section is a very brief summary of the

standard congestion control algorithms widely used in TCP implementations today.

1.2.7 Slow Start

Slow Start, a requirement for TCP software implementations is a mechanism used by

the sender to control the transmission rate, otherwise known as sender-based flow control.

This is accomplished through the return rate of acknowledgements from the receiver. In

other words, the rate of acknowledgements returned by the receiver determines the rate at

which the sender can transmit data.

When a TCP connection first begins, the Slow Start algorithm initializes a congestion

window to one segment which is the maximum segment size (MSS) initialized by the

receiver during the connection establishment phase when acknowledgements are returned

by the receiver, the congestion window increases by one segment for each

acknowledgement returned. Thus, the sender can transmit the minimum of the congestion

window and the advertised window of the receiver, which is simply called the transmission

window.

Slow Start is actually not very slow when the network is not congested and network

response time is good. For example, the first successful transmission and acknowledgement

of a TCP segment increases the window to two segments. After successful transmission of

these two segments and acknowledgements completes, the window is increased to four

segments.

1.2.8 Congestion Avoidance

During the initial data transfer phase of a TCP connection the Slow Start algorithm is

used. However, there may be a point during Slow Start that the network is forced to drop

one or more packets due to overload or congestion. If this happens, Congestion Avoidance is

used to slow the transmission rate. However, Slow Start is used in conjunction with


Congestion Avoidance as the means to get the data transfer going again so it doesn't slow

down and stay slow.

In the Congestion Avoidance algorithm a retransmission timer expiring or the

reception of duplicate ACKs can implicitly signal the sender that a network congestion

situation is occurring. The sender immediately sets its transmission window to one half of

the current window size (the minimum of the congestion window and the receiver's

advertised window size), but to at least two segments. If congestion was indicated by a

timeout, the congestion window is reset to one segment, which automatically puts the

sender into Slow Start mode. If congestion was indicated by duplicate ACKs, the Fast

Retransmit and Fast Recovery algorithms are invoked (see below).

As data is received during Congestion Avoidance, the congestion window is

increased. However, Slow Start is only used up to the halfway point where congestion

originally occurred. This halfway point was recorded earlier as the new transmission window.

After this halfway point, the congestion window is increased by one segment for all

segments in the transmission window that are acknowledged. This mechanism will force the

sender to more slowly grow its transmission rate, as it will approach the point where

congestion had previously been detected.

1.2.9 Fast Retransmit

When a duplicate ACK is received, the sender does not know if it is because a TCP

segment was lost or simply that a segment was delayed and received out of order at the

receiver. If the receiver can re-order segments, it should not be long before the receiver

sends the latest expected acknowledgement. Typically no more than one or two duplicate

ACKs should be received when simple out of order conditions exist. If however more than

two duplicate ACKs are received by the sender, it is a strong indication that at least one

segment has been lost. The TCP sender will assume enough time has lapsed for all

segments to be properly re-ordered by the fact that the receiver had enough time to send

three duplicate ACKs.

When three or more duplicate ACKs are received, the sender does not even wait for a

retransmission timer to expire before retransmitting the segment (as indicated by the

position of the duplicate ACK in the byte stream). This process is called the Fast Retransmit


algorithm and was first defined in it. Immediately following Fast Retransmit is the Fast

Recovery algorithm.

1.2.10 Fast Recovery

Since the Fast Retransmit algorithm is used when duplicate ACKs are being received,

the TCP sender has implicit knowledge that there is data still flowing to the receiver. Why?

The reason is because duplicate ACKs can only be generated when a segment is received.

This is a strong indication that serious network congestion may not exist and that the lost

segment was a rare event. So instead of reducing the flow of data abruptly by going all the

way into Slow Start, the sender only enters Congestion Avoidance mode.

Rather than start at a window of one segment as in Slow Start mode, the sender

resumes transmission with a larger window, incrementing as if in Congestion Avoidance

mode. This allows for higher throughput under the condition of only moderate congestion.

1.2.11 User Datagram Protocol

This User Datagram Protocol (UDP) is defined to make available a Datagram mode of

packet-switched computer communication in the environment of an interconnected set of

computer networks. This protocol assumes that the Internet Protocol (IP) is used as the

underlying protocol.

This protocol provides a procedure for application programs to send messages to

other programs with a minimum of protocol mechanism. The protocol is transaction

oriented, and delivery and duplicate protection are not guaranteed. Applications requiring

ordered reliable delivery of streams of data should use the Transmission Control Protocol

(TCP).

1.2.11.1 Fields:

Source Port is an optional field, when meaningful, it indicates the port of the sending

process, and may be assumed to be the port to which a reply should be addressed in

the absence of any other information. If not used, a value of zero inserted.

Destination Port has a meaning within the context of a particular Internet destination

address. Length is the length in octets of this user datagram including this header

and the data. (This means the minimum value of the length is eight.)


Checksum is the 16-bit one's complement of the one's complement sum of a

pseudo header of information from the IP header, the UDP header, and the data,

padded with zero octets at the end (if necessary) to make a multiple of two

octets. The pseudo header conceptually prefixed to the UDP header contains the

source address, the destination address, the protocol, and the UDP length. This

information gives protection against misrouted datagrams.

1.2.11.2 User Interface:

A user interface should allow the creation of new receive ports, receive operations

on the receive ports that return the data octets and an indication of source port and

source address, and an operation that allows a datagram to be sent, specifying the

data, source and destination ports and addresses to be sent.

1.2.11.3 IP Interface:

The UDP module must be able to determine the source and destination internet

addresses and the protocol field from the internet header. One possible UDP/IP

interface would return the whole internet datagram including the entire internet

header in response to a receive operation. Such an interface would also allow the

UDP to pass a full internet datagram complete with header to the IP to send. The IP

would verify certain fields for consistency and compute the internet header

checksum.

1.2.11.4 Protocol Application:

The major use of this protocol is the Internet Name Server, and the Trivial File

Transfer.

This project report is divided into 7 chapters. Chapter 1 presented an overview of Computer

Networks which consists of the OSI layers, Transmission Control Protocol, TCP header

format, connection establishment and termination, sliding window and flow control,

congestion control, slow start, congestion avoidance, fast retransmit, fast recovery, user

datagram protocol.


Chapter 2 presents an overview of ad hoc network in simplest form; wireless ad hoc

network, mobile ad hoc network and several different protocols have been proposed for ad-

hoc routing, the communication environment and the MANET model.

Chapter 3 discusses about the Secure ad hoc on-demand distance vector (SAODV) and

Trusted ad hoc on-demand distance vector (TAODV) protocols for MANET routing security,

and briefly about the ad hoc on-demand distance vector (AODV) routing protocol.

Chapter 4 covers the design and implementation part which include use case diagram, class

diagram, sequence diagram, collaboration diagram, state chart diagram and data flow

diagrams, where the UML diagrams gives the static and the dynamic views of the system

and the data flow diagrams gives the conceptual flow of the system.

Chapter 5 presents the test cases, which consists of the execution results of the system

developed. These results will guide the user how the system works throughout the execution

process.

Chapter 6 presents the conclusion of the project developed and future work discusses the

future protocols that can be developed with more advanced features based on these

protocols.

Chapter 7 consists of the books, magazines, journals and conference papers etc, that are

referred during the project work.

2. AD HOC NETWORK

An ad hoc is considered a collection of wireless mobile nodes that are capable of

communicating with each other without the use of a network infrastructure or any

centralized administration. The mobile hosts are not bound to any centralized control like

base stations or mobile switching centers. Although this offers unrestricted mobility and


connectivity to the users, the onus of network management is now entirely on the nodes

that forms the network. Due to the limited transmission range of wireless network

interfaces, multiple hops may be needed for one node to exchange data with another across

the network. In such a network, each mobile node operates not only as a host but also as a

router, forwarding packets for other mobile nodes in the network that may not be within

direct wireless transmission range of each other. Each node participates in an ad hoc routing

protocol that allows it to discover multihop paths through the network to any other node.

The idea of ad hoc is also called infrastructure less networking, since the mobile nodes in the

network dynamically establish routing among themselves to form their own network on the

fly. It is formed instantaneously, and uses multihop routing to transmit information. MANET

technology can provide an extremely flexible method of establishing communications in

situations where geographical or terrestrial constraints demand a totally distributed network

system without any fixed base station, such as battlefields, military applications, and other

emergency and disaster situations.

Ad-Hoc Network is the simplest form of Wireless LAN is a network composed of a few

nodes without any bridging or forwarding capability. All nodes are equal and may join or

leave at any time, and have equal right to the medium. In fact, it's very much like an

Ethernet, where you may add or remove node at discretion. This is the kind of radio

networks deployed in homes of small offices. Ad hoc Network is an Isolated Network.

Ad hoc networks are a new paradigm of wireless communication for mobile hosts

(which we call nodes). In an ad hoc network, there is no fixed infrastructure such as base

stations or mobile switching centres. Mobile nodes that are within each other’s radio range

communicate directly via wireless links, while those that are far apart rely on other nodes to

relay messages as routers. Node mobility in an ad hoc network causes frequent changes of

the network topology Military tactical operations are still the main application of ad hoc

networks today. Ad hoc networks can also be used for emergency, law enforcement, and

rescue missions. Since an ad hoc network can be deployed rapidly with relatively low cost, it

becomes an attractive option for commercial uses such as sensor networks or virtual

classrooms.

2.1 Wireless Ad hoc Network

A Wireless Ad Hoc Network is a decentralized wireless network. The network is ad hoc

because each node is willing to forward data for other nodes, and so the determination of


which nodes forward data is made dynamically based on the network connectivity. This is in

contrast to wired networks in which routers perform the task of routing. It is also in contrast

to managed (infrastructure) wireless networks, in which a special node known as an access

point manages communication among other nodes.

Wireless ad hoc networks can be further classified by their application:

Mobile Ad Hoc Networks (MANETs)

Wireless Mesh Networks

Wireless Sensor Networks

2.2 Mobile Ad hoc Network

A mobile ad hoc network (MANET) is a kind of wireless network without centralized

administration or fixed network infrastructure, in which nodes communicate over relatively

bandwidth constrained wireless links and perform routing discovery and routing

maintenance in a self-organized way. The topology of the MANET may change uncertainly

and rapidly due to the high mobility of the independent mobile nodes, and because of the

network decentralization, each node in the MANET will act as a router to discover the

topology and maintain the network connectivity. Unlike the wired networks, the MANET must

take into account many factors such as wireless link quality, power limitation, multi user

interference and so on. The routing determination is also more difficult in the MANET.

Nowadays the MANET enables many promising applications in the areas of emergency

operations, disaster relief efforts, and military battlefield networks. These kinds of

applications often comprise lots of independent mobile nodes and demand establishing

efficient, reliable and dynamic network communications rapidly. Especially for the military

environment, preservation of security, latency, reliability, intentional jamming, and recovery

from failure are significant concerns. On the other hand, with some characteristics such as

openness, mobility, dynamic topology and protocol weaknesses, MANETs are prone to be

unstable and attemptable. Consequently, the security issues of MANETs are becoming an

urgent requirement. Finally, the nodes in the network can be highly mobile, thus rapidly

changing the node constellation and the presence or absence of links. Examples of the use

of the MANETs are:

Tactical operation – for fast establishment for military communication during

the deployment of forces in unknown and hostile terrain;


Rescue missions – for communication in times of national crisis, where the

existing communication infrastructure is non – operational due to natural

disaster or a global war;

Law – enforcement for the establishment of communication infrastructure

during law enforcement operations;

Commercial use – for setting up communication in exhibitions, conference, or

sales presentations.

Educations – for operations of wall – free (virtual) classrooms; and

Sensor networks – for communication between intelligent sensors (e.g.

MEMS2) mounted on mobile platforms.

Nodes in the MANET exhibit nomadic behaviour by freely migrating within some area,

dynamically creating and tearing down associations with other nodes. Groups of nodes that

have a common goal can create formations (clusters) and migrate together, similarly to

military units on missions or to guided tours on excursions. Nodes can communicate with

each other at any time and without restrictions, except for connectivity limitations and

subject to security provisions.

MANETs are intended to provide a data network that is immediately deployable in

arbitrary communication environments and is responsive to changes in network topology.

Because adhoc networks are intended to be deployable anywhere, existing infrastructure

may not be present. The mobile nodes are thus likely to be the sole elements of the

network. Differing mobility patterns and radio propagation conditions that vary with time

and position can result in intermittent and sporadic connectivity between adjacent nodes.

The result is a time-varying network topology.

MANETs are distinguished from other ad-hoc networks by rapidly changing network

topologies, influenced by the network size and node mobility. Such networks typically have a

large span and contain hundreds to thousands of nodes. The MANET nodes exist on top of

diverse platforms that exhibit quite different mobility patterns. Within a MANET, there can

be significant variations in nodal speed (from stationary nodes to high-speed aircraft),


direction of movement, acceleration/deceleration or restrictions on paths (e.g., a car must

drive on a road, but a tank does not). A pedestrian is restricted by built objects while

airborne platforms can exist anywhere in some range of altitudes. In spite of such volatility,

the MANET is expected to deliver diverse traffic types, ranging from pure voice to integrated

voice and image, and even possibly some limited video.

In traditional wireless networks, a base station or access point facilitates all

communications between nodes on the network and communications with destinations

outside the network, In contrast, MANETs allow for the formation of a network without

requiring a fixed infrastructure. These networks only require that nodes have interoperable

radio hardware and are using the same routing protocol to route traffic over the network.

The lessened requirements for such networks, along with the ability to implement them

using small, resource-limited devices has made them increasingly popular in all types of

application areas. Since there is no fixed infrastructure, the nodes in the network forward

traffic for one another in order to allow communication between nodes that are not within

physical radio range.

Nodes must also be able to change how they forward data over the network as

individual nodes move around and acquire and lose neighbors, i.e., nodes within radio

range. Such an approach does indeed prevent tampering with the routing information; it

also makes for a very simple denial of service (DoS) attack. This attack is very effective in

MANETs as the devices often have limited battery power in addition to the limited

computational power. Consequently, this type of DoS attack allows for an attacker to

effectively shutdown nodes or otherwise disrupts the network.

The trade-off between strong cryptographic security and DoS has become

increasingly important as MANET applications are developed which require a protocol with

reasonable security and reasonable resistance to DoS, a kind of middle-ground. It has been

suggested that various trust mechanisms could be used to develop new protocols with

unique security assurances at different levels in this trade-off. Since there is no fixed

infrastructure, the nodes in the network forward traffic for one another in order to allow

communication between nodes that are not within physical radio range.

Several different protocols have been proposed for ad-hoc routing. The earliest protocols

such as

DSDV


DSR

AODV

Focused on problems that mobility presented to the accurate determination of routing

information;

DSDV is a proactive protocol requiring periodic updates of all the routing information.

DSR and AODV are reactive protocols, only used when new destinations are sought, a

route breaks, or a route is no longer in use.

2.3 The Communication Environment and the MANET Model

The following are a number of assumptions about the communication parameters,

the network architecture, and the network traffic in a MANET.

Nodes are equipped with portable communication devices. Lightweight batteries may

power these devices. Limited battery life can impose restrictions on the transmission

range, communication activity (both transmitting and receiving) and the

computational power of these devices.

Connectivity between nodes is not a transition relation; i.e., if a node A can

communicate directly with node B and node B can communicate directly with node C,

then node A may not, necessarily, be able to communicate directly with node C. This

leads to the hidden terminal problem.

A hierarchy in the network routing and mobility management procedures could

improve network performance measures, such as the latency in locating a mobile.

However, a physical hierarchy may lead to areas of congestion and is very vulnerable

to frequent topological reconfigurations.

All the network nodes have equal capabilities. This means that all nodes are

equipped with identical communication devices and are capable of performing

functions from a common set of network services. However, all nodes do not

necessarily perform the same functions at the same time. In particular, node may be

assigned specific functions in the network, and those roles may change over time.

Although the network should allow communication between any two nodes, it is

envisioned that a large portion of the traffic will be between geographically close

nodes. This assumption is clearly justified in a hierarchical organization. For example,


it is much more likely that communication will take place between two soldiers in the

same unit, rather than between two soldiers in two different brigades.

A MANET is a peer-to-peer network that allows direct communication between any

two nodes, when adequate radio propagation conditions exist between these two nodes and

subject to transmission power limitations of the nodes. If there is no direct link between the

source and the destination nodes, multi-hop routing is used. In multi-hop routing, a packet is

forwarded from one node to another, until it reaches the destination. Of course, appropriate

routing protocols are necessary to discover routes between the source and the destination,

or even to determine the presence or absence of a path to the destination node. Because of

the lack of central elements, distributed protocols have to be used.

All communications between all network entities in ad-hoc networks are carried over

the wireless medium. Due to the radio communications being vulnerable to propagation

impairments, connectivity between network nodes is not guaranteed. In fact, intermittent

and sporadic connectivity may be quite common. Additionally, as the wireless bandwidth is

limited, its use should be minimized. Finally, as some of the mobile devices are expected to

be handheld with limited power sources, the required transmission power should be

minimized as well. Therefore, the transmission radius of each mobile is limited, and channels

assigned to mobiles are typically spatially reused. Consequently, since the transmission

radius is much smaller than the network span, communication between two nodes often

needs to be relayed through intermediate nodes; i.e., multi-hop routing is used.

In MANETs, because of the possibly rapid movement of the nodes and variable

propagation conditions, network information, such as a route table, becomes obsolete

quickly. Frequent network reconfiguration may trigger frequent exchanges of control

information to reflect the current state of the network. However, the short lifetime of this

information means that a large portion of this information may never be used. Thus, the

bandwidth used for distribution of the routing update information is wasted. In spite of these

attributes, the design of the MANETs still needs to allow for a high degree of reliability,

survivability, availability, and manageability of the network.

On the basis of the above discussion the following features are required:


Robust routing and mobility management algorithms to increase the

network reliability and availability.

Adaptive algorithms and protocols to adjust the frequency changing radio

propagation, network and traffic conditions.

Low – overhead algorithms ad protocols to preserve radio communication

resource.

Multiple (distinct) routes between the source and a destination – to reduce

congestion in the vicinity of certain nodes, and to increase the reliability and

survivability.

Robust network architecture to avoid susceptibility to network failures,

congestion around high-level nodes, and the penalty due to inefficient routing.

In the absence of fixed infrastructure, MANET node cooperate to provide routing

services, relying on each other to forward packets to their destination. Routing protocols

designed for fixed networks are not effective in the dynamic and resource constrained

MANET environment. Due to the radio communications being vulnerable to propagation

impairments, connectivity between network nodes is not guaranteed. In fact, intermittent

and sporadic connectivity may be quite common. Additionally, as the wireless bandwidth is

limited, its use should be minimized. Finally, as some of the mobile devices are expected to

be handheld with limited power sources, the required transmission power should be

minimized as well. Therefore, the transmission radius of each mobile is limited, and channels

assigned to mobiles are typically spatially reused.

3. SECURE AODV & TRUSTED AODV

3.1 Ad hoc On-demand Distance Vector (AODV)

The Ad hoc On Demand Distance Vector (AODV) routing algorithm is a routing

protocol designed for ad hoc mobile networks. AODV is capable of both unicast and

multicast routing. It is an on demand algorithm, meaning that it builds routes between

nodes only as desired by source nodes. It maintains these routes as long as they are needed

by the sources. Additionally, AODV forms trees which connect multicast group members.

The trees are composed of the group members and the nodes needed to connect the


members. AODV uses sequence numbers to ensure the freshness of routes. It is loop-free,

self-starting, and scales to large numbers of mobile nodes.

AODV builds routes using a route request / route reply query cycle. When a source

node desires a route to a destination for which it does not already have a route, it

broadcasts a route request (RREQ) packet across the network. Nodes receiving this packet

update their information for the source node and set up backwards pointers to the source

node in the route tables. In addition to the source node's IP address, current sequence

number, and broadcast ID, the RREQ also contains the most recent sequence number for the

destination of which the source node is aware. A node receiving the RREQ may send a route

reply (RREP) if it is either the destination or if it has a route to the destination with

corresponding sequence number greater than or equal to that contained in the RREQ. If this

is the case, it unicasts a RREP back to the source. Otherwise, it rebroadcasts the RREQ.

Nodes keep track of the RREQ's source IP address and broadcast ID. If they receive a RREQ

which they have already processed, they discard the RREQ and do not forward it.

As the RREP propagates back to the source, nodes set up forward pointers to the

destination, once the source node receives the RREP, it may begin to forward data packets

to the destination. If the source later receives a RREP containing a greater sequence number

or contains the same sequence number with a smaller hop count, it may update its routing

information for that destination and begin using the better route.

As long as the route remains active, it will continue to be maintained. A route is

considered active as long as there are data packets periodically travelling from the source to

the destination along that path. Once the source stops sending data packets, the links will

time out and eventually be deleted from the intermediate node routing tables. If a link break

occurs while the route is active, the node upstream of the break propagates a route error

(RERR) message to the source node to inform it of the now unreachable destination(s). After

receiving the RERR, if the source node still desires the route, it can reinitiate route

discovery.

Multicast routes are set up in a similar manner. A node wishing to join a multicast

group broadcasts a RREQ with the destination IP address set to that of the multicast group

and with the 'J'(join) flag set to indicate that it would like to join the group. Any node

receiving this RREQ that is a member of the multicast tree that has a fresh enough sequence


number for the multicast group may send a RREP. As the RREPs propagate back to the

source, the nodes forwarding the message set up pointers in their multicast route tables. As

the source node receives the RREPs, it keeps track of the route with the freshest sequence

number, and beyond that the smallest hop count to the next multicast group member. After

the specified discovery period, the source node wills unicast a Multicast Activation (MACT)

message to its selected next hop. This message serves the purpose of activating the route.

A node that does not receive this message that had set up a multicast route pointer will

timeout and delete the pointer. If the node receiving the MACT was not already a part of the

multicast tree, it will also have been keeping track of the best route from the RREPs it

received. Hence it must also unicast a MACT to its next hop, and so on until a node that was

previously a member of the multicast tree is reached. AODV maintains routes for as long as

the route is active. This includes maintaining a multicast tree for the life of the multicast

group. Because the network nodes are mobile, it is likely that many link breakages along a

route will occur during the lifetime of that route.

The main advantage of this protocol is that routes are established on demand and

destination sequence numbers are used to find the latest route to the destination. The

connection setup delay is lower. One of the disadvantages of this protocol is that

intermediate nodes can lead to inconsistent routes if the source sequence number is very

old and the intermediate nodes have a higher but not the latest destination sequence

number, thereby having stale entries. Also multiple Route Reply packets in response to a

single Route Request packet can lead to heavy control overhead. Another disadvantage of

AODV is that the periodic beaconing leads to unnecessary bandwidth consumption.

3.2 Secure Ad hoc on-demand Distance Vector (SAODV)

Two mechanisms are used to secure the AODV messages: digital signatures to

authenticate the non-mutable fields of the messages, and hash chains to secure the hop

count information. For the non mutable information, authentication is performing in an end-

to-end manner, but the same kind of techniques cannot be applied to the mutable

information. The information relative to the hash chains and the signatures is transmitted

with the AODV message as an extension message that will be refereed as Signature

Extension.

SAODV uses hash chains to authenticate the hop count of RREQ and RREP messages

in such a way that allows every node that receives the message to verify that the hop count


has not been decremented by an attacker. This prevents an attack of type 2. A hash chain is

formed by applying a one-way hash function repeatedly to a seed. Every time a node

originates a RREQ or a RREP message, it performs the following operations:

• Generates a random number (seed).

• Sets the Max Hop Count field to the TimeToLive value (from the IP header).

Max Hop Count = TimeToLive

• Sets the Hash field to the seed value.

Hash = seed

• Sets the Hash Function field to the identifier of the hash function that it is going to use.

Hash Function = h

• Calculates Top Hash by hashing seed Max Hop Count times.

Top Hash = hMax Hop Count(seed)

Where:

– h is a hash function.

– hi(x) is the result of applying the function h to x i times.

In addition, every time a node receives a RREQ or a RREP message, it performs the following

operations in order to verify the hop count:

• Applies the hash function h Maximum Hop Count minus Hop Count times to the value in

the Hash field, and verifies that the resultant value is equal to the value contained in the Top

Hash field.

Top Hash == hMax Hop Count−Hop Count(Hash)

Where:

a == b reads: to verify that a and b are equal.

• Before rebroadcasting a RREQ or forwarding a RREP, a node applies the hash function to

the Hash value in the Signature Extension to account for the new hop.

Hash = h (Hash)


The Hash Function field indicates which hash function has to be used to compute the

hash. Trying to use a different hash function will just create a wrong hash without giving any

advantage to a malicious node. Hash Function, Max Hop Count, Top Hash, and Hash fields

are transmitted with the AODV message, in the Signature Extension. And, as it will be

explained later, all of them but the Hash fields are signed to protect its integrity.

Digital signatures are used to protect the integrity of the non-mutable data in RREQ and

RREP messages. That means that they sign everything but the Hop Count of the AODV

message and the Hash from the SAODV extension.

The main problem in applying digital signatures is that AODV allows intermediate

nodes to reply RREQ messages if they have a ‘fresh enough’ route to the destination. While

this makes the protocol more efficient it also makes it more complicated to secure. The

problem is that a RREP message generated by an intermediate node should be able to sign

it on behalf of the final destination. And, in addition, it is possible that the route stored in the

intermediate node would be created as a reverse route after receiving a RREQ message.

To solve this problem, SAODV offers two alternatives. The first one (and also the

obvious one) is that, if an intermediate node cannot reply to a RREQ message because it

cannot properly sign its RREP message, it just behaves as if it didn’t have the route and

forwards the RREQ message. The second is that, every time a node generates a RREQ

message, it also includes the RREP flags, the prefix size and the signature that can be used

(by any intermediate node that creates a reverse route to the originator of the RREQ) to

reply a RREQ that asks for the node that originated the first RREQ. Moreover, when an

intermediate node generates a RREP message, the lifetime of the route has changed from

the original one. Therefore, the intermediate node should include both lifetimes (the old one

is needed to verify the signature of the route destination) and sign the new lifetime.

When a node receives a RREQ, it first verifies the signature before creating or

updating a reverse route to that host. Only if the signature is verified, will it store the route.

If the RREQ was received with a Double Signature Extension, then the node will also store

the signature for the RREP and the lifetime (which is the ‘reverse route lifetime’ value) in the

route entry. An intermediate node will reply to a RREQ with a RREP only if it fulfills the

AODV’s requirements to do so and the node has the corresponding signature and old


lifetime to put into the Signature and Old Lifetime fields of the RREP Double Signature

Extension. Otherwise, it will rebroadcast the RREQ.

When a RREQ is received by the destination itself, it will reply with a RREP only if it

fulfills the AODV’s requirements to do so. This RREP will be sent with a RREP Single

Signature Extension.

When a node receives a RREP, it first verifies the signature before creating or

updating a route to that host. Only if the signature is verified, will it store the route with the

signature of the RREP and the lifetime.

3.2.1 Security Requirements:

● Import authorization: Route information will be imported only if it concerns to the

node that is sending the information.

● Source authentication: To be able to verify that the node is the one it claims to be.

● Integrity: To be able to verify the received routing information has not been altered.

● Data authentication: The combination of the two last ones.

3.2.2 Securing Ad hoc Protocols:

3.2.2.1 Import authorization: It is important to note that in here it is not referring to the

traditional meaning of authorization. What means is that the ultimate authority about

routing messages regarding a certain destination node is that node itself. Therefore, route

information will only be authorized in a routing table if that route information concerns the

node that is sending the information. In this way, if a malicious node lies about it, the only

thing it will cause is that others will not be able to route packets to the malicious node.

3.2.2.2 Source authentication: Nodes need to be able to verify that the node is the one it

claims to be.

3.2.2.3 Integrity: In addition, nodes need to be able to verify that the routing information

that it is being sent to us has arrived unaltered. The two last security services combined

build data authentication, and they are requirements derived from our import authorization

requirement.


In an ad hoc network, from the point of view of a routing protocol, there are two kinds

of messages: the routing messages and the data messages. Both have a different nature

and different security needs. Data messages are point-to-point and can be protected with

any point-to-point security system (like IPSec). On the other hand, routing messages are

sent to immediate neighbors, processed, possibly modified, and resent. Moreover, as a

result of the processing of the routing message, a node might modify its routing table. This

creates the need for the intermediate nodes to be able to authenticate the information

contained in the routing messages to be able to apply their import authorization policy.

3.2.3 Security flaws of AODV:

Since AODV has no security mechanisms, malicious nodes can perform many attacks

just by not behaving according to the AODV rules. A malicious node M can carry out the

following attacks (among many others) against AODV:

Impersonate a node S by forging a RREQ with its address as the Originator address.

When forwarding a RREQ generated by S to discover a route to D, Reduce the hop

count field to increase the chances of being in the route Path between S and D so it

can analyze the communication between them. A variant of this is to increment the

destination sequence number to make the other nodes believe that this is a ‘fresher’

route.

Impersonate a node D by forging a RREP with its address as a destination address.

Impersonate a node by forging a RREP that claims that the node is the destination

and, to increase the impact of the attack, claims to be a network leader of the subnet

SN with a big sequence number and send it to its neighbors. In this way it will

became (at least locally) a black hole for the whole subnet SN.

Selectively, not forward certain RREQs and RREPs not reply to certain RREPs and not

forward certain data messages. This kind of attack is especially hard to even detect

because transmission errors have the same effect.


Forge a RERR message pretending it is the node S and send it to its neighbor D. The

RERR message has a very high destination sequence number DSN for one of the

unreachable destinations (U). This might cause D to update the destination sequence

number corresponding to U with the value DSN and, therefore, future route

discoveries performed by D to obtain a route to U will fail.

According to the current AODV draft, the originator of a RREQ can put a much bigger

destination sequence number than the real one. In addition, sequence numbers

wraparound when they reach the maximum value allowed by the field size. This

allows a very easy attack in where an attacker is able to set the sequence number of

a node to any desired value by just sending two RREQ messages to the node.

3.2.4 SAODV digital signatures:

Digital signatures are used to protect the integrity of the non-mutable data in RREQ

and RREP messages. That means that they sign everything but the Hop Count of the AODV

message and the Hash from the SAODV extension.

The main problem in applying digital signatures is that AODV allows intermediate

nodes to reply RREQ messages if they have a ‘fresh enough’ route to the destination. While

this makes the protocol more efficient it also makes it more complicated to secure. The

problem is that a RREP message generated by an intermediate node should be able to sign

it on behalf of the final destination. And, in addition, it is possible that the route stored in the

intermediate node would be created as a reverse route after receiving a RREQ message

(which means that it does not have the signature for the RREP). To solve this problem,

SAODV offers two alternatives. The first one (and also the obvious one) is that, if an

intermediate node cannot reply to a RREQ message because it cannot properly sign its RREP

message, it just behaves as if it didn’t have the route and forwards the RREQ message. The

second is that, every time a node generates a RREQ message, it also includes the RREP

flags, the prefix size and the signature that can be used (by any intermediate node that

creates a reverse route to the originator of the RREQ) to reply a RREQ that asks for the node

that originated the first RREQ. Moreover, when an intermediate node generates a RREP

message, the lifetime of the route has changed from the original one. Therefore, the

intermediate node should include both lifetimes (the old one is needed to verify the

signature of the route destination) and sign the new lifetime. In this way, the original

information of the route is signed by the final destination and the lifetime is signed by the


intermediate node. To distinguish the different SAODV extension messages, the ones that

have two signatures are called RREQ and RREP Double Signature Extension.

When a node receives a RREQ, it first verifies the signature before creating or

updating a reverse route to that host. Only if the signature is verified, will it store the route.

If the RREQ was received with a Double Signature Extension, then the node will also store

the signature for the RREP and the lifetime (which is the ‘reverse route lifetime’ value) in the

route entry. An intermediate node will reply to a RREQ with a RREP only if it fulfils the

AODV’s requirements to do so and the node has the corresponding signature and old

lifetime to put into the Signature and Old Lifetime fields of the RREP Double Signature

Extension. Otherwise, it will rebroadcast the RREQ.

When a RREQ is received by the destination itself, it will reply with a RREP only if it

fulfils the AODV’s requirements to do so. This RREP will be sent with a RREP Single Signature

Extension. When a node receives a RREP, it first verifies the signature before creating or

updating a route to that host. Only if the signature is verified, will it store the route with the

signature of the RREP and the lifetime.

3.2.5 SAODV error messages:

When Considering RERR messages, someone could think that the right approach to

secure them should be similar to the way the other AODV messages are (signing the non-

mutable information and finding out a way to secure the mutable information).

Nevertheless, RERR messages have a big amount of mutable information. In addition, it is

not relevant which node started the RERR and which nodes are just forwarding it. The only

relevant information is that a neighbour node is informing another node that it is not going

to be able to route messages to certain destinations anymore.

The proposal is that every node (generating or forwarding a RERR message) will use

digital signatures to sign the whole message and that any neighbour that receives it will

verify the signature. In this way it can verify that the sender of the RERR message is really

the one that it claims to be. And, since destination sequence numbers are not signed by the

corresponding node, a node should never update any destination sequence number of its

routing table based on a RERR message. Implementing a mechanism that will allow the

destination sequence numbers of a RERR message to be signed by their corresponding


nodes would add too much overhead compared with the advantage of the use of that

information.

Although nodes will not trust destination sequence numbers in a RERR message, they

will use them to decide whether they should invalidate a route or not. This does not give any

extra advantage to a malicious node.

3.2.6 RSA Algorithm:

RSA is a widely used and well document algorithm in Cryptography. It is a public key

algorithm (i.e. two different keys are used to encrypt and decrypt the data). However these

two keys are related. More details will be provided later regarding the relationship between

the keys.

RSA is currently used for many applications like RSA Secure-ID, Digital Certificates,

Smart Cards, etc. This algorithm is considered computationally unbreakable i.e. it would take

a very long time to break the code. Especially if we use large keys (1024 bits at least), it is

almost impossible to find the private key to decode the cipher text. This is because the

algorithm requires factoring two very large numbers. The RSA site has more information in

this regard.

The following are the steps involved in determining the public and private keys using the

RSA algorithm:

p, q - Are large randomly

generated prime numbers.

n – One of the public keys. It is

used as the modulus.

phi - Or φ(n) is used to find ‘e’.

phi is an Euler Totient.

e – Is the other public key. It

should be relatively prime to phi.


Pick p & q

Pick e

Calculate:n = pqphi = (p-1)(q-1)

i.e. gcd(e, phi) = 1.

d – Is the private key. It is relatively

prime to phi and a multiplicative

inverse of e. It is calculated using

Extended Euclid’s Algorithm.

Figure 3.2.6 RSA Algorithm Implementation

At this stage we should discard p, q, and m values. Now we have the private key d, and the

public keys e and n.

If we want to encrypt text, we will need to first represent it in some numeric form (say P).

Then we simply apply the formula: C = Pe mod n.

If we want to decrypt the cipher text C to P`, we apply the formula: P` = Cd mod n.

3.3 Trusted Ad hoc On-demand Distance Vector (TAODV)

Mobile nodes in MANETs often communicate with one another through an error-

prone, bandwidth-limited, and insecure wireless channel. We do not concern the security

problem introduced by the instability of physical layer or link layer. We only assume that:

Each node in the network has the ability to recover all of its neighbours.

Each node in the network can broadcast some essential messages to its neighbours

with high reliability.

Each node in the network possesses a unique ID, the physical network interface

address for example, that can be distinguished from others. In the TAODV, we also

assume that the system is equipped with some monitor mechanisms or intrusion

detection units either in the network layer or the application layer so that one node

can observe the behaviours of its one-hop neighbours.

Another kind of secure routing protocol which uses cryptography technologies is

recommended to take effect before nodes in the TAODV establish trust relationships among


Calculate:d such thatd*e mod phi = 1

one another. The latest security schemes for securing MANET, which employ cryptography

technologies. It assumes that the keys and certificates needed by these cryptographic

technologies have been obtained through some key management procedures before the

node performs routing behaviours. In the network layer, a new node model is designed as

the basis of our trust model. Some new fields are added into a node’s routing table to store

its opinion about other nodes’ trust worthiness and to record the positive and negative

evidence when it performs routing with others. By embedding our trust model into the

routing layer of MANET, we can save the consuming time without the trouble of maintaining

the expire time, valid state, etc. which is important in the situation of high node mobility and

invalidity. Also because of this reason, it is hard to design secure solutions in the transport

layer, which is an end-to-end communication mechanism.

3.3.1 Framework of the Trusted AODV:

There are mainly three modules in the whole TAODV system: basic AODV routing

protocol, trust model, and trusted AODV routing protocol. Based on our trust model, the

TAODV routing protocol contains such procedures as trust recommendation, trust

combination, trust judging. The Cryptographic routing behaviours trusted routing

behaviours, and trust updating. The general procedure for establishing trusts relationships

among nodes and for performing routing discovery is described as follows.

Imagine the beginning of an ad hoc network which contains a few nodes. Which

means that the node does not trust or distrust another node but it is only uncertain about

another node’s trustworthiness? Suppose node A wants to discover a route path to fl.

Because the uncertainty element in A’s opinion towards others is larger than or equal to 0.5,

which means that A is not sure whether it should believe or disbelieve any other nodes, A

will use the cryptographic schemes as proposed in SAODV or some other schemes to

perform routing discovery operations. After some successful or failed communications, A will

change its opinions about other nodes gradually using the trust updating algorithm. The

uncertainty elements in its opinions about other nodes will be mostly less than 0.5 after a

period of time. By means of this procedure, each node in this MANET will form more certain

opinions towards other nodes eventually after this period of initial time.

Once the trust relationship is established among most of the nodes in this ad hoc

network, these nodes can use our trusted routing protocol which is based our trust model to

perform routing operations. Note that the trust relationships among nodes are not


symmetric. That is, if node A totally trust B, B may not have the same opinion about A’s

trustworthiness. Node A now will use the trust recommendation protocol to exchange trust

information about a node, B, from its neighbours, then use the trust combination algorithm

to combine all the recommendation opinions together and calculate a new option towards B.

The sequent routing discovery and maintenance operations will follow the specifications of

our trusted routing protocol. Note that the situation that one node first joins a MANET can be

handled in the same way as at the beginning of this whole network. In this framework, the

establishment of trust relationships among nodes and the discovery of route paths are all

performed in a self-organized way, which is achieved by the cooperation of different nodes

to exchange information and to obtain agreements without any third-party’s interventions.

3.3.2 Trust model for TAODV:

Trust Representation Our trust model is an extension of the original trust model in

subjective logic. In our trust model, opinion is a 3-dimensional metric and is defined as

follows:

Figure 3.3.2 Framework of the Trusted AODV (TAODV)

Let U= (b g, d, i, U) denote any node A s opinion about any node fl’s trustworthiness

in a MANET: where repress, second and third component correspond to belief- disbelief and

uncertainty, respectively. These three elements sates: In this definition, belief means the

probability of a node B can be trusted by a node A, and disbelief means the probability of B


Trusted AODV Routing Protocol

Trust Model

Basic AODV Routing Protocol

Trust Recommendation

Trust combination

Trust Judging

Cryptography routing protocol

Trusted Routing Protocol

Trust Updating

cannot be trusted by A. Then uncertainty U$ fills the void in the absence of both belief and

disbelief, and sum of these three elements is Mapping between the Evidence and Opinion

Spaces A node in MANET will collect and record all the positive and negative evidences

about other nodes trustworthiness.

3.3.3 Trust Combination:

In this trust model, a node will collect all its neighbours’ opinions about another node

and combine them together using combination operations. In this way, the node can make a

Relatively objective judgment about another node’s trustworthiness even in case several

nodes are lying. The followings are two combination operations nodes may adopt:

Discounting Combination and Consensus Combination.

Discounting Combination-Let’s consider such a situation: Node A wants to how C’s

trustworthiness, then node B gives its opinion about C. Assuming A already has an opinion

about B. Then A will combine the two opinions: A to B, B to C to obtain a recommendation

opinion A to C. Discounting combination is for this purpose.

• Use Opinion to represent trust:

– 3-Dimensional metric ωBA≡(bB

A , dBA , uB

A )

• bBA

-- Probability of node A believing in node B

• d BA

--Probability of node A disbelieving in node B

• uBA

-- Probability of node A’s uncertainty about B

– We define that bBA+dB

A+uBA=1

3.3.4 Routing Operations in TAODV:

Exchange trust information

Three types of message:

TREQ: Trust REQUEST.

TREP: Trust REPLY.

TWARN: Trust WARNING.


3.3.5 General Process of TAODV:

On initialization, each node’s opinion towards others is (0, 0, 1), which means total

uncertainty of other nodes’ trustworthiness.

Nodes perform signature authentication during the initialization period. After some

trust exchanges and data communications, thus with the increase of either positive or

negative events, the uncertainty will be decreased and the trust relationship among nodes is

forming. When the trust relationship in the network has been established, the authentication

of nodes will mainly use trust authentication.

3.3.6 Trust Judging Rules:

The process of trusted routing discovery and maintenance in detail, we predefine

some trust judging rules here:

In node A’s opinion towards node B’s trustworthiness, if the first component belief of

opinion ωBA

is larger than 0.5, A will trust B and continue to perform routing related

to B.

In node A’s opinion towards node E’s trustworthiness, if the second component

disbelief of opinion ωBA

is larger than 0.5, A will not trust E and will refuse to

performing muting related to B. Accordingly the route entry for B in A’s routing table

will be disabled and deleted after an expire time.

In node A’s opinion towards node E’s trustworthiness, if the third component

uncertainty of opinion ωBA

is larger than 0.5, A will request E’s digital signature

whenever A has interaction (or relationship) with E.

In node A’s opinion towards node B’s trustworthiness, if the three components of

opinion ωBA

are all smaller than or equal to 0.5, A will request E’s digital signature

whenever A bas interaction (or relationship) with B.


If node B has no route entry in node A’s routing table, A’s opinion about B is

initialized as (0,0,1).

3.3.7 Trust Updating Policies:

Opinions among nodes change dynamically with the increase of successful or failed

communication times, when and how to update trust opinions among nodes will follow some

policies.

We derive as follows:

Each time a node A has performed a successful communication with another node B,

including forwarding route requests or replies normally, generating route requests or

route replies normally, etc., B’s successful events in A’s routing table will be

increased by 1.

Each time a node A has performed a failed communication with another node E,

including forwarding route requests or replies abnormally, generating route requests

or route replies abnormally, authenticating itself incorrectly, and so on, E’s failed

events in A’s routing table will be increased by 1.

Each time when the field of the successful or failed events changes, the

corresponding value of opinion will be recalculated using Equation 2 from the

evidence space to the opinion space.

If node E’s route entry has been deleted from node A’s route table because of expiry,

or there is no B’s route entry from the beginning, the opinion ωBA

will be set to

(0,0,1).

3.3.8 Trust Recommendation:

Existing trust models seldom concern the exchange of trust information. However, it

is necessary to design an information exchange mechanism when applying the trust models

into network applications. In our trust recommendation protocol, there are three types of

messages: Trust Request Message (TREQ), Trust Reply Message (TREF’), and Trust Warning

Message (WARN). Nodes who issue TREQ messages are called Requestor. Those who reply

TREP messages are called Recommender. The recommendation target nodes are called


Recommended. Any node may be a Requestor, a Recommender, or a Recommended. These

three types of messages share a common message structure.

3.4 System Description

It deals with understanding the problems, goals and constraints etc. During the

analysis, the problem domain and the environment are modelled in an effort to understand

the system behaviour, the constraints on the system its inputs and the outputs etc. The

understanding obtained by problem analysis forms the basis of the second activity-

requirement specification in which the focus is on clearly specifying the requirements in a

document. Issues such as representation, specification language and tools are addressed

during this activity .As analysis produces large amount of information and knowledge with

possible redundancies properly organizing and describing requirements in an important goal

of this activity.

3.4.1 Problem Statement:

Initial MANET routing protocols were not designed to withstand malicious nodes

within the network or outside attackers nearby with malicious intent. Subsequent protocols

and protocol extensions have been proposed to address the issue of security. Many of these

protocols seek to apply cryptographic methods to the existing protocols in order to secure

the information in the routing packets. It was quickly discovered, however, that while such

an approach does indeed prevent tampering with the routing information, it also makes for a

very simple denial of service (DoS) attack.

3.4.2 Existing System:

The protocols such as DSDV, DSR, and AODV focused on problems that mobility

presented to the accurate determination of routing information. DSDV is a proactive protocol

requiring periodic updates of all the routing information. In contrast, DSR and AODV are

reactive protocols, only used when new destinations are sought, a route breaks, or a route is

no longer in use.

As more applications were developed to take advantage of the unique properties of

ad-hoc networks, it soon became obvious that security of routing information was an issue

not addressed in the existing protocols.

3.4.3 Proposed System:


In this project, we provide the first performance evaluations for two proposed

protocol extensions to secure MANET routing. The first, SAODV, uses cryptographic methods

to secure the routing information in the AODV protocol. The second, TAODV, uses trust

metrics to allow for better routing decisions and penalize uncooperative nodes. . It was

quickly discovered, however, that while such an approach does indeed prevent tampering

with the routing information, it also makes for a very simple denial of service (DoS) attack.

The system works on the java jdk1.3 or more versions, which should have knowledge in

swings packages, Networking packages and works on windows 98 or more versions with

20GB Hard disk space, 128MB RAM and Pentium processor respectively.

4. DESIGN AND IMPLEMENTATION

The Unified Modelling Language (UML)

It is a standard language for writing a software blueprints. The UML may be used

Visualize

Specify

Construct

Document, the artifacts of a software system.

The UML is appropriate for modelling systems ranging from enterprise information

systems to distributed web-based applications and even to hard real time embedded

systems. It is very expressive language, addressing all the views needed to develop and

then deploy such systems.

Learning to apply the UML effectively starts with forming a conceptual model of the

language, which requires three major elements.

The UML basic building blocks

The rules that dictate how these building blocks may be put together

Some common mechanisms that apply throughout the language.

4.1 An overview of the UML

The UML is a language for

Visualizing


Specifying

Constructing

Documenting, the artefacts of a software system.

A language provides a vocabulary and the rules for combining words in that

vocabulary for the purpose of communication. A modelling language is a language whose

vocabulary and rules focus on the conceptual and physical representation of a system. A

modelling language such as the UML is thus a language for software blueprints.

4.1.1 UML is a language for visualizing:

The UML is more than just a bunch of graphical symbols. Behind each symbol in the UML

notation is a well defined semantics.

4.1.2 UML is a language for specifying:

Specifying means building models that precise, unambiguous and complete. In particular the

UML addresses the specification of all the important analysis, design, and implementation

decisions that must be made in developing and deploying a software intensive system.

4.1.3 UML is a language for constructing:

UML is not a visual programming language, but its models can be directly connected to a

variety of programming languages. It is possible to map from a model in the UML to a

programming language such as Java or C++ or visual basic or even to tables in a relational

database.

This mapping provides forward engineering. The generation of code from UML model into a

programming language. The reverse is also possible called reverse engineering. You can

reconstruct a model from an implementation back into the UML. Combining these two paths

or forward code generation and reverse engineering yield round trip engineering.

4.1.4 UML is language for documenting:

A health software organization produces all sorts of artifacts in addition to raw executable

code. These artifacts include

Requirements


Architecture

Design

Source code

Project plans

Tests

Prototypes

Releases

The UML addresses the documentation of a system’s architecture and all of its

details. The UML also provides a language for expressing requirements and for tests. Finally,

the UML provides a language for modelling the activities of project planning and release

management.

Where can the UML are used

Enterprise information systems

Banking and financial services

Telecommunications

Transportation

Defence/air force

Distributed web based services

4.2 A conceptual model of the UML

To understand the UML, you need to form a conceptual model of the language and this

requires learning three major elements.

The UML basic building blocks

The rules that dictate how these building blocks may put together

Some common mechanisms that apply throughout the UML

4.2.1 Building blocks of the UML:

The vocabulary of the UML encompasses three kinds of building blocks:

Things

Relationships

Diagrams

4.2.2 Things in the UML:


There are four kinds of things in the UML

Structural things

Behavioural things

Grouping things

Annotational things

4.2.3 Relationships in the UML:

There are four kinds of relationships in the UML

Dependency

Association

Generalization

Realization

4.2.4 Diagrams in the UML:

A diagram is the graphical presentation of a set of elements, most often rendered as

a connected graph of vertices (things) and ares (relationships). We draw diagrams to

visualize a system from different perspectives so a diagram is a projection into a system.

For all but the most trivial systems, a diagram represents an elided view of the elements

that make up a system. The same element may appear in all diagrams, only a few diagrams

(the most common case) or in no diagrams at all (a very rare case). In theory, a diagram

may contain any combination of things and relationships. In practice, however, a small

number of common combinations arise, which are consistent with the five most useful views

that comprise the architecture of a software-intensive system. For this reason, the UML

include nine such diagrams.

Diagrams in the UML are of two types

Static Diagrams

Dynamic Diagrams

Static diagrams consists of

Class diagram

Object diagram

Component diagram

Deployment diagram


Dynamic diagrams consists of

Use case diagram

Sequence diagram

Collaboration diagram

State chart diagram

Activity diagram

4.3 UML Diagrams

4.3.1 Class Diagram:

A class diagram shows a set of classes, interfaces, and collaborations and their

relationships. These diagrams are the most common diagrams found in modelling object-

oriented systems. Class diagrams address the static design view of a system. Class diagram

that include active classes address the static process view of a system.

4.3.1.1 Class: It is a description of a set of objects that share the same attributes,

operations, relationships, and semantics. A class implements one or more interfaces.

Graphically a class is rendered as rectangle usually including its name, attributes, and

operations as shown in figure.

Figure 4.3.1.1 A UML class Example

4.3.1.2 Interface: An interface is a collection of operations that specify a service of class or

component. An interface defines a set of operation specifications (that is their signatures)

but never a set of operation implementations. Graphically an interface is rendered as a circle

together with its name. An interface defines a set of operation specifications (that is, their

signatures) but never a set of operation implementations. The declaration of an interface

looks like a class with the keyword «interface» above the name; attributes are not relevant,

except sometimes to show constants.


Window

OriginSize

Open ()Close ()Move ()Display ()

Interface name

Figure 4.3.1.2 A UML Interface Example

4.3.1.3 Collaboration: It defines an interaction and is a society of roles and other

elements that work together to provide some cooperative behaviour that’s bigger than the

sum of the elements. Therefore collaborations have structural as well as behavioural

dimensions. A given class might participate in several collaborations. These collaborations

therefore represent the implementation of patterns that make up a system. Graphically,

collaboration is rendered as an ellipse with dashed lines including only its name.

Figure 4.3.1.3 A UML Collaboration Example

4.3.1.4 Dependency: It is a semantic relationship between two things in which a change to

one thing (the independent thing) may affect the semantics of the other thing( the

dependent thing) . Graphically, a dependency is rendered as a dashed line, possibly directed

and occasionally including a label as shown in the fig.

Semantic relationship

Figure 4.3.1.4 A UML Dependency Example

4.3.1.5 Association: It is the structural relationship that describes a set of links, a link

being a connection among objects. Aggregation is a special kind of association, representing

a structural relationship between a whole and its parts. Graphically, an association is

rendered as a solid line, possibly directed, occasionally including a label and often

containing adornments, such as multiplicity and role names as shown in the fig.

0..1 *


Chain ofresponsibility

employer employee

Figure 4.3.1.5 A UML Association Example

4.3.1.6 Generalization: Is specialization/generalization relationship in which objects of the

specialized element (the child) are substitutable for objects of the generalized element (the

parent). In this way the child shares the structure and the behavior of the parent.

Graphically a generalization is rendered as a solid line with a hollow arrowhead pointing to

the parent as shown in the fig.

Specialization relationship

Figure 4.3.1.6 A UML Generalization Example

4.3.1.7 Realization: A realization is a semantic relationship between classifiers, wherein

one classifier specifies a contract that another classifier guarantees to carry out. You'll

encounter realization relationships in two places: between interfaces and the classes or

components that realize them, and between use cases and the collaborations that realize

them. Graphically, a realization relationship is rendered as a cross between a generalization

and a dependency relationship

Figure 4.3.1.7 A UML Realization Example


login

user idpassword

accept()reject()

user

useridpassword

login()logout()register()discuss()

1..*1 1..*1

access

upload()download()browse()

personalize

nameageiddesignationdepartment

update personal info()change password()delete account()

administrator

updateabort user

accept user()reject user()

1

1..*

1

1..*

stores data

user details

request

Figure 4.3.1.8 An example for class diagram

Password

user idpassword

password()

RSA key

exponent valueN value

EnRSA()timers()RSAkeydsgn()send()

sender

upload contentdestination address

send()upload()

RSAdecry

Decrypt valueN value

ProcessDecryp()DERSA()

Req

RequestAcknowledgement

sendAck()Receive()


Figure 4.3.1 Class Diagram for communication between the source and destination

Description:

As shown in the above figure the class diagram explains the static design view of the

system. In this the password class consists of user id and password fields to be provided by

the user. The sender class i.e. the source end consists of the upload content where the user

uses it to upload the data and the destination address fields where the destination end user

address is entered. The RSA key class consists of the public key attributes to be entered by

the source end user for encryption of the data. The Req class acts as the destination end,

where it sends acknowledgement to the source end, thus the communication between the

source and the destination. The RSAdecry class consists of the decrypt value and the N

value attributes, which are provided by the destination user to decrypt the data.

4.3.2 Use case Diagram:

4.3.2.1 Use case: A use case is a description of set of sequences that a system performs

that yields an observable result of value to a particular actor. A use case is used to structure

the behavioural things in a model. A use case is realized by collaboration. Graphically a use

case is rendered as an ellipse with solid lines, including only its name.

Figure 4.3.2.1 Use case

4.3.2.2 Actor: Actor is the user of the system, who performs action on the system and to

whom the system yields an observable result of a value.

Figure 4.3.2.2 Actor


Place order

help info

register

login

personalize

browse

download information

upload information

logout

updates

abort useradministratoruser

access permissions

Figure 4.3.2.3 An example for use case diagram


select Routing protocol

Route mainatanence

Find request zone

sending route request to all nodes in the zone

Retrive route path from destination node

Node i

send and receive data with cryptographic encryption

Node j

Figure 4.3.2 Use Case Diagram for communication between the source and destination nodes

Description:

The above use case diagram consists of two nodes i.e. node i and node j, where node

i is the source and node j is the destination. Source node sends the route request to the

destination; if the destination node accepts the route request then it sends the

acknowledgement to the source, So that the nodes can send and receive the data.

4.3.3 Sequence diagram:


Both sequence diagrams land collaboration diagrams are kinds of interaction

diagrams. An interaction diagram shows an interaction, consisting of a set of objects and

their relationships, including the messages that may be dispatched among them.

Interaction diagrams address the dynamic view of a system. A sequence diagram is an

interaction diagram that emphasizes the time-ordering of messages, a collaboration

diagram is an interaction diagram that emphasizes the structural organization of the

objects that send and receive messages. Much like the class diagram, developers typically

think sequence diagrams were meant exclusively for them. However, an organization's

business staff can find sequence diagrams useful to communicate how the business

currently works by showing how various business objects interact.

4.3.3.1 Object: Objects are typically named or anonymous instances of class but may also

represent instances of other things such as components, collaboration and nodes.

4.3.3.2 Link: A link is a semantic connection among objects i.e.; an object of an association

is called as link.

4.3.3.3 Lifeline: A life line is vertical dashed line that represents the lifetime of an object.

When drawing a sequence diagram, lifeline notation elements are placed across the top of

the diagram. Lifelines represent either roles or object instances that participate in the

sequence being modelled.

4.3.3.4 Focus of Control: A Focus of control is tall, thin rectangle that shows the period of

time during which an object is performing an action.

4.3.3.5 Messages: A message is a specification of a communication between objects that

conveys the information with the expectation that the activity will ensue. To show an object

(i.e., lifeline) sending a message to another object, you draw a line to the receiving object

with a solid arrowhead (if a synchronous call operation) or with a stick arrowhead (if an

asynchronous signal). The message/method name is placed above the arrowed line. The

message that is being sent to the receiving object represents an operation/method that the

receiving object's class implements.


Node i Node jNetwork configuration

Buffer managers

Select routing protocol

Find request zone

send RREQ messege

RREP messege

Generate packetsProcess packets

Generate ack packetssending ack packets

Figure 4.3.3 Sequence Diagram for communication between the source and destination nodes

Description:

The above sequence diagram illustrates the dynamic behaviour of the system. As

shown in the above figure the nodes i and j communicate through the network configuration.

The buffer managers are used for the temporary storage of data.


4.3.4 State chart Diagram:

A state chart diagram shows a state machine, consisting of states, transitions,

events, and activities. State chart diagrams address the dynamic view of a system. They

are especially important in modelling the behaviour of an interface class, or collaboration

and emphasize the event ordered behaviour of an object, which is especially useful in

modelling reactive systems. State diagrams depict the dynamic behaviour of the entire

system.

4.3.4.1 Initial State:

This shows the starting point or first activity of the flow denoted by a solid circle. This

is also called as a "pseudo state," where the state has no variables describing it further and

no activities.

Figure: 4.3.4.1 Initial State

4.3.4.2 State:

A state is a condition or situation in the life of an object during which it satisfies some

condition, performs some activity, or waits for some event represents the state of object at

an instant of time. In a state diagram, there will be multiple of such symbols, one for each

state of the Object we are discussing denoted by a rectangle with rounded corners and

compartments.

Figure: 4.3.4.2 State

4.3.4.3 Transition:

A transition is a relationship between two states indicating that an object in the first

state will perform certain actions and enter the second state when specified event occurs

and specified conditions are satisfied.

Figure: 4.3.4.3 Transition


4.3.4.4 Event and Action:

An event is the specification of a significant occurrence that has a location in time

and space. A trigger that causes a transition to occur is called as an event or action. As

described above, an event/action is written above a transition that it causes.

Figure: 4.3.4.4 Event or Action

4.3.4.5 Final State:

The end of the state diagram is shown by a bull's eye symbol, also called a final

state. A final state is another example of a pseudo state because it does not have any

variable or action described.

Figure: 4.3.4.5 Final State

Figure: 4.3.4.6 An example for state chart diagram


sends the data

data1 data2

creates the ACG gap between RTS/CTS

sends the acknowledgement

data recieved by node2

Select routing protocol

Route maintanence

Find request zone

Send route request (RREQ)

Retrieve route reply (RREP)

Send and receive data with cryptographic encryption

sending acknowledgement to received data

Figure 4.3.4 State Chart Diagram for communication between the source and destination nodes

Description:

The above state chart diagram illustrates the step by step process of the system. The

source end user of the system sends the route request to the destination user, if the

acknowledgement is received from the destination the nodes can send and receive data.

The encryption and decryption process is performed while sending the message from source

to destination.


4.4 Data Flow Diagrams:

A data flow diagram (DFD) is a graphical representation of the "flow" of data through

an information system. It differs from the system flowchart as it shows the flow of data

through processes instead of hardware. A data flow diagram can also be used for the

visualization of data processing (structured design).

4.4.1 Data Flow Diagram Principles:

The general principles in data flow diagramming is that a system can be decomposed

into lower level system and soon.

Each subsystem represents a process or activity in which data is proposed.At the

lowest level processes can no longer be decomposed.

Each process in a data flow diagram has the characteristics of a system.

4.4.2 Data Flow Diagram shows:

The process within the system.

The data stores supporting the system’s operation.

The information flows within the system.

The system boundary.

Interactions with external entities.

4.4.3 Data Flow Diagram Symbols:

Data flow diagram symbols are follows.

4.4.3.1 External Entity:

An external entity is a source or destination of a data flow which is outside the area

of study. Only those entities which originate or receive data are represented on a business

process diagram. The symbol used is an oval containing a meaningful and unique identifier.

4.4.3.2 Process:

A process shows a transformation or manipulation of data flows within the system.

The symbol used is a rectangular box which contains 3 descriptive elements:


Firstly an identification number appears in the upper left hand corner. This is allocated

arbitrarily at the top level and serves as a unique reference.

Secondly, a location appears to the right of the identifier and describes where in the system

the process takes place. This may, for example, be a department or a piece of hardware.

Finally, a descriptive title is placed in the centre of the box. This should be a simple

imperative sentence with a specific verb, for example 'maintain customer records' or 'find

driver'.

Figure 4.4.3.2 Process

4.4.3.3 Data Flow:

A data flow shows the flow of information from its source to its destination. A data

flow is represented by a line, with arrowheads showing the direction of flow. Information

always flows to or from a process and may be written, verbal or electronic. Each data flow

may be referenced by the processes or data stores at its head and tail, or by a description of

its contents.

Figure 4.4.3.3 Data flow

4.4.3.4 Data Store:

A data store is a holding place for information within the system: It is represented by

an open ended narrow rectangle. Data stores may be long-term files such as sales ledgers,

or may be short-term accumulations: for example batches of documents that are waiting to

be processed. Each data store should be given a reference followed by an arbitrary number.

Figure 4.4.3.4 Data store

4.4.3.5 External agent: An external agent is a source or destination of data. The external

agent occurs outside of the system of processes. An external agent is depicted by an

overlapping rectangle.

Figure 4.4.3.5 External agent


Source

Figure 4.4.1 Establishing of security between source and destination

Description:

The above diagram illustrates the routing protocols, route maintenance and

providing the security using these routing protocols between the source and the destination.

Secure AODV VS Trusted AODV Protocols for MANET routing security 61INPUT FILE

MANET RoutingProtocols

Route Maintenance

Retrieve route path from destination

Destination

Find request zone and send route request to all nodes in

that zone

Send and Receive data using that path

With Cryptographic Encryption.

Input

Manager

Input

NETWORK CONFIGURATION

Figure 4.4.2 Pictorial representation of the communication between the networks

Description:

The above diagram gives the description of how the data is transferred between the

source and the destination with the help of the process manager, the buffer networks

consists of the data to be transferred and the Network configuration consists of the

information about the protocols and the different nodes in the network.


NETWORK j

NETWORK i

BUFFERS OF NETWORKS

Network Configuration

Packets

Packets

Figure 4.4.3 Overview of the packet processing between the networks

Description:

As shown in the above figure, it gives how the source and the destinations networks

communicate between each other. The Buffer networks stores the data and sends it at the

time of receipt. The Input manager consists of the network configuration of the nodes and

the protocols.

5. TEST CASES

In this project work we have tested the proposed system using the java swing

packages and some networking packages. In order to get an understanding for the

performance of SAODV and TAODV protocols, we have implemented each of them and

measured their performance through threshold and static values.

In order to implement SAODV, it was necessary to have cryptographic operations. We

used RSA algorithm, in which the user has to provide two prime numbers. Based on the

prime numbers the public and private keys are calculated. After selecting two prime

numbers the exponent and ‘n’ values are calculated, then a number ‘e’ is picked which is

the public key such that the greatest common divisor of ‘e’ and exponent value should be 1.

Then ‘d’ which is private key is relatively prime to exponent and multiplicative inverse of ‘e’.

The encryption and decryption are done using the ‘e’ and‘d’ values which are used in the

formulas to encrypt and decrypt.

Implementing TAODV required similar to those involved in SAODV. In this project, we

used three levels of trust i.e. low level of trust, medium level of trust and high level of trust.

These trust levels are measured depending on the prime numbers supplied. We have

specified ranges for the three trust levels, so that when the user provides prime numbers

comparison is done in which trust level does it belong to and a dialog window show the trust

level.

Test case 1:

During the test case 1, first the user specifies the user-id and password to enter into

the source end of the system. From here the user can upload the data or may do changes if

any provided in the text area and should also specify the destination address correctly for


the communication. In meanwhile the public and private keys are generated and the public

key is used to encrypt the message and the private key is sent to destination user after the

source has received the acknowledgment from it, private key is sent at the backend. When

the destination user receives the message, uses private key to decrypt the message. Then

the performance result is shown in a result window, which has the network performance and

security risk of both the protocols measured using threshold and static values.

Figure 5.1 Source end login

This page is the login prompt at the source end in which user-id and password fields are to

be provided. If the user doesn’t give correct details then login fails and gives error messages

i.e., which ever the field is wrongly entered. When the user provides correct details to login,


then the user-id and password fields are compared with the one provided in the code file

and if the comparison goes perfectly the user can enter into the source end to send the data

to destination user. If the comparison fails, error messages are displayed according to the

one which has gone wrong i.e., the user-id or the password field.

Figure 5.2 Source end window with file chooser

This is the source end window with uploaded content, destination address, upload button,

send button. In the uploaded content, the user provides the data or information to be sent to

destination address and in that text area he can type the message directly or can also


upload text file using the upload button provided in the window. The user can browse the

directory using the file chooser window appears when clicked on the upload button. At the

destination address text box, the user has to specify the destination address i.e., the

computer name. When the user chooses file through upload button the message is displayed

in the uploaded content text area and the send button is used to send the message to the

destination which is provided in the destination address.

Figure 5.3 Source end window with message content

This page appears when the login details are correctly specified and it contains the message

to be sent (i.e., given by the user) and the destination address. The uploaded content has

the message which is uploaded by the user using the upload button. The destination address


has the computer name of the destination is specified by the user at the source end to send

the message to the destination end. The send button is used to send the data to the

destination user when clicked should follow the process to encrypt the data and to keep the

data secure while not tracked by the third user.

Figure 5.4 RSA key generation

The above window appears when the user clicks the send button which gives the RSA Key

window. Then the user has to click on the RSAKeyGen button in the RSA KEY window. The

user has to provide two prime numbers P, Q respectively. If the user fails to provide prime


number and instead given a random number, then it gives error message stating that

provide correct prime numbers in the fields provided. The error messages are displayed at

the back end i.e., in the command prompt. After providing the correct details the user can

click the ok button provided in that window to generate keys.

Figure 5.5 Level of trust

The level of trust appears with the values provided in the RSA Key Generation window. In

that the user specifies the prime numbers, based on the prime numbers the trust level is

measured. Here the user entered into high level trust as he has specified the prime values


which are greater than 100. The user has to provide correct prime numbers otherwise the

trust level is not measured and it also display error message stating the user that please

provide correct prime numbers so that the trust level can be measured.

Figure 5.6 Public and private key generation

The public and private keys are generated based on the prime numbers provided by the

user and the level of trust. The public key has the exponent value and the N value, which

should be noted down by the user to encrypt the message. The private key has the


decryption key and the N value. The private key is given to the destination user at the

backend such that the destination can receive the message using the values provided in

private key. The public key exponent value is different from the private key decryption value

and the N value both in public key and private key is same.

Figure 5.7 RSA encryption key values

The exponent value and N value should be provided by the user after he generates the

public and private key values using the prime numbers and level of trust. The user has to

provide the correct exponent value and N value which is generated previously and the send


button is used to send the encrypted message. When the user clicks the send button in RSA

KEY in the backend the system is going to create a socket with the destination address

specified in the enter the destination address text box. If the correct destination is found

then it sends a route request to destination address and waits for the acknowledgement

from the destination for to transfer message between them.

Figure 5.8 Destination end

The above window is the Destination end window which has the request and

acknowledgement columns. In which the request message from source address is shown

and the source end user is waiting for the acknowledgement from the destination end. The


destination end window acts as the server and the user has to note one point in mind that

before starting the client i.e. source end login window he/she has to start the server i.e. the

destination end window. The computer name which is displayed in the request column of

destination end the same name has to be specified as the destination address in the source

end window. If the destination sends the acknowledgement then the source sends the file

i.e. communication between the nodes is opened now.

Figure 5.9 Acknowledgement received from destination

The acknowledgement window appears whenever the destination address is found i.e. the

source is going to create a socket with the destination address if the address specified is

correct and then the destination sends the acknowledgement. If the user click ok button, the


sender can now send the data i.e. after receiving the acknowledgement from the

destination. The path from source to destination is laid down to send the message from

source to destination. The source address, destination address, local address are same, as

we are executing in the same system itself.

Figure 5.10 File received from source end

The file received window appears whenever the source end user accepts the

acknowledgement from the destination i.e. the source is going to create a socket with the

system destination address, if the destination address is found then it creates a socket with


the destination. Then the destination sends acknowledgement to the source, after receiving

the acknowledgement the sender can send the data now, the path from source to

destination is laid down and the file is received at the destination end. When the destination

user accepts the file he/she directly cannot view the message as it is encrypted and the user

has to provide decryption values to view the message.

Figure 5.11 RSA decryption values

As shown in the above figure the destination end user will be able to receive the message

after entering the decryption values. At the destination end the message is received after

the request from source to destination and if the destination sends acknowledgement to


source. The source can send the data now and file is received at the destination end. The

receive window has a text area in which the message is displayed after entering the

decryption values, as the message is encrypted by the source end user. The destination user

has to provide the decryption values by clicking the receive button on the window displayed.

The decryption value and N value has to be specified correctly to get the message in text

format, otherwise the text will not be in human readable form.

Figure 5.12 Original message with performance result

In the receive window the message is received after entering the decryption values. The

destination user has to provide correct decryption values to get the original text message.

After receiving the original text message, the result window appears and shows the


performance result which has the comparison of both the secure AODV and trusted AODV. If

the secure AODV is used to send the message the security risk is 0.4% and the network

performance is 95%, whereas for the trusted AODV the security risk is 19% and network

performance is 75%. From this we can say that risk is more in trusted AODV than the secure

AODV.

Test case 2:

In the test case 2, we consider different values for prime numbers. And the level of trust

changes w.r.to the prime numbers. In the test case 1, the user entered into high level of

trust, here in test case 2 user entered into low level of trust, depending on the prime

numbers the trust level is measured.

Figure 5.13 RSA key generation with low level trust


The low level of trust appears with the values provided in the RSA Key Generation window.

In that the user specifies the prime numbers, based on the prime numbers the trust level is

measured. Here the user entered into low level trust as he has specified the prime values

within the range from 1 to 25. The user has to provide correct prime numbers otherwise the

trust level is not measured and it also display error message stating the user that please

provide correct prime numbers, so that the trust level can be measured.

Figure 5.14 Original message with performance result for other trust level 1

In the receive window the message is received after entering the decryption values. The

destination user has to provide correct decryption values to get the original text message.

After receiving the original text message, the result window appears and shows the


performance result which has the comparison of both the secure AODV and trusted AODV. If

the secure AODV is used to send the message the security risk is 0.3% and the network

performance is 93%, whereas for the trusted AODV the security risk is 17% and network

performance is 69%. From this we can say that risk is more in trusted AODV than the secure

AODV.

Test case 3:

In this test case the user provides different prime numbers, which changes the trust level. In

test case 2 the user entered into medium level of trust, by this the performance result may

change according to the trust levels.

Figure 5.15 RSA key generation with medium level trust


The medium level of trust appears with the values provided in the RSA Key Generation

window. In that the user specifies the prime numbers, based on the prime numbers the trust

level is measured. Here the user entered into medium level trust as he has specified the

prime values within the range from 26 to 100. The user has to provide correct prime

numbers otherwise the trust level is not measured and it also display error message stating

the user that please provide correct prime numbers, so that the trust level can be measured.

Figure 5.16 Original message with performance result for other trust level 2

In the receive window the original message is received after entering the decryption values.

The destination user has to provide correct decryption values to get the original text

message. After receiving the original text message, the result window appears and shows


the performance result which has the comparison of both the secure AODV and trusted

AODV. If the secure AODV is used to send the message the security risk is 0.2% and the

network performance is 91%, whereas for the trusted AODV the security risk is 18% and

network performance is 64%. From this we can say that risk is more in trusted AODV than

the secure AODV.

6. CONCLUSION

In this project we have compared the Secure AODV and Trusted AODV protocols for

securing ad hoc network routing and presented the results of security risk and network

performance of both protocols. The expected difference between the two protocols was

shown to be consistent. These experiments showed that there is significant room between

the two protocols for a secure hybrid protocol to be developed which takes advantage of the

strongest points of both.


7. FUTURE WORK

Future work needs to delve further into the extensive body of work on various trust

metrics. This includes the testing of other trust metrics for use in ad-hoc routing as well as

developing the fore mentioned hybrid protocols and testing their performance against the

results presented in this project. Future protocol designs should seek to use various new

combinations of smarter, trust-based metrics and lightweight security mechanisms in order

to develop hybrid protocols.


8. BIBLIOGRAPHY

[1] Jared Cordasco, Susanne Wetzel. Cryptographic vs. Trust-based Methods for MANET

Routing Security, IEEE Volume 197, Issue 2, 2007.

[2] C. N.-R. Baruch Awerbuch, David Holmer and H. Rubens. An on-demand secure routing

protocol resilient to byzantine failures. In ACM Workshop on Wireless Security (WiSe),

September 2002.

[3] S. Buchegger and J.-Y. L. Boudec. Nodes Bearing Grudges: Towards Routing Security,

Fairness, and Robustness in Mobile Ad Hoc Networks. In Proceedings of the Tenth

Euromicro Workshop on Parallel, Distributed and Network-based Processing. IEEE

Computer Society, January 2002.

[4] Andrew S. Tanenbaum. Computer Networks, Fourth Edition, Prentice Hall PTR, 2001.

[5] P. Dewan and P. Dasgupta. Trusting routers and relays in ad hoc networks. In ICPPW ’03:

Proceedings of the 2007 International Conference on Parallel Processing Workshops,

pages 351–358, 2007.

[6] L. Eschenauer, V. Gligor, and J. Baras. On trust establishment in mobile ad hoc networks.

Technical Report MS 2002-10, Institute for Systems Research, University of Maryland,

MD, USA, October 2008.

[7] Yuh-Min Tseng, A heterogeneous-network aided public-key management scheme for

mobile ad hoc networks, International Journal of Network Management, v.17 n.1, p.3-15,

January 2007.

[8] T. Ghosh, N. Pissinou, and K. Makki. Collaborative trust-based secure routing against

colluding malicious nodes in multi-hop ad hoc networks. In LCN ’04: Proceedings of the

29th Annual IEEE International Conference on Local Computer Networks (LCN’04). IEEE

Computer Society, 2004.


[9] Y. Hu, D. Johnson, and A. Perrig. SEAD: Secure efficient distance vector routing for

mobile wireless ad hoc networks. Ad Hoc Networks, I:175–192, 2003.

[10] Y. Hu, A. Perrig, and D. Johnson. Packet leashes: A defense against wormhole attacks in

wireless adhoc networks. Technical report, Department of Computer Science, Rice

University, December 2001.

[11] Jian Yin , Sanjay K. Madria, ESecRout: An Energy Efficient Secure Routing for Sensor

Networks, International Journal of Distributed Sensor Networks, v.4 n.2, p.67-82, April

2008.

[12] Lijun Qian , Ning Song , Xiangfang Li, Detection of wormhole attacks in multi-path

routed wireless ad hoc networks: a statistical analysis approach, Journal of Network

and Computer Applications, v.30 n.1, p.308-330, January 2007.

[13] X. Li, M. Lyu, and J. Liu. A trust model based routing protocol for secure ad hoc

networks. In Proceedings of the Aerospace Conference, 2004.

[14] S. Marti, T. J. Giuli, K. Lai, and M. Baker. Mitigating routing misbehavior in mobile adhoc

networks. In Mobile Computing and Networking, 2000.

[15] K. Meka, M. Virendra, and S. Upadhyaya. Trust based routing decisions in mobile ad hoc

networks.In Proceedings of the Workshop on Secure Knowledge Management (SKM

2006), 2006.


Majordoc Rev 6

Documents

demand distance

manet routing

select routing

typically

trusted aodv

trusted routing

ad hoc networks

metropolitan