secure and policy compliant source routing1

7/28/2019 secure and policy compliant source routing1

1/50

1

1. INTRODUCTION

The main objective of this project is used to avoid the default and take the alternative

path, at the time to check the traffic of each path. Network operators and academic

researchers alike recognize that todays wide-area Internet routing does not realize the

full potential of the existing network infrastructure in terms of performance, reliability or

flexibility. While a number of techniques for intelligent, source-controlled path selection

have been proposed, there has been no way for ASes to ensure that such traffic does

not violate local traffic policies.

We present the design and evaluation of Platypus, a source routing system that, like

many source-routing protocols before it, can be used to implement efficient overlay

forwarding, select among multiple ingress/egress routers, provide virtual AS multi-

homing, and address many other common routing deficiencies. The key advantage of

Platypus is its ability to ensure policy compliance during packet forwarding. Platypus

enables packets to be stamped at the source as Policy compliant, reducing policy

enforcement to stamp verification. Hence, Platypus allows for management of routing

policy independent of route export and path selection.

Many of the deficiencies in todays routing policies are symptoms of coupling of routing

policy and routing mechanism. ASes express their local routing policy during BGP route

advertisement, affecting the routes that are chosen and exported to neighbors.

Similarly, ASes often adjust a number of attributes on routes they accept from their

neighbors according to local guidelines. As a result, configuring BGP becomes an

overly complex task, one for which the outcome is rarely certain. BGPs complexity

affects Internet Service Providers (ISPs) and end users alike; ISPs struggle to

understand and configure their networks while end users are left to wonder why end-to-

end connectivity is so poor.


2/50

2

Our approach to reducing this complexity is to separate the issues of connectivity

discovery and path selection. Removing policy constraints from route discovery

presents an opportunity for end users and edge networks. The key challenge becomes

determining whether a particular source route is appropriate. It is well known that

multiple paths often exist between any two points in todays Internet. The central tenet

of any source routing scheme is that no single route will be best for all parties. Instead,

sources should be empowered to select their own routes according to whatever criteria

they determine.


3/50

3

CHAPTER 2

BACKGROUND STUDY


4/50

4

2. BACKGROUND WORK

2.1 Border Gateway Protocol

The Border Gateway Protocol (BGP) is the de-facto interdomain routing

protocol between Autonomous Systems (ASes) that achieves global connectivity while

shielding intra-domain routing details and fluctuations from the external view. Recent

studies of BGP have indicated a significant growth in BGP routing tables, an increase in

route flapping and necessarily specific route announcements. The large growth in the

number of ASes that participate in BGP peering sessions has been fueled by stub

ASes. Our analysis of the BGP data from route views reveals that at least 60% of these

stub ASes are multi-homed to two or more providers, i.e., they announce BGP routes

via multiple upstream ASes. This trend towards increased connectivity to the Internet

and participation in inter-domain routing is placing more stress on the BGP

infrastructure. The scale of routing is increasing, and more features are being expected

out of it than BGP was designed to handle. For instance, this increasing trend towards

multi-homing is intended as a solution to achieve two goals: fault tolerance and load

balancing on inter-domain routes.

As an illustration, Figure 1 compares two scenarios where a stub AS is (a) single-

homed and (b) multi-homed to three providers. The stub AS, W, in Figure 1(b) can

choose to have its traffic go primarily through ISP X. If the link to ISP X fails, or when

there are failures along the path through ISP X, W can failover to ISP Y or Z. If it were

singly homed, as in case (a), it could only protect itself against upstream link failures by

purchasing multiple redundant links to ISP X. In addition, W can load-balance its

outgoing traffic by selecting the best route to the destinations via one of the three

providers. Route science and others automate outgoing traffic balancing by selecting

specific BGP announcements heard from different providers.

Achieving connectivity by subscribing to multiple providers is likely to be

expensive, but Mortimers study suggests that reliability is a deciding factor. However,

the effectiveness of multi-homing is limited by the slow convergence behavior of BGP.

Inter-domain routes can take upto 15 minutes to failover in the worst case. For


5/50

5

companies that rely on Internet connectivity to conduct online transactions, such a long

outage can have a severe financial impact. Furthermore, BGP allows an AS little control

over how the incoming traffic enters its network. As more networks connect to the

Internet via BGP, the likelihood of router misconfiguration will increase. With more

participants, the chance of having a malicious or compromised participant grows. As

has been observed in the past, a single incorrect routing announcement can seriously

impact data traffic. As yet, no protocol exists for detecting and stemming such bogus

route announcements.

Fig 2 Company W with ISP X,Y,Z

As more and more applications are enabled on the Internet, traffic will grow and

may become more unpredictable. Higher traffic use may incur higher transit costs for

stub networks that rely on ISPs for Internet service. During periods of abnormal traffic

patterns or even link failures, it may be advantageous for two entities that have a

