Controlling Ip Spoofing Through Interdomain Packet Filter Computer Science Essay

The Distributed Denial-of-Service attack is a serious threat to the valid use of the Internet. Prevention mechanisms are disillusioned by the ability of attackers to spoof the source addresses in IP packets. With the help of the technique called IP spoofing, attackers can avoid detection and cause a burden on the destination network for policing attack packets. In this project, I propose an inter-domain packet filter (IDPF) architecture that can alleviate the level of IP spoofing on the Internet. A key feature of the scheme is that it does not require global routing information. IDPFs are constructed from the information hidden in Border Gateway Protocol (BGP) route updates and are deployed in network border routers. I establish the conditions under which the IDPF framework works correctly; it does not discard packets with valid source addresses. Even with partial employment on the Internet, IDPFs can proactively limit the spoofing capability of attackers. In addition, they can help localize the origin of an attack packet to a small number of participant networks.

IP spoofing can avoid detection and put a burden on the destination network for policing attack packets from the attackers. In this Project, an inter domain packet filter (IDPF) architecture that can alleviate the level of IP spoofing on the Internet is used. A key feature of this scheme is that it does not require global routing information. IDPFs are constructed from the information hidden in Border Gateway Protocol (BGP) route updates and are deployed in network border routers. The condition under which the IDPF framework works correctly is established. It does not discard packets with valid source addresses. Even with partial employment on the Internet, IDPFs can proactively limit the spoofing capability of attackers.

1.2) Project Description:

Packets sent using the IP protocol include the IP address of the sending host. The recipient sends the replies to the sender using this source address. However, the correctness of this address is not verified by the protocol. The IP protocols do not specify any method for validating the authenticity of the packet’s source. This implies that an attacker can create the source address to be any desired. This is exclusively done for malicious or inappropriate purposes. The attackers can take advantage of this weakness for many attacks; it would be useful to know if network traffic has spoofed source addresses in it or not.

The problem of sending spoofed packets is done for illegal purposes. Sending IP packets with fake source addresses is known as packet spoofing and is used by attackers for several purposes. The purposes include obscuring the true source of the attack, implicating another site as the attack origin, pretending to be a trusted host, intercepting network traffic, or sending fake replies to aim at another system.

Because none of the above are wanted, it is therefore useful to determine if a packet has a spoofed source address. In situations where an ongoing attack is occurring it is advantageous to determine if the attack is from a particular location. Most of the situations the determination of when packets are spoofed and their origination is possible using this scheme. Spoofing of network traffic can occur at different layers. Examples include network layer spoofing as well as session and application layer spoofing (e.g. email spoofing). All of these have security concerns. This project mainly concentrates on IP Spoofing. The issue is attacks that cause packets to be routed to a different host than the sender intends. These are attacks on routing and the DNS system. Packet spoofing is restricted to false source addresses in the IP packet header.

IP spoofing is advantageous in many aspects. First, IP spoofing makes isolating attack traffic from lawful traffic harder: packets with spoofed source addresses may appear to be from all around the Internet. Second, it presents the attacker with an easy way to introduce a level of indirection. As a result, ample of effort is required to localize the source of the attack traffic. Finally flood attacks use IP spoofing and require the ability to copy source addresses.

PROBLEM DEFINITION

2.1) EXISITING SYSTEM:

Route-based Packet Filter: Route-based distributed packet filtering (DPF) uses routing information to decide if a packet arriving at a router (e.g., border router at an AS) is valid or not with respect to its inscribed source/destination addresses, given the facility constraints imposed by routing and network topology. A single AS can only apply a limited impact with respect to identifying and discarding forged IP flows.

Route-based packet filtering occurs at two time scales-packet forwarding/discard based on table look-up (fast) and filter table update (slow)-and thus its forwarding/discard function can be performed close to line speed subject to generic processing overhead.

Disadvantages:

IP spoofing may occur easily. Because the packet-filtering router permits or denies a network connection based on the source and destination addresses of the packet, any attack that uses valid IP address may not be detected.

