[Gzz] PEG: Attacking against GISP

[Hermanni Hyytiälä]

==========================================================================
PEG attacking_gisp--hemppah:
==========================================================================

:Authors:  Hermanni Hyytiälä
:Date-Created: 2003-06-05
:Last-Modified: $Date: 2003/06/05 13:42:50 $
:Revision: $Revision: 1.4 $
:Status:   Incomplete

.. :Stakeholders:
.. :Scope:    Major|Minor|Trivial|Cosmetic
.. :Type:     META|Policy|Architecture|Interface|Implementation

.. Affect-PEGs:

This PEG document briefly describes the attack methods used by a
"killer" 
program against the GISP P2P software. The program is used to test
GISP's
robustness against hostile attacks.  

In this document we mean with "peer" as an entity which is able to do a 
(limited/simplified/modified) number of regular GISP peer's
functionalies
in a way which may be harmful for the GISP network w.r.t. performance
and redundancy. The harmfulness of a peer be a consequence of the fact
that a peer is faulty, or a peer is wilfully malicious. 

Disclaimer
==========
This program is only used for research purposes and
the goal is to improve GISP's resilience against hostile attacks.


Research problems
=================

For determining whether GISP is resilient against hostile attack, 
we want the answers to the following questions:

- Does GISP have *obvious* exploits ?

- If there are exploits how easily they can be used by an 
  hostile peer ? 

- Is GISP resilient against (hostile) attacks or not ?

- How severe implications attacks may cause ?

- How well GISP is able to re-organise after a (hostile) attack ?

Simulation method
==================

We will perform simulations on a single desktop computer. We intend
to use GISP's native code as much as possible. We start our 
simulation process by creating simple scenarios in which:

- A hostile (or faulty) peer(s) doesn't reply to queries (a "dumb"
peer)*

- A hostile (or faulty) peer(s) tries to drop certain packets/queries
wilfully*
  
- A hostile (or faulty) peer(s) forwards queries to incorrect
destination peers

- A hostile (or faulty) peer(s) gives false information during queries

- A hostile (or faulty) peer(s)'s queries/replies include loads of
rubbish, i.e., 
  wrong XML-scheme, wrong string/text encoding, or doesn't otherwise
follow the protocol
  
- A hostile (or faulty) peer(s) performs many queries randomly

- A hostile (or faulty) peer(s) performs many queries wilfully with a
certain key

- A hostile (or faulty) peer(s) stores lot of dummy random
key-value-pairs

- A hostile (or faulty) peer(s) stores lot of dummy key-value-pairs with
a certain key

During the simulation process we will use a single hostile (or faulty)
peer
or a group of hostile/faulty peers (fraction of all peers) in the test
network. 

By using above scenarios, we want to clarify GISP's properties with
regard to research 
questions.

*=We start the simulation process with these scenarios.  
  
Issues
======

.. Is there any issues ?

None, yet.

Changes
=======

No changes are required to the Storm implementation
codebase.