business relationship for exchanging traffic to temporarily modify this agreement to

improve congestion or reduce transit costs. As yet, no protocol exists for negotiating

and applying such temporary agreements.

Fig 1 Company W with ISP X


6/50

6

2.2 Current state of BGP

2.2.1 Poo r rel iabi l i ty/ stabi l i ty

BGP is a notoriously difficult protocol to configure properly. We believe a significantportion of this complexity stems from the need to simultaneously optimize for route

efficiency and policy compliance. Part of the problem is that it is very hard to know

beforehand what the right configuration might be because policy goals cannot be

directly mapped to configuration settings; instead, operators must adjust a number of

overloaded parameter in hopes of coercing both their own internal network and adjacent

ASes to select the desired routes. In fact, its possible for local policy settings to

guarantee that the routing configuration will diverge. This issue could largely be avoided

if ASes could simply export all possible routes, and determine whether or not to forward

a particular packet (because it did or did not meet the ASs local policy constraints)

when it arrived at a border router. We believe that a mechanism for explicit routing can

free ASes to fully export routes as routing policy can be decoupled from route

computation and distribution.

2.2.2 Poo r reachabil i ty/ perform ance

Even if network operators manage to get BGP configured properly, BGP is slow to

adapt to changes in network topology . In addition, BGPdoes not have all of the existing

routes available to it; studies have shown that a large number of BGP outages can be

avoided by overlay networks [3], implying serviceable routes do exist. While it is

reasonable to assume many of the paths exploited by these overlays might not be

policy compliant (because they transit stub networks), how many would be is an open

question. We believe our approach could have two benefits: first, BGP may be able to

converge to a working path more rapidly when provided with the full set of available

routes; second, full route export could provide existing overlay techniques with more

alternatives. Overlay networks are constrained to select among the set of paths they


7/50

7

themselves can construct. We posit even greater redundancy exists in the network, but

is being concealed by policy-based route export filters.

2.2.3 Poo r accou ntabl i ty

There are few ways to determine where an Internet packet came from , none of which

are widely deployed. Further, even if a packets source is identified, there is no easy or

correct way to identity the accountable partyeither for the path selection or the

forwarding decision. Even if a packet is deemed admissible, the options for assigning

appropriate resource principals are few. The obvious candidates are either the adjacent

AS, or, should finer-grained accounting be desired, the source or destination IP. While

several router vendors now support class-based accounting, the lack of a mechanism

for defining consistent, globally-meaningful classes makes this functionality difficult to

utilize across ASes. Network capabilities provide an explicit, locally meaningful

accounting principal at each point in the network. Accounting and/or rate control can be

done on a per-flow or even a per-packet basis; recent results indicate such fine-grained

accounting is entirely plausible even at high speed. Our primary complaint is that the

current mechanisms for determining the appropriate resource principal and authorizing

agent are insufficient.

2.2.4 Poo r flexibi l i ty

All of BGPs ills could be forgiven (if not forgotten) if motivated networks and end hosts

could efficiently implement their own routing mechanisms. Unfortunatelybut

understandablyISPs are unwilling to allow external entities to influence their operation

in the absence of effective accounting and enforcement mechanisms. For a multi-

homed AS, the inability to affect in-bound routing is particularly limiting: an AS can

determine its own outgoing routes, and can limit the possible choices for the incoming

routes, but it cannot, in general, control which incoming link traffic from a particular AS

will arrive on. Such restrictions are painfully ironic, as they prevent ISPs from realizing

many of their own goals. For example, it is increasingly common for ASes to have

complex business relationship, where an adjacent AS is not entirely customer or peer,

but sometimes one or the other depending on the particular peering point.


8/50

8

2.3 RELATED WORK

Source routing has been included as a feature in many Internet architectures over the

years. For example, Nimrod defined mechanisms for packets to be forwarded in both

flow-based and source-routed, per-packet fashions. Similarly, IPv6 provides support for

the source demand routing protocol, SDRP. SDRP allows for hosts to specify a strict or

loose source route of ASes or IP addresses through which to route a packet. More

recently, Yang described a new addressing architecture called NIRA with the explicit

goal of providing AS-level source routing. NIRA path selection consists of two stages:

an initial discovery phase followed by an availability phase in which a host determines

the quality of a particular route. A contemporary proposal, BANANAS, allows for explicit

path selection in a multi-path environment, but does not allow for the insertion ofarbitrary intermediate hops. None of these proposals, however, have addressed the

need to verify policy compliance of the specified route on the forwarding plane. To the

best of our knowledge, we are the first to present a fully decentralized, authenticated

source-routing architecture.

Frustrated with the lack of control provided by current wide-area Internet routing,

researchers have proposed circumventing it entirely by forwarding packets between end

hosts in an effort to construct routes with more desirable path characteristics.

Unfortunately, the effectiveness of any overlay-based approach is fundamentally limited