Packet-filtering rules are harder to be designed and configured.

2.2) PROPOSED SYSTEM

Definition1: (stable routing state). A routing system is in a Stable state if all the nodes have selected a best route to reach other nodes and no route updates are generated.

Definition 2: (route-based packet filtering). Node v accepts packet M(s, d) that is forwarded from node u if and only if e (u, v) belongs to R(s, d). Else, the source address of the packet is spoofed, and the packet is discarded by v.

Definition 3: (correctness of packet filtering). A packet filter is correct if it does not discard packets with valid source addresses when the routing system is stable.

Advantages:

IDPFs can significantly limit the spoofing capability of an attacker. It also helps to locate the origin of an attack packet to be within a small number of participant networks, thereby making the reactive IP trace back process much simpler.

FEASIBILITY STUDY

3.1) Technical Feasibility

PROBLEM FORMULATION:

Distributed Denial-of-Service (DDoS) attacks pose an increasingly grave threat to the Internet. DDoS attacks are observed on a daily basis on most of the large networks. One of the factors that complicate the mechanisms for policing such attacks is IP spoofing, which is the act of forging the source addresses in IP packets. By pretending to be a different host, an attacker can hide its true identity and location, interpreting the source based packet filtering less effective.

The basic protocol for sending data over the Internet and many other computer networks is the Internet Protocol (IP). The header of each IP packet contains the source and destination address of the packet. The source address is the address that the packet was sent from. By forging the header, an attacker can depict as the packet was sent by a different machine. The machine that receives spoofed packets will send response back to the forged source address, which means that this technique is mainly used when the attacker does not care about response or the attacker has some way of guessing the response.

In certain cases, it might be possible for the attacker to see or redirect the response to his own machine. The most usual case is when the attacker is spoofing an address on the same LAN or WAN.

IP spoofing is most frequently used in denial-of-service attacks. In such attacks, the goal is to flood the victim with vast amounts of traffic, and the attacker does not care about receiving responses to his attack packets. Packets with spoofed addresses are thus suitable for such attacks. They are more difficult to filter since each spoofed packet appears to come from a different address, and they hide the true source of the attack. Denial of service attacks that use spoofing randomly choose addresses from the entire IP address space, though more complicated spoofing mechanisms might avoid unroutable addresses or unused portions of the IP address space. The production of large botnets makes spoofing less important in denial of service attacks, but attackers have spoofing available as a tool, so defenses against denial-of-service attacks that rely on the validity of the source IP address in attack packets might have trouble with spoofed packets. Backscatter, a technique used to observe denial-of-service attack activity in the Internet, relies on attackers’ use of IP spoofing for its effectiveness.

IP spoofing is a method of attack used by network intruders to defeat network security measures, such as authentication based on IP addresses. This method of attack on a remote system can be extremely difficult, as it involves modifying thousands of packets at a time. This type of attack is most effective where trust relationships exist between machines. For example, it is common on some corporate networks to have internal systems trust each other, so that a user can log in without a username or password provided he is connecting from another machine on the internal network (and so must already be logged in). By spoofing a connection from a trusted machine, an attacker may be able to access the target machine without authenticating.

3.2) Operational Feasibility

TECHNIQUE USED IN THIS PROJECT

BGP (BORDER GATEWAY PROTOCOL):

Each node only selects and propagates to neighbors a single best route to the destination. Both the selection and the propagation of best routes are governed by locally defined routing policies.

Import policies:

Neighbor-specific import policies are applied upon routes learned from neighbors.

Export policies:

Neighbor-specific export policies are imposed on locally selected best routes before they are propagated to the neighbors.

BGP WORKING:

