secure and policy compliant source routing1
TRANSCRIPT
-
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.
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
3/50
3
CHAPTER 2
BACKGROUND STUDY
-
7/28/2019 secure and policy compliant source routing1
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
-
7/28/2019 secure and policy compliant source routing1
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
-
7/28/2019 secure and policy compliant source routing1
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/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
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
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
10/50
10
CHAPTER 3
PLATYPUS SYSTEM
-
7/28/2019 secure and policy compliant source routing1
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:
-
7/28/2019 secure and policy compliant source routing1
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
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
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
-
7/28/2019 secure and policy compliant source routing1
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
-
7/28/2019 secure and policy compliant source routing1
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
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
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
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
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 pop- up 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:
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
25/50
25
CHAPTER 4
PROJECT DESIGN
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
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
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
32/50
32
Fig 4 Dataf low diagram for p latypus
-
7/28/2019 secure and policy compliant source routing1
33/50
33
Fig 5 Class Diagram for Pol icy Complaint
-
7/28/2019 secure and policy compliant source routing1
34/50
34
Fig 6 Class d iagram for Source
-
7/28/2019 secure and policy compliant source routing1
35/50
35
Fig 7 Class diagram fo r Destination
-
7/28/2019 secure and policy compliant source routing1
36/50
36
Fig 8 Use c ase Diagram
-
7/28/2019 secure and policy compliant source routing1
37/50
37
Fig 9 Sequenc e Diagram
-
7/28/2019 secure and policy compliant source routing1
38/50
38
CHAPTER 5
RESULTS AND ANALYSIS
-
7/28/2019 secure and policy compliant source routing1
39/50
39
5. RESULTS AND ANALYSIS
5.1OUTPUT SCREEN SHOTS
Fig 10 Source
Fig 11 Routers
-
7/28/2019 secure and policy compliant source routing1
40/50
40
Fig 12 Destination
Fig 13 Select a fi le to s end
-
7/28/2019 secure and policy compliant source routing1
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
-
7/28/2019 secure and policy compliant source routing1
42/50
42
Fig 16 File is trans ferred by ISP
Fig 17 Destination s tarts receiving the fi le
-
7/28/2019 secure and policy compliant source routing1
43/50
43
Fig 18 When ISP is busy , fi le is transferred throu gh RC1 and RC2
-
7/28/2019 secure and policy compliant source routing1
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
-
7/28/2019 secure and policy compliant source routing1
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
-
7/28/2019 secure and policy compliant source routing1
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.
-
7/28/2019 secure and policy compliant source routing1
47/50
47
CHAPTER 7
CONCLUSIONS
-
7/28/2019 secure and policy compliant source routing1
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).
-
7/28/2019 secure and policy compliant source routing1
49/50
49
CHAPTER 8
BIBILOGRAPHY
-
7/28/2019 secure and policy compliant source routing1
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/