by both the number and the locations of the hosts involved in the overlay.We believe

Platypus addresses both of these issues: overlay networks can view far away Platypus

routers as additional members of the overlay and use nearby Platypus routers to

increase the efficiency of their forwarding mechanisms.

Stoica et al. suggest that indirection be explicitly supported as an overlay network

primitive; in the Internet Indirection Infrastructure (i3) packets may include a set of

indirection points through which they wish to be forwarded. Unlike Platypus waypoints,

however, i3 IDs specify logical entities, not necessarily network routing hops. Each ID is


9/50

9

associated with one or more application-installed triggers that can involve arbitrary

packet processing; there are no guarantees about the topological location of the overlay

node(s) responsible for a particular ID. Packet-level authentication credentials have

been suggested in a number of other contexts. IPsec-enabled packets may contain an

authentication header with information similar to a network capability, except without a

routing request. In order to verify authentication headers, however, IPsec routers must

hold one key for each source, far more than with Platypus. Per-packet authenticators

have also been proposed to prevent DoS attacks; it would be straightforward to

implement a similar scheme using Platypus. Perhaps the most closely related use is

due to Estrin et al., who introduced the notion of visas that confer rights of exit from one

organization and entry into another. Stateless visas provide a mechanism for per-packet

authentication between two independent organizations, but not for expressing routing

requests. Visas are the result of a bilateral agreement between a packets source and

destination; each packet contains exactly two visasone for the source organization

and one for the destination. In contrast, network capabilities are concerned with

authentication and routing through intermediate ASes.


10/50

10

CHAPTER 3

PLATYPUS SYSTEM


11/50

11

3. PLATYPUS SYSTEM

To create an authenticated source routing system built around the concept of

network capabilities which allow accountable fine grained path selection by

cryptographically attesting policy compliance at each hop.

3.1 OVER VIEW OF PLATYPUS SYSTEM

Our approach to reducing this complexity is to separate the issues of connectivitydiscovery and path selection. We present Platypus, an authenticated source routing

system built around the concept of network capabilities, which allow for accountable,

fine-grained path selection by cryptographically attesting to policy compliance at each

hop along a source route. Capabilities can be composed to construct routes through

multiple ASes and can be delegated to third parties. Platypus caters to the needs of

both end users and ISPs: users gain the ability to pool their resources and select routes

other than the default, while ISPs maintain control over where, when, and whose

packets traverse their networks. We describe the design and implementation of an

extensive Platypus policy framework that can be used to address several issues in

wide-area routing at both the edge and the core, and evaluate its performance and

security. Our results show that incremental deployment of Platypus can achieve

immediate gains.

Consider the partial network topology shown in Figure 2. Nodes A, B, and C are all

willing to cooperate to forward each others traffic. Assume that A wishes to send a

packet to B, but the default routeA R3 R4 B is unsatisfactory, perhaps because

the link R3 R4 is congested or down. With prior overlay systems,A could use Cas a

transit point by tunneling its traffic directly to C, who would then forward it along to B.

While effective at avoiding the bad link, this route is clearly sub-optimal for all involved,

since:


12/50

12

1. C is forced to forward each packet itself, consuming both its bandwidth (in both

directions) and processor resources. It would prefer that R8 forward the traffic instead;

likewise, R8 would prefer that R7 forward the traffic.

2. Any path from A to B through R7 is likely suboptimal unless the R5 R6 link is

congested.

3. If avoiding R3 R4 is the objective, an alternate route exists using the R1 R2 link.

IfCs ISP also owns R1 and R2, Cshould be able to authorize use of the link R1 R2.

Fig 3 Simple network topolo gy


13/50

13

The first issue could be addressed by traditional source-routing schemes, requiring that

A specify the route R3 R5 R7 R6 R4 B. The challenge is in

communicating to Cs ISP that such a route request is reasonable. In this case,

assuming Cs ISP is not a transit provider, it is permissible only because C is a

customer of the ISP and is willing to be charged forAs traffic. With existing source-

routing mechanisms, an AS cannot determine whether a forwarding request complies

with local policy, and, if so, who to charge for the service. Currently, an AS assumes

that packets should arrive at its border only if it advertised a route to their destinations.

In our example, a packet destined forB should not arrive at R5 from R3; it should go

directly to R4. Source-routed packets can obviously be made to explicitly transit any AS,

violating this precondition. While ISPs can (and do) use filters to prevent unauthorized

traffic from entering their network, filters can only act upon information contained within

a packetsource and destination addresses, protocol, type of service, etc.and

current network location. These attributes are insufficient to determine policy

compliance or the responsible party in this case. Nothing about the source-routed

packet from A to B indicates Cs cooperation (and resulting policy compliance). In

Platypus, C, by virtue of being a customer of its ISP, may have authority to source route

through any of the ISPs routers. In that case, Cs ISP would issue Ca capability and a