Each node only selects and propagates to neighbors a single best route to the destination, if any. Both the selection and the propagation of best routes are governed by locally defined routing policies. Two distinct sets of routing policies are typically employed by a node: import policies and export policies. Neighbor-specific import policies are applied upon routes learned from neighbors, whereas neighbor-specific export policies are imposed on locally selected best routes before they are propagated to the neighbors. In general, import policies can affect the “desirability” of routes by modifying route attributes. Let r be a route (to destination d) received at v from node u. I denote by import (v <- u) [{r}] the possibly modified route that has been transformed by the import policies. The transformed routes are stored in v’s routing table. The set of all such routes is denoted as candidateR (v, u);

CandidateR (v, d) = {r: import (v <- u) [{r}]! = {} r.prefix d Ò±u E (v)}

Here, N (v) is the set of v’s neighbors.

Among the set of candidate routes candidateR (v, d); node v selects a single best route to reach the destination based on a well-defined procedure. To aid in description, I denote the outcome of the selection procedure at node v, that is, the best route, as bestR (v, d) which reads the best route to destination d at node v. Having selected bestR (v, d) from candidateR (v, d) v then exports the route to its neighbors after applying neighbor-specific export policies. The export policies determine if a route should be forwarded to the neighbor and if so, they modify the route attributes according to the policies. I denote by export (v <- u) [{r}] the route sent to neighbor u by node v after node v applies the export policies on route r.

BGP is an incremental protocol: updates are generated only in response to network events. In the absence of any event, no route updates are triggered or exchanged between neighbors, and the routing system is in a stable state.

3.3) IDPF (INTER DOMAIN PACKET FILTER):

IDPFs can independently be deployed in each S. IDPFs are deployed at the border routers so that IP packets can be inspected before they enter the network. IDPFs are used locally exchange BGP Updates to compare the paths.

If the Source address is not valid it will discard the packets.

IDPF WORKING:

IDPFs are completely oblivious to the specifics of the announced routes. Following a network failure, the set of feasible upstream neighbors will not admit more members during the period of routing convergence, assuming that AS relationships are static, which is true in most cases. Hence, for the first type of routing dynamics (network failure), there is no possibility that the filters will block a valid packet. It is illustrated as follows: Consider an IDPF-enabled AS v that is on the best route from s to d. Let u = bestU(s; d; v) and U = feasibleU(s; d; v).A link or router failure between u and s can have three outcomes: 1) ASu can still reach ASs, and u is still chosen to be the best upstream neighbor for packet M(s; d), that is, u =bestU(s; d; v). In this situation, although u may explore and announce multiple routes to v during the path exploration process [30], the filtering function of v is unaffected. 2) ASuis no longer the best upstream neighbor for packet M(s; d), and another feasible upstream neighbor U can reach AS s and is instead chosen to be the new best upstream neighbor (for M(s; d). Now, both u and u0 may explore multiple routes; however, since u0 has already announced a route (about s) to v, the IDPF at v can correctly filter (that is, accept) packetM(s; d), which is forwarded from u0. 3) No feasible upstream neighbors can reach s. Consequently, AS v will also not be able to reach s, and v will no longer be on the best route between s and d. No new packet M(s; d) should be sent through v.

M(s; d) should be sent through v. The other concern of routing dynamics relates to how a newly connected network (or a network recovered from a fail-down event) will be affected. In general, a network may start sending data immediately following the announcement of a (new) prefix, even before the route has had time to propagate to the rest of the Internet. During the time that the route should be propagated, packets from this prefix may be discarded by some IDPFs if the reachability information has not propagated to them. However, the mitigating factor here is that in contrast to the long convergence delay that follows failure, reachability for the new prefix will be distributed far more speedily. In general, the time taken for such new prefix information to reach an IDPF is proportional to the shortest ASpath between the IDPF and the originator of the prefix and independent of the number of alternate paths between the two. Previous work has established this bound with L being the diameter of the AS graph. It is believed that in this short timescale, it is acceptable for IDPFs to potentially incorrectly behave (discarding valid packets). It must be noted that during BGP route convergence periods, without IDPF, BGP can also drop packets. One alternative solution is to allow a neighbor to continue forwarding packets from a source within a grace period, after the corresponding network prefix has been withdrawn by the neighbor. In this case, during this short period, IDPFs may fail to discard spoofed attack packets. However, given that most DDoS attacks require a persistent train of packets to be directed at a victim, not discarding spoofed packets for this short period of time should be acceptable. I plan to further investigate the related issues in the future.

