[attachment=1004]
Secure and Policy-Compliant Source Routing

Abstract

In todayâ„¢s Internet, inter-domain route control remains elusive; nevertheless, such control could improve the performance, reliability, and utility of the network for end users and ISPs alike. While researchers have proposed a number of source routing techniques to combat this limitation, there has thus far been no way for independent ASes to ensure that such traffic does not circumvent local traffic policies, nor to accurately determine the correct party to charge for forwarding the traffic.


Algorithm /Method Used:
Platypus Policy Framework.
Algorithm /Method DESCRIPTION:

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
i) Transferable: an entity can delegate capabilities to others,
ii) Composable: a packet may be accompanied by a set of capabilities,
and 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.


Existing System

An increasing number of ASes have been connecting to the
Internet through the BGP inter-domain routing protocol. With increasing stress on the scale of this system and increasing reliance on Internet connectivity, more participants demand additional functionality from inter-domain routing that BGP cannot handle. For example, we believe that the recent trend towards multi-homed stub networks exhibits a likely intent to achieve fault tolerant and load balanced connectivity to the Internet. However, BGP today offers route fail-over times as long as 15 minutes, and very
limited control over incoming traffic across multiple wide area paths. More research literature and news media are calling for stemming malicious or erroneous routing announcements. We propose policy control architecture, OPCA that runs as an overlay network on top of BGP. OPCA allows an AS to make route change requests at other, remote ASes to achieve faster route fail-over and provide capabilities to control traffic entering the local AS.

Proposed System
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.


Modules:
1. Networking Module.
2. ISP Module.
3. Load Balancing Module.
4. Platypus Framework Module.
5. Encryption Module.
Module Description:

1. Networking Module.
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.

2. ISP Module.
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. BGPâ„¢s 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. Load Balancing Module.


4. Platypus Framework Module.
5. Encryption Module

Conclusions
We argue that capabilities are uniquely well-suited for use in wide-area Internet routing. 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. Moreover, 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. While properly 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).

Hardware Requirements

¢ System : Pentium IV 2.4 GHz.
¢ Hard Disk : 40 GB.
¢ Floppy Drive : 1.44 Mb.
¢ Monitor : 15 VGA Colour.
¢ Mouse : Logitech.
¢ Ram : 256 Mb.




Software Requirements

¢ Operating system :- Windows XP Professional
¢ Front End :-Visual Studio Dot Net 2005.
¢ Coding Language :- C#

use this page link for full report
http://portal.acmcitation.cfm?id=1569739

i want source code of this project
Title :: compliant source routing secure and policy

[attachment=13420]
Introduction
General:
Algorithm /Method Used:
Platypus Policy Framework.
Algorithm /Method Description:
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 i) Transferable: an entity can delegate capabilities to others, ii) Composable: a packet may be accompanied by a set of capabilities, and 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.
NETWORK operators and academic researchers alike recognize that today’s 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 to improve end-to-end performance, reliability, and flexibility, they have proven problematic to deploy due to concerns about security and network instability. We attempt to address these issues in developing a scalable, authenticated, policy-compliant, wide-area source routing protocol.
We argue that many of the deficiencies of today’s routing infrastructure are symptoms of the coupling of routing policy and routing mechanism . In particular, today’s primary widearea routing protocol, the Border Gateway Protocol (BGP), is extraordinarily difficult to describe, analyze, or manage . 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. BGP’s 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.
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 being policy compliant, reducing policy enforcement to stamp verification. Hence, Platypus allows for management of routing policy independent of route export and path selection.
Objective:
In today’s Internet, inter-domain route control remains elusive; nevertheless, such control could improve the performance, reliability, and utility of the network for end users and ISPs alike.
Existing System:
An increasing number of ASes have been connecting to the Internet through the BGP inter-domain routing protocol. With increasing stress on the scale of this system and increasing reliance on Internet connectivity, more participants demand additional functionality from inter-domain routing that BGP cannot handle. For example, we believe that the recent trend towards multi-homed stub networks exhibits a likely intent to achieve fault tolerant and load balanced connectivity to the Internet. However, BGP today offers route fail-over times as long as 15 minutes, and very limited control over incoming traffic across multiple wide area paths. More research literature and news media are calling for stemming malicious or erroneous routing announcements. We propose policy control architecture, OPCA that runs as an overlay network on top of BGP. OPCA allows an AS to make route change requests at other, remote ASes to achieve faster route fail-over and provide capabilities to control traffic entering the local AS.
Proposed System:
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.
System Analysis
Overview:
The first step in developing anything is to state the requirements. This applies just as much to leading edge research as to simple programs and to personal programs, as well as to large team efforts. Being vague about your objective only postpones decisions to a later stage where changes are much more costly.
The problem statement should state what is to be done and not how it is to be done. It should be a statement of needs, not a proposal for a solution. A user manual for the desired system is a good problem statement. The requestor should indicate which features are mandatory and which are optional, to avoid overly constraining design decisions. The requestor should avoid describing system internals, as this restricts implementation flexibility. Performance specifications and protocols for interaction with external systems are legitimate requirements. Software engineering standards, such as modular construction, design for testability, and provision for future extensions, are also proper.
Many problems statements, from individuals, companies, and government agencies, mixture requirements with design decisions. There may sometimes be a compelling reason to require a particular computer or language; there is rarely justification to specify the use of a particular algorithm. The analyst must separate the true requirements from design and implementation decisions disguised as requirements. The analyst should challenge such pseudo requirements, as they restrict flexibility. There may be politics or organizational reasons for the pseudo requirements, but at least the analyst should recognize that these externally imposed design decisions are not essential features of the problem domain.
A problem statement may have more or less detail. A requirement for a conventional product, such as a payroll program or a billing system, may have considerable detail. A requirement for a research effort in a new area may lack many details, but presumably the research has some objective, which should be clearly stated.
Most problem statements are ambiguous, incomplete, or even inconsistent. Some requirements are just plain wrong. Some requirements, although precisely stated, have unpleasant consequences on the system behavior or impose unreasonable implementation costs. Some requirements seem reasonable at first but do not work out as well as the request or thought. The problem statement is just a starting point for understanding the problem, not an immutable document. The purpose of the subsequent analysis is to fully understand the problem and its implications. There is no reasons to expect that a problem statement prepared without a fully analysis will be correct.
The analyst must work with the requestor to refine the requirements so they represent the requestor’s true intent. This involves challenging the requirements and probing for missing information. The psychological, organizational, and political considerations of doing this are beyond the scope of this book, except for the following piece of advice: If you do exactly what the customer asked for, but the result does not meet the customer’s real needs, you will probably be blamed anyway

send code , and model discription[/font]

to get information about the topic" Secure and Policy-Compliant Source Routing" refer the page link bellow
http://studentbank.in/report-secure-and-...7#pid60427

i need the code of this project......

---

The code you have included does not contain the entire code...could u pls post the entire code....!!!!!!!!!!1

to get information about the topic Secure and Policy-Compliant Source Routing full report ,ppt and related topic refer the page link bellow

http://studentbank.in/report-secure-and-...ce-routing

http://studentbank.in/report-secure-and-...networking

---

The code included doesn't have the modules you have shown in the class diagram....the code is not working without that....so plz send the entire code....

hello.....PLs send the code of x905certificate and action packages that you have included in your code.......