secret key that can be used to stamp packets. The capability would name C as the

resource principalthe party responsible for all traffic bearing the capability. Platypus

ensures the policy compliance of a given source route by requiring that source-routed

packets contain a capability for each waypoint in a packets source route. Because the

secret key needed to stamp packets is known only to the indicated resource principal

(or its associates), properly stamped packets certify their policy compliance and allow

waypoints to appropriately account for usage. We posit that ASes conduct a priori

negotiations with customers and each other to determine mutually agreeable policies

about who may source route traffic through which waypoints (similar to todays peering

agreements ). Efficiently describing or constructing such policies is a complex problem

on its own; we do not discuss it here. Instead, we assume the output of this process is a

set of rights which can be encoded as a matrix of binary entries: for each waypoint in

the network, a given resource principal may or may not forward traffic through it.


14/50

14

Capabilities expire periodically and can be revoked, allowing ASes to dynamically

update their policies. Returning to our example, C could transfer its capability to A,

allowingA to construct a source route that can alleviate all three issues, depending on

the waypoint specified in the capability. If the capability specifies R7 as a waypoint, the

first problem is solved. If, on the other hand, the waypoint simply refers to any router

within Cs ISP, the second problem is addressed automatically by the intra-AS routing

protocol, which forwards the packet along the most efficient route from R5 (which would

serve as the waypoint). Finally, ifCwere to request a capability specifically naming R1

as a next hop, even the third issue can be addressed. While we have described A, B,

and Cas end hosts for simplicity, Platypus is designed to allow in-network stamping.

Hence, each of these entities could correspond to entire ASes, allowing the example to

be recast as a type of secondary transit, where Ca stub domaincan resell its transit

privileges to other, non-adjacent stub domains without prior involvement of its provider.

3.2 TECHNIQUES USED

1. Networking

2. ISP

3. Load Balancing

4. Platypus Framework

5. Encryption


15/50

15

3.2.1 DESCRIPTION OF TECHNIQUES

3.2.1.1 Networking

Client-server computing or networking is a distributed application architecture that

partitions tasks or workloads between service providers (servers) and service

requesters, called clients. Often clients and servers operate over a computer network on

separate hardware. A server machine is a high-performance host that is running one or

more server programs which share its resources with clients. A client also shares any of

its resources; Clients therefore initiate communication sessions with servers which await

(listen to) incoming requests.

3.2.1.2 ISP

Autonomous systems (ASes) express their local routing policy during BGP route

advertisement by affecting the routes that are chosen and exported to neighbors.

Similarly, ASes often adjust a number of attributes on routes they accept from their

neighbors according to local guidelines. As a result, configuring BGP becomes an

overly complex task, one for which the outcome is rarely certain. BGPs complexity

affects Internet Service Providers (ISPs) and end users alike; ISPs struggle to

understand and configure their networks while end users are left to wonder why End-to-

end connectivity is so poor.

3.2.1.3 Load Balancing

Platypus users forward their traffic through selected waypoints. For example, a Web

site that purchases Platypus service from an ISP; traffic that the server sends to specific

clients uses Platypus to selectively improve performance. However, given the popularity

of the website, it may overload a single waypoint at certain times of the day. To remedy

this issue, we consider a policy in which the server selects a set of waypoints to forward

traffic through and load balances across them. This functionality is important in many

applications, since it is unlikely that a single waypoint can suffice for an arbitrarily large


16/50

16

traffic volume. Using the Platypus policy framework, we evaluate a Web server

application scenario, with probabilistic load balancing across two waypoints. Each client

makes ordinary HTTP requests to the server. The servers replies are stamped

according to a policy that begins by sending all response traffic through a single

waypoint. Halfway through the experiment we change the policy such that the response

traffic is load balanced at the granularity of a TCP flow.

3.2.1.4 Platypus framework

We present the design and evaluation of Platypus, a source routing system that, like

many source-routing protocols before it, can be used to implement efficient overlay

forwarding. The key advantage of Platypus is its ability to ensure policy compliance

during packet forwarding. Platypus enables packets to be stamped at the source as

being policy compliant, reducing policy enforcement to stamp verification. Hence,

Platypus allows for management of routing policy Independent of route export and path

selection. Platypus uses network capabilities, primitives that are placed within individual

packets, to securely attest to the policy compliance of source routing requests. Network

capabilities are within individual packets, to securely attest to the policy compliance of

source routing requests. Network capabilities are:

i) transferable : an entity can delegate capabilities to others.

ii) Composable: a packet may be accompanied by a set of capabilities.

iii) cryptographically authenticated.

Capabilities can be issued by ASes to any parties they know how to bill. Each capability

specifies a desired transit point (called a waypoint),a resource principal responsible for

the traffic, and a stamp of authorization. By presenting a capability along with a routing

request, end users and ISPs express their willingness to be held accountable for the