In short, IDPFs can handle the routing dynamics caused by network failures, which may cause long route convergence times. IDPFs may, however, drop packets in the network recovery events. This is not a big problem, since 1) the network recovery events typically have a short convergence time and 2) such events can also cause service disruptions in the original BGP without IDPF.

System Analysis

4.1) Software Requirement Specification (SRS):

Modules:

In this project, there are four modules

Topology Construction.

BGP Construction.

IDPF Construction.

Control the Spoofed Packets.

Topology Construction:

In this module, a topological structure is constructed. A mesh topology is used because of its unstructured nature. Topology is constructed by getting the names of the nodes and the connections among the nodes as input from the user. While getting each of the nodes, their associated port and ip address is also obtained. For successive nodes, the node to which it should be connected is also accepted from the user. While adding nodes, comparison will be done so that there would be no node duplication. Then the source and the destinations are identified.

Provisions:

1) Construction

construction_id

source

destination

Node

1. node_id

2. node_name

3. port_number

4. ip_address

Functionalities:

Association of node with construction

Queries:

How many nodes are connected?

Which topology is being used?

Alerts:

Connected Successfully.

message sent successfully.

Message discarded.

All fields are mandatory.

2. BGP Construction:

Each node selects and propagates to neighbors a single best route to the destination. Both the selection and the propagation of best routes are governed by locally defined routing policies. Two distinct sets of routing policies are employed by a node: import policies and export policies. Neighbor-specific import policies are applied upon routes learned from neighbors, whereas neighbor-specific export policies are imposed on locally selected best routes before they are propagated to the neighbors. In general, import policies can affect the “desirability” of routes by modifying route attributes.

Provisions:

BGP

best_path_id

best_path_name

Functionalities:

Association of BGP with Node.

Queries:

Which path is chosen?

How many nodes are connected?

Which destination is selected?

Alerts:

Connected Successfully.

message sent successfully.

Message discarded.

All fields are mandatory.

3. IDPF Construction:

IDPFs can independently be deployed in each AS. IDPFs are deployed at the border routers so that IP packets can be inspected before they enter the network. By deploying IDPFs, an AS constrains the set of packets that a neighbor can forward to the AS: a neighbor can only successfully forward a packet M (s, d) to the AS after it announces the reach ability information of s. All other packets are identified to carry spoofed source addresses and are discarded at the border-router of the AS.

Provisions:

Functionalities:

IDPFs are deployed at the border routers for checking IP packets.

Queries:

How many packets are sent?

How many packets are discarded?

Which topology is used?

Alerts:

Message sent successfully.

Message discarded.

All fields are mandatory.

4. Control the Spoofed Packets:

Based on the IDPF and BGP, the packet will be identified as spoofed or correct. If it is correct the messages are allowed to the destination. If spoofed, the packets will be discarded. IDPF framework works correctly and does not discard packets with valid source addresses.

Provisions:

Functionalities:

Association of nodes with port and ip address.

Association of Source with Destination.

Association of message with Source & Destination.

One node associated with another node.

Queries:

How many nodes are connected?

Which topology is used?

How many messages are sent?

How many messages are discarded?

Alerts:

Connected Successfully.

Message sent successfully.

Message discarded.

All fields are mandatory.

4.2) Hardware requirements:

Processor : Any Processor above 500 MHz.

Ram : 128Mb.

Hard Disk : 10 Gb.

Compact Disk : 650 Mb.

Input device : Standard Keyboard and Mouse.

Output device : VGA and High Resolution Monitor.

4.3) Software requirements:

Operating System : Windows 2000 server Family.

Techniques : JDK 1.5

Data Bases : Microsoft Sql Server

Front End : Java Swing

System Design