traffic, and the included authorization ensures the policy compliance of the request. In

addition to its basic design, we also aim to understand how Platypus might be deployed

in todays Internet. We detail the design and implementation of a policy framework for


17/50

17

managing Platypus in an AS and that can be used to address several issues in wide-

area routing at both the edge and the core and evaluate its performance and security.

3.2.1.5 Encryption

Security in Platypus is provided by the fact that not all parties have the information

needed to bind known capabilities to new packets or create new, usable capabilities. To

generate a temporal secret key, a party must have the waypoint key, which is known

only to the router and the routers key server. Binding a capability to a packet requires

only the temporal secret key, which is generated based upon and the current time.

Knowledge of one capabilitys temporal secret key, however, does not allow a party to

generate temporal secrets for others.

Resource principals wishing to transfer their full rights for a particular waypoint to a

trusted third party can pass both the capability and corresponding temporal secret key.

While the capability can be passed in the clear, the temporal secret key must be

communicated privately, ensuring that only the chosen third parties are able to receive

it. These third parties can then use to generate bindings to stamp their own packets

which others, including those sniffing packets on the network, can see.

3.3 SOFTWARE REQUIREMENT SPECIFICATION

3.3.1 Purpose

The main purpose for preparing this document is to give a general insight into the

analysis and requirements of the existing system or situation and for determining the

operating characteristics of the system.


18/50

18

3.3.2 Scope

This Document plays a vital role in the development life cycle (SDLC)

As it describes the complete requirement of the system, it is meant for use by the

developers and will be the basic during testing phase. Any changes made to the

requirements in the future will have to go through formal change approval process.

3.3.2.1 Overview of developers responsibility

The developer is responsible for:

1) Developing the system, which meets the SRS and solving all the requirements of the

system?

2) Demonstrating the system and installing the system at client's location after the

acceptance testing is successful.

3) Submitting the required user manual describing the system interfaces to work on it

and also the documents of the system.

4) Conducting any user training that might be needed for using the system.

5) Maintaining the system for a period of one year after installation.

3.4 FUNCTIONAL REQUIREMENTS

3.4.1 Outp ut desig n

Outputs from computer systems are required primarily to communicate the results of

processing to users. They are also used to provides a permanent copy of the results forlater consultation. The various types of outputs in general are:

External Outputs, whose destination is outside the organization.

Internal Outputs whose destination is within organization and they are the

users main interface with the computer.


19/50

19

Operational outputs whose use is purely within the computer department.

Interface outputs, which involve the user in communicating directly with other

computer departments.

3.4.1.1 Output definition

The outputs should be defined in terms of the following points:

Type of the output

Content of the output

Format of the output

Location of the output

Frequency of the output

Volume of the output

Sequence of the output

It is not always desirable to print or display data as it is held on a computer. It should be

decided as which form of the output is the most suitable.

For Example

Will decimal points need to be inserted?

Should leading zeros be suppressed?

3.4.1.2 Output media

In the next stage it is to be decided that which medium is the most appropriate for the

output. The main considerations when deciding about the output media are:

The suitability for the device to the particular application.

The need for a hard copy.

The response time required.

The location of the users

The software and hardware available.


20/50

20

Keeping in view the above description the project is to have outputs mainly coming

under the category of internal outputs. The main outputs desired according to the

requirement specification are:

The outputs were needed to be generated as a hot copy and as well as queries to be

viewed on the screen. Keeping in view these outputs, the format for the output is taken

from the outputs, which are currently being obtained after manual processing. The

standard printer is to be used as output media for hard copies.

3.4.2 Input desig n

Input design is a part of overall system design. The main objective during the input

design is as given below:

To produce a cost-effective method of input.

To archive the highest possible level of accuracy.

To ensure that the input is acceptable and understood by the user.

3.4.2.1 Input stages

The main input stages can be listed as below:

Data recording

Data transcription

Data conversion

Data verification

Data control

Data transmission

Data validation

Data correction


21/50

21

3.4.2.2 Input types

It is necessary to determine the various types of inputs. Inputs can be categorized

as follows:

External inputs, which are prime inputs for the system.

Internal inputs, which are user communications with the system.

Operational, which are computer departments communications to the

system?

Interactive, which are inputs entered during a dialogue.

3.4.2.3 Input media

At this stage choice has to be made about the input media. To conclude about the

input media consideration has to be given to;

Type of input

Flexibility of format

Speed

Accuracy

Verification methods Rejection rates

Ease of correction

Storage and handling requirements

Security

Easy to use

Portabilility

Keeping in view the above description of the input types and input media, it can be

said that most of the inputs are of the form of internal and interactive. As input data is to

be the directly keyed in by the user, the keyboard can be considered to be the most

suitable input device.


22/50

22

3.4.2.4 Error avoidance

At this stage care is to be taken to ensure that input data remains accurate form