Design involves identification of classes, their relationships as well as their collaboration. Classes are divided into entity classes, interface classes and control classes. In the Fusion method, some object-oriented approaches like Object Modeling Technique (OMT), Classes, Responsibilities, Collaborators (CRC), etc, are used. Objectory used the term “agents” to represent some of the hardware and software systems .In Fusion method, there is no requirement phase, where a user will supply the initial requirement document. Any software project is worked out by both the analyst and the designer. The analyst creates the use case diagram. The designer creates the class diagram. But the designer can do this only after the analyst creates the use case diagram. Once the design is over, it is essential to decide which software is suitable for the application.

System Architecture:

The process of the design implemented with the system architecture view comprises of the parts of the project work that encapsulates all modules ranging from module to module communication, setting initializations and system.

Source 1

Source 2

Router

It chooe the best path

BGP-Border Gateway Protocol

It updates the router Information

Source 3

IPDF-Inter domain packet Filter, It allow or discard the packet

Destination 2

Destination 1

Destination 3

SYSTEM ARCHITECTURE

5.1) Module Design:

The diagram shows the four modules and the operations performed in each module. First, a multicast topology is constructed. The source and destinations are decided, based on which the paths are found. After all the possible paths are found for the given destinations, the hop counts are calculated. Using the hop count the minimum hop count and path for each destination is calculated. The paths which have the minimum count is found and then the message is transmitted.

IMPLEMENTATION AND DISCUSSION

The key contributions of the project are given as follows: First, construct IDPFs at an AS by only using the information in the locally exchanged BGP updates. Second, Establishment of the conditions under which the proposed IDPF framework works correctly in that it does not discard packets with valid source addresses. The results show that, even with partial deployment, the architecture can proactively limit an attacker’s ability to spoof packets. When spoofed packet can be stopped, IDPFs can help localize the attacker to a small number of candidates ASs, which can significantly improve the IP trace back situation.

In this project there are four modules

Topology Construction.

BGP Construction.

IDPF Construction.

Control the Spoofed Packets.

Module Description:

Topology Construction:

In this module, a topology structure is constructed. A mesh topology is used because of its unstructured nature. Topology is constructed by getting the names of the nodes and the connections among the nodes as input from the user. While getting each of the nodes, their associated port and ip address is also obtained. For successive nodes, the node to which it should be connected is also accepted from the user. While adding nodes, comparison will be done so that there would be no node duplication. Then the source and the destinations are identified.

BGP CONSTRUCTION:

Each node only selects and propagates to neighbors a single best route to the destination, if any. Both the selection and the propagation of best routes are governed by locally defined routing policies. Two distinct sets of routing policies are typically employed by a node: import policies and export policies. Neighbor-specific import policies are applied upon routes learned from neighbors, whereas neighbor-specific export policies are imposed on locally selected best routes before they are propagated to the neighbors. In general, import policies can affect the “desirability” of routes by modifying route attributes. Let r be a route (to destination d) received at v from node u. It is denoted by import (v <- u) [{r}] the possibly modified route that has been transformed by the import policies. The transformed routes are stored in v’s routing table. The set of all such routes is denoted as candidateR (v, u);

CandidateR (v, d) = {r: import (v <- u) [{r}]! = {} r.prefix d Ò±u E (v)}

Here, N (v) is the set of v’s neighbors.

Among the set of candidate routes candidateR (v, d); node v selects a single best route to reach the destination based on a well-defined procedure. The (denoted) outcome of the selection procedure at node v, that is, the best route, as bestR (v, d) which reads the best route to destination d at node v. Having selected bestR (v, d) from candidateR (v, d) v then exports the route to its neighbors after applying neighbor-specific export policies. The export policies determine if a route should be forwarded to the neighbor and if so, they modify the route attributes according to the policies. It is denoted by export (v <- u) [{r}] the route sent to neighbor u by node v after node v applies the export policies on route r.

BGP is an incremental protocol: updates are generated only in response to network events. In the absence of any event, no route updates are triggered or exchanged between neighbors, and it is said that the routing system is in a stable state.

MODULE2 Diagram

IDPF CONSTRUCTION:

IDPFs can independently be deployed in each AS. IDPFs are deployed at the border routers so that IP packets can be inspected before they enter the network. By deploying IDPFs, an AS constrains the set of packets that a neighbor can forward to the AS: a neighbor can only successfully forward a packet M (s, d) to the AS after it announces the reachability information of s. All other packets are identified to carry spoofed source addresses and are discarded at the border router of the AS.

MODULE DIAGRAM 3

CONTROL THE SPOOFED PACKETS:

Based on the IDPF and BGP, the packet will be identified if spoofed or correct. If it is correct the messages allow to the destination or its spoofed means the packets will be discarded. IDPF framework works correctly in that it does not discard packets with valid source addresses.

MODULE DIAGRAM 4:

5.2) Data Flow Diagram:

The Data Flow diagram is a graphic tool used for expressing system requirements in a graphical form. The DFD also known as the “bubble chart” has the purpose of clarifying system requirements and identifying major transformations that to become program in system design.

Thus DFD can be stated as the starting point of the design phase that functionally decomposes the requirements specifications down to the lowest level of detail.

The DFD consists of series of bubbles joined by lines. The bubbles represent data transformations and the lines represent data flows in the system. A DFD describes what data flow is rather than how they are processed, so it does not depend on hardware, software, data structure or file organization.

DATA FLOW DIAGRAM:

5.3) UML DIAGRAMS

Use Case Diagram:

A use case is a set of scenarios that describes an interaction between a user and a system.  A use case diagram displays the relationship among actors and use cases.  The two main components of a use case diagram are use cases and actors. An actor is represents a user or another system that will interact with the system modeled.  A use case is an external view of the system that represents some action the user might perform in order to complete a task.

Select Destination

Find all paths using BGP

Find Best Path using BGP

Compare paths using IDPF

Discard or allow packets

Source

Destination

Activity Diagram:

Activity diagrams are typically used for business process modeling, for modeling the logic captured by a single use case or usage scenario, or for modeling the detailed logic of a business rule. In many ways UML activity diagrams are the object-oriented equivalent of flow charts and data flow diagrams (DFDs) from structured development.

ACTIVITY DIAGRAM

Class Diagram:

Class diagrams are the mainstay of object-oriented analysis and design. Class diagrams show the classes of the system, their inter relationships (including inheritance, aggregation, and association), and the operations and attributes of the classes. Class diagrams are used for a wide variety of purposes, including both conceptual/domain modeling and detailed design modeling.

Node

Construct ()

Choose best path ()

Send Message ()

Construct

Construct Structure ()

Source ()

Select destination ()

Transmit Message ()

BGP

Find Possible Path ()

Find Best Path ()

Update Routing Table ()

Attach Best Path ()

IDPF

Check ip Address ()

Discard invalid Packets ()

Forward valid Packets ()

CLASS DIAGRAM

Sequence Diagram:

Database Design

Entities:

Construction

Node

BGP

Entities with Attributes:

Construction

construction_id

source

destination

Node

node_id

node_name

port_number

ip_address

BGP

best_path_id

best_path_name

E-R Diagrams

Construction

Node

with

Construction

construction_id

source

destination

node_id(FK)

Node

node_id(PK)

node_name

port_number

ip_address

BGP

Node

with

Node

node_id

node_name

port_number

ip_address

best_path_id(FK)

BGP

best_path_id

(PK)

best_path_name

5.5) Data Dictionary

Node:

SNO

Column Name

Data Type (Size)

Constraints (Key)

ReferencES FROM

1

node_id

int(15)

Primary key

2

node_name

VARCHAR(30)

null

3

port_number

int(15)

null

4

ip_address

VARCHAR(30)

null

Construction:

SNO

Column Name

Data Type (Size)

Constraints (Key)

ReferenceS FROM

1

construction_id

int(15)

NULL

2

source

VARCHAR(30)

null

3