the stage at which it is recorded up to the stage in which the data is accepted by the

system. This can be achieved only by means of careful control each time the data is

handled.

3.4.2.5 Error detection

Even though every effort is make to avoid the occurrence of errors, still a small

proportion of errors is always likely to occur, these types of errors can be discovered by

using validations to check the input data.

3.4.2.6 Data validation

Procedures are designed to detect errors in data at a lower level of detail. Data

validations have been included in the system in almost every area where there is a

possibility for the user to commit errors. The system will not accept invalid data.

Whenever an invalid data is keyed in, the system immediately prompts the user and the

user has to again key in the data and the system will accept the data only if the data is

correct. Validations have been included where necessary.

The system is designed to be a user friendly one. In other words the system has

been designed to communicate effectively with the user. The system has been

designed with popup menus.

3.4.3 User interface design

It is essential to consult the system users and discuss their needs while

designing the user interface. User interfaces can be classified as:


23/50

23

1. User initiated interface: The user is in charge, controlling the progress of the

user/computer dialogue.

2. Computer-initiated interface: The computer selects the next stage in the

interaction. In the computer-initiated interfaces the computer guides the

progress of the user/computer dialogue. Information is displayed and the

user response of the computer takes action or displays further information.

3.4.3.1 User initialized interfaces

User initiated interfaces fall into tow approximate classes:

1. Command driven interfaces: In this type of interface the user inputs

commands or queries, which are interpreted by the computer.

2. Forms oriented interface: The user calls up an image of the form to

his/her screen and fills in the form. The forms oriented interface is

chosen because it is the best choice.

3.4.3.2 Computer initialized interfaces

The following computer initiated interfaces were used:

1. The menu system for the user is presented with a list of alternatives

and the user chooses one; of alternatives.

2. Questions answer type dialog system where the computer asks

question and takes action based on the basis of the users reply.

Right from the start the system is going to be menu driven, the opening menu displays

the available options. Choosing one option gives another popup menu with more

options. In this way every option leads the users to data entry form where the user can

key in the data.


24/50

24

3.4.3.3 Error message design:

The design of error messages is an important part of the user interface design.

As user is bound to commit some errors or other while designing a system the system

should be designed to be helpful by providing the user with information regarding the

error he/she has committed.

This application must be able to produce output at different modules for different

inputs.

3.5 PERFORMANCE REQUIREMENTS

Performance is measured in terms of the output provided by the application.

Requirement specification plays an important part in the analysis of a system. Only

when the requirement specifications are properly given, it is possible to design a

system, which will fit into required environment. It rests largely in the part of the users

of the existing system to give the requirement specifications because they are the

people who finally use the system. This is because the requirements have to be known

during the initial stages so that the system can be designed according to those

requirements. It is very difficult to change the system once it has been designed and onthe other hand designing a system, which does not cater to the requirements of the

user, is of no use.

The requirement specification for any system can be broadly stated as given

below:

The system should be able to interface with the existing system

The system should be accurate

The system should be better than the existing system

The existing system is completely dependent on the user to perform all the duties.


25/50

25

CHAPTER 4

PROJECT DESIGN


26/50

26

4. PROJECT DESIGN

4.1 DATA FLOW DIAGRAM

A data flow diagram is graphical tool used to describe and analyze movement of

data through a system. These are the central tool and the basis from which the other

components are developed. The transformation of data from input to output, through

processed, may be described logically and independently of physical components

associated with the system. These are known as the logical data flow diagrams. The

physical data flow diagrams show the actual implements and movement of data

between people, departments and workstations. A full description of a system actually

consists of a set of data flow diagrams. Using two familiar notations Yourdon, Gane

and Sarson notation develops the data flow diagrams. Each component in a DFD is

labeled with a descriptive name. Process is further identified with a number that will be

used for identification purpose. The development of DFDs is done in several levels.

Each process in lower level diagrams can be broken down into a more detailed DFD in

the next level. The lop-level diagram is often called context diagram. It consists a single

process bit, which plays vital role in studying the current system. The process in the

context level diagram is exploded into other process at the first level DFD.

The idea behind the explosion of a process into more process is that

understanding at one level of detail is exploded into greater detail at the next level. This

is done until further explosion is necessary and an adequate amount of detail is

described for analyst to understand the process.

Larry Constantine first developed the DFD as a way of expressing system

requirements in a graphical from, this lead to the modular design.

A DFD is also known as a bubble Chart has the purpose of clarifying system

requirements and identifying major transformations that will become programs in system

design. So it is the starting point of the design to the lowest level of detail. A DFD

consists of a series of bubbles joined by data flows in the system.


27/50

27

4.1.1 DFD sym bo ls

In the DFD, there are four symbols

1. A square defines a source(originator) or destination of system data2. An arrow identifies data flow. It is the pipeline through which the information flows

3. A circle or a bubble represents a process that transforms incoming data flow into

outgoing data flows.

4. An open rectangle is a data store, data at rest or a temporary repository of data

Process that transforms data flow.

Source or Destination of data

Data flow

Data Store


28/50

28

4.1.2 Cons truc ting A DFD

Several rules of thumb are used in drawing DFDs:

1. Process should be named and numbered for an easy reference. Each name shouldbe representative of the process.

2. The direction of flow is from top to bottom and from left to right. Data Traditionally

flow from source to the destination although they may flow back to the source. One way

to indicate this is to draw long flow line back to a source. An alternative way is to repeat

the source symbol as a destination. Since it is used more than once in the DFD it is

marked with a short diagonal.

3. When a process is exploded into lower level details, they are numbered.

4. The names of data stores and destinations are written in capital letters. Process and

dataflow names have the first letter of each work capitalized

A DFD typically shows the minimum contents of data store. Each data store should

contain all the data elements that flow in and out.

Questionnaires should contain all the data elements that flow in and out. Missing

interfaces redundancies and like is then accounted for often through interviews.

4.1.3 Sailent featur es ofDFDs

The DFD shows flow of data, not of control loops and decision are controlled

considerations do not appear on a DFD.

The DFD does not indicate the time factor involved in any process whether the

dataflows take place daily, weekly, monthly or yearly.

The sequence of events is not brought out on the DFD.


29/50

29

4.1.4 Types of data flow diagram s

1. Current Physical

2. Current Logical

3. New Logical

4. New Physical

4.1.4.1 Current physical

In Current Physical DFD process label include the name of people or their

positions or the names of computer systems that might provide some of the overall

system-processing label includes an identification of the technology used to process the

data. Similarly data flows and data stores are often labels with the names of the actual

physical media on which data are stored such as file folders, computer files, business

forms or computer tapes.

4.1.4.2 Current logical

The physical aspects at the system are removed as mush as possible so that the

current system is reduced to its essence to the data and the processors that transform

them regardless of actual physical form.

4.1.4.3 New logical

This is exactly like a current logical model if the user were completely happy with

the functionality of the current system but had problems with how it was implemented

typically, through the new logical model will differ from current logical model while

having additional functions, absolute function removal and inefficient flows recognized.

4.1.4.4 New physical

The new physical represents only the physical implementation of the new system.


30/50

30

4.1.5 Rules go vernin g theDFDS

4.1.5.1 Process

No process can have only outputs.

No process can have only inputs. If an object has only inputs than it must be a

sink.

A process has a verb phrase label.

4.1.5.2 Data store

Data cannot move directly from one data store to another data store, a process

must move data.

Data cannot move directly from an outside source to a data store, a process,

which receives, must move data from the source and place the data into data

store.

A data store has a noun phrase label.

4.1.5.3 Source or sink

The origin and /or destination of data.

Data cannot move directly from a source to sink, it must be moved by a process.

A source and /or sink has a noun phrase.

4.1.5.4 Data flow

A Data Flow has only one direction of flow between symbol. It may flow in both

directions between a process and a data store to show a read before an update.

The later is usually indicated however by two separate arrows since these

happen at different type.


31/50

31

A join in DFD means that exactly the same data comes from any of two or more

different processes data store or sink to a common location.

A data flow cannot go directly back to the same process it leads. There must be

atleast one other process that handles the data flow, produces some other data

flow and returns the original data into the beginning process.

A Data flow to a data store means update (delete or change).

A data flow from a data store means retrieve or use.

A data flow has a noun phrase label more than one data flow noun phrase can

appear on a single arrow as long as all of the flows on the same arrow move

together as one package.

4.1.6 Dataflow diagram / Use case diagram / Flow diagram

The DFD is also called as bubble chart. It is a simple graphical formalism

that can be used to represent a system in terms of the input data to the system, various

processing carried out on these data, and the output data is generated by the system.


32/50

32

Fig 4 Dataf low diagram for p latypus


33/50

33

Fig 5 Class Diagram for Pol icy Complaint


34/50

34

Fig 6 Class d iagram for Source


35/50

35

Fig 7 Class diagram fo r Destination


36/50

36

Fig 8 Use c ase Diagram


37/50

37

Fig 9 Sequenc e Diagram


38/50

38

CHAPTER 5

RESULTS AND ANALYSIS


39/50

39

5. RESULTS AND ANALYSIS

5.1OUTPUT SCREEN SHOTS

Fig 10 Source

Fig 11 Routers


40/50

40

Fig 12 Destination

Fig 13 Select a fi le to s end


41/50

41

Fig 14 Select the IP add ress o f destin ation

Fig 15 Select a path to rec eive the fi le


42/50

42

Fig 16 File is trans ferred by ISP

Fig 17 Destination s tarts receiving the fi le


43/50

43

Fig 18 When ISP is busy , fi le is transferred throu gh RC1 and RC2