destination

VARCHAR(30)

NULL

4

node_id

int(15)

Foreign KEY

node

BGP:

SNO

Column Name

Data Type (Size)

Constraints (Key)

ReferenceS FROM

1

best_path_id

int(15)

Primary key

2

best_path_name

VARCHAR(30)

null

6) Implementation of Project

6.1) HTML

6.2) JavaScript

6.3) Oracle/MS Sql / MySql

6.4) Detailed Description of Technology.

7) Testing

7.1) Software Testing:

The purpose of testing is to discover errors. Testing is the process of trying to discover every conceivable fault or weakness in a work product. It provides a way to check the functionality of components, sub assemblies, assemblies, a finished product. It is the process of exercising software with the intent of ensuring that the Software system meets its requirements and user expectations and does not fail in an unacceptable manner. There are various types of test. Each test type addresses a specific testing requirement.

TYPES OF TESTS:

UNIT TESTING:

Unit testing involves the design of test cases that validate that the internal program logic is functioning properly, and that program input produces valid outputs. All decision branches and internal code flow should be validated. It is the testing of individual software units of the application .it is done after the completion of an individual unit before integration. This is a structural testing, that relies on knowledge of its construction and is invasive. Unit tests perform basic tests at component level and test a specific business process, application, system configuration. Unit tests ensure that each unique path of a business process performs accurately to the documented specifications and contains clearly defined inputs and expected results.

INTEGRATION TESTING:

Integration tests are designed to test integrated software components to determine if they actually run as one program. Testing is event driven and is more concerned with the basic outcome of screens or fields. Integration tests demonstrate that although the components were individually satisfaction, as shown by successfully unit testing, the combination of components is correct and consistent. Integration testing is specifically aimed at exposing the problems that arise from the combination of components.

FUNCTIONAL TESTING:

Functional tests provide systematic demonstrations that functions tested are available as specified by the business and technical requirements, system documentation and user manuals.

Functional testing is centered on the following items:

Valid Input : identified classes of valid input must be accepted.

Invalid Input : identified classes of invalid input must be rejected.

Functions : identified functions must be exercised.

Output : identified classes of application outputs must be exercised.

Systems/Procedures : interfacing systems or procedures must be invoked.

Organization and preparation of functional tests is focused on requirements, key functions, or special test cases. In addition, systematic coverage pertaining to identify Business process flows; data fields, predefined processes, and successive processes must be considered for testing. Before functional testing is complete, additional tests are identified and the effective value of current tests is determined.

SYSTEM TESTING:

System testing ensures that the entire integrated software system meets requirements. It tests a configuration to ensure known and predictable results. An example of system testing is the configuration oriented system integration test. System testing is based on process descriptions and flows, emphasizing pre-driven process links and integration points.

Unit Testing:

Unit testing is usually conducted as part of a combined code and unit test phase of the software lifecycle, although it is not uncommon for coding and unit testing to be conducted as two distinct phases.

Test strategy and approach

Field testing will be performed manually and functional tests will be written in detail.

Test objectives

All field entries must work properly.

Pages must be activated from the identified link.

The entry screen, messages and responses must not be delayed.

Features to be tested

Verify that the entries are of the correct format

No duplicate entries should be allowed

All links should take the user to the correct page.

Integration Testing:

Software integration testing is the incremental integration testing of two or more integrated software components on a single platform to produce failures caused by interface defects.

The task of the integration test is to check that components or software applications, e.g. components in a software system or – one step up – software applications at the company level – interact without error.

Test Results:

All the test cases mentioned above passed successfully. No defects encountered.

Acceptance Testing:

User Acceptance Testing is a critical phase of any project and requires significant participation by the end user. It also ensures that the system meets the functional requirements.

Test Results:

All the test cases mentioned above passed successfully. No defects encountered.

7.2) Testing Objectives

WHITE BOX TESTING:

White Box Testing is a testing in which in which the software tester has knowledge of the inner workings, structure and language of the software, or at least its purpose. It is used to test areas that cannot be reached from a black box level .