44/50

44

Fig 19After file is received by the destination file saved message is displayed

Fig 20 If con nect ion is n ot establ ished an error message is disp layed


45/50

45

5.2 PERFORMANCE ANALYSIS

5.2.1 Replay attack s

For rate-based accounting, we can constrain resource principals to a fixed, aggregatebandwidth. However, while packet bindings cannot be forged (modulo standard

cryptographic hardness assumptions), they may be replayed by an adversary, who may

wish to waste a resource principals limited bandwidth for a given capability. Since

capabilities expire periodically, a natural countermeasure to replay attacks is to track

packets that traverse a router within some time window and only count each distinct

packet once.

5.2.2 Scalabil ity

Previous works explored the use of access control lists for network resources. In

contrast, a Platypus router does not need to keep track of permissions for end hosts,

potentially providing for greater scalability. In particular, by using capabilities, Platypus

is able to implement capability delegation without involving Platypus routers or key

servers. The downside, of course, of capabilities is communication overhead

5.2.3 Traff ic engin eering

Conventional wisdom holds that widespread source routing deployment would

complicate traffic-engineering efforts. While there admittedly is cause for concern, we

have reasons for optimism. Recent simulations by Qiu et al. show that while source

routed traffic can have deleterious interactions with intra-AS traffic engineeringmechanisms in extreme cases, certain techniques may be able to mitigate these effects.

In their studies, however, source-routed traffic was capable of completely specifying

intra-AS paths. Our design for Platypus is meant to allow ISPs to specify any globally

routable IP address within their IP space as a Platypus waypoint and dynamically adjust

the actual (set of) internal router(s) to which the IP corresponds in response to traffic


46/50

46

load. By dilating waypoints in this way, an ISP can meet its traffic engineering goals

while delivering improved service to end hosts; In addition, an ISP has the option of

pricing capabilities in a way that attracts traffic to lightly loaded links or that

compensates for the use of links that have little spare capacity.

Independent of its interaction with traditional traffic engineering, Platypus opens up a

new dimension for traffic provisioning: time. Routing in todays Internet has no temporal

dimension the advertisement of a route makes it immediately available. With

Platypus, however, routes may have time-limited availability; that is, a route is available

only when users possess the correct temporal secrets. By appropriately choosing

expiration intervals and expressing route selection policy upon key lookup, ISPs can

control the temporal aspects of traffic flow; in this way, Platypus may even serve to help

achieve traffic engineering goals.


47/50

47

CHAPTER 7

CONCLUSIONS


48/50

48

6. CONCLUSIONS

Capabilities are well known in the operating systems literature, but have failed to catch

on in many mainstream systems, likely because they are perceived as too heavyweight

a mechanism to address the relatively simple access problems of single-user systems.

In contrast, we believe capabilities are extremely well-suited for use in wide-area

Internet routing. Unlike todays PCs, which typically are used by at most a small number

of users with similar goals and policy constraints, the Internet serves an extremely large

number of users with an even larger number of motivations, all attempting to

simultaneously share widely distributed resources. Most importantly, there exists no

single arbiter (for example, a system administrator or user logged in at the console) who

can make informed access decisions.

Looking forward, while much work has gone into

understanding existing Internet routing policy and describing how to specify it better, we

believe that much of the complexity of Internet routing policy stems from inflexibility of

existing routing protocols. We aim to study how one might implement inter-AS traffic

engineering policies through capability pricing strategies. For example, an AS with

multiple peering routers that wishes to encourage load balancing may be able to do so

through variable pricing of capabilities for the corresponding Platypus waypoints. Whileproperly modeling the self-interested behavior of external entities may be difficult, we

are hopeful that this challenge is simplified by the direct mapping between Platypus

waypoints and path selection (as compared, for example, to the intricate interactions of

various BGP parameters).


49/50

49

CHAPTER 8

BIBILOGRAPHY


50/50

7. BIBLIOGRAPHY

Good Teachers are worth more than thousand books, we have them in Our Department

References Made From:

1. User Interfaces in C#: Windows Forms and Custom Controls by Matthew

MacDonald.

2. Applied Microsoft .NET Framework Programming (Pro-Developer) by Jeffrey

Richter.

3. Practical .Net2 and C#2: Harness the Platform, the Language, and the Framework

by Patrick Smacchia.

4. Data Communications and Networking, by Behrouz A Forouzan.

5. Computer Networking: A Top-Down Approach, by James F. Kurose.

6. Operating System Concepts, by Abraham Silberschatz.

Sites Referred:

http://www.sourcefordgde.com

http://www.networkcomputing.com/
http://www.sourcefordgde.com/http://www.sourcefordgde.com/http://www.networkcomputing.com/http://www.networkcomputing.com/http://www.networkcomputing.com/http://www.sourcefordgde.com/

Documents

secure and policy compliant source routing1