BLACK BOX TESTING:

Black Box Testing is testing the software without any knowledge of the inner workings, structure or language of the module being tested. Black box tests, as most other kinds of tests, must be written from a definitive source document, such as specification or requirements document, such as specification or requirements document. It is a testing in which the software under test is treated, as a black box . The test provides inputs and responds to outputs without considering how the software works.

7.3) Test Cases

IMPLEMENTATION:

Implementation is the stage of the project when the theoretical design is turned out into a working system. Thus it can be considered to be the most critical stage in achieving a successful new system and in giving the user, confidence that the new system will work and be effective.

The implementation stage involves careful planning, investigation of the existing system and it’s constraints on implementation, designing of methods to achieve changeover and evaluation of changeover methods.

Implementation is the process of converting a new system design into operation. It is the phase that focuses on user training, site preparation and file conversion for installing a candidate system. The important factor that should be considered here is that the conversion should not disrupt the functioning of the organization.

The implementation can be preceded through Socket in java but it will be considered as one to all communication .For proactive broadcasting a dynamic linking is needed. So java will be more suitable for platform independence and networking concepts. For maintaining route information, a SQL-server is used as database back end.

8) OUTPUT SCREENS

SCREEN SHOTS:

9) Test Cases:

Topology Creation

Test case 1: TopologyCreation.

Priority (H, L): High

Test Objective: For Creating Topolgy

Test Description: “Topology is constructed by getting the names of the nodes and the connections among the nodes as input from the user.While getting each of the nodes, their associated port and ip address is also obtained.

Requirements Verified: Yes

Test Environment: Database Should contain appropriate table and link must be established between database and client program.

Test Setup/Pre-Conditions: New Node, IP Address, Port Number.

Actions

Expected Results

The user presses submit button.

Displays BGP window.

Pass: Conditions pass: No Fail: No

Problems / Issues: NIL

Notes: Successfully Executed

Border Gateway Protocol

Test case 1: Border Gateway Protocol

Priority (H, L): High

Test Objective: For choosing best path.

Test Description: “Each node only selects and propagates to neighbors a single best route to the destination, if any. Both the selection and the propagation of best routes are governed by locally defined routing policies.

Requirements Verified: Yes

Test Environment: Database Should contain appropriate table and link must be established between database and client program.

Test Setup/Pre-Conditions: Node information should be provided.

Actions

Expected Results

The user presses GetTheBestPath button.

Displays confirmation window for not to spoof IP Address.

Pass: Conditions pass: No Fail: No

Problems / Issues: NIL

Notes: Successfully Executed

IDPF

Test case 1: IDPF

Priority (H, L): High

Test Objective: For Checking Spoofed IP Packets.

Test Description: “IDPFs can independently be deployed in each AS. IDPFs are deployed at the border routers so that IP packets can be inspected before they enter the network.

Requirements Verified: Yes

Test Environment: Database Should contain appropriate table and link must be established between database and client program.

Test Setup/Pre-Conditions: BGP must choose best path

Actions

Expected Results

The user presses Yes button.

Pass: Conditions pass: No Fail: No

Problems / Issues: NIL

Notes: Successfully Executed

10) CONCLUSION

10.1) Limitations

In this project IDPF architecture is used as an effective countermeasure to the IP spoofing- based DDoS attacks. IDPFs rely on BGP update messages exchanged on the Internet to infer the validity of source address of a packet forwarded by a neighbor. The IDPFs can easily be deployed on the current BGP-based Internet routing architecture. The conditions under which the IDPF framework can correctly work without discarding any valid packets. The simulation results showed that, even with partial deployment on the Internet, IDPFs can significantly limit the spoofing capability of attackers. Moreover, they also help the true origin of an attack packet to be within a small number of participant networks, therefore simplifying the reactive IP traceback process.

10.2) Future Enhancements:

It also helps the true origin of an attack packet to be within a small number of participant networks, thus simplifying the reactive IP traceback process.