[Gzz-commits] storm/doc/pegboard/attacking_gisp--hemppah peg.rst

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/storm
Module name:    storm
Branch:         
Changes by:     Hermanni Hyytiälä <address@hidden>      03/06/06 04:23:35

Modified files:
        doc/pegboard/attacking_gisp--hemppah: peg.rst 

Log message:
        update and clean

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/attacking_gisp--hemppah/peg.rst.diff?tr1=1.4&tr2=1.5&r1=text&r2=text

Patches:
Index: storm/doc/pegboard/attacking_gisp--hemppah/peg.rst
diff -u storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.4 
storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.5
--- storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.4      Thu Jun  5 
09:42:50 2003
+++ storm/doc/pegboard/attacking_gisp--hemppah/peg.rst  Fri Jun  6 04:23:35 2003
@@ -5,8 +5,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-05
-:Last-Modified: $Date: 2003/06/05 13:42:50 $
-:Revision: $Revision: 1.4 $
+:Last-Modified: $Date: 2003/06/06 08:23:35 $
+:Revision: $Revision: 1.5 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -16,77 +16,70 @@
 .. Affect-PEGs:
 
 
--PEG document for implementing killer program against the GISP P2P software
--for research purposes only
--the goal is to improve GISP's resilience against hostile attacks
+This PEG document describes general properties of a killer program against 
+the GISP P2P software. This program is only used for research purposes and
+the goal is to improve GISP's resilience 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.
 
 Research problems
 =================
 
-- 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 ?
+For determining whether GISP is resilient against hostile attack, 
+we want the answers to the following questions:
 
-Simulation methods
-==================
+- Is GISP resilient against (hostile) attacks or not ?
 
-- Use GISP's native code as much as possible
+- How severe implications attacks may cause ?
 
+- How well GISP is able to re-organise after a (hostile) attack ?
 
-Attacks models
-==============
+- Does GISP have *obvious* exploits ?
 
-- Peer just wants to make the network work slower
- 
-  - Extra network packets / random false queries
-  - Drop random packets
-  - Try to drop packets wilfully
+- If there are exlpoits, how easily they can be used by an 
+  hostile peer ? 
 
-- Peer wants to make searches for some particular informations difficult
+Simulation method
+==================
 
-  - Forward incorrectly if a key is identified correctly
-  - Peer doesn't reply/forward at all
+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:
 
-- Peer wants to make life difficult for some particular peers,
-  slowing down their queries
-  
-  - Reply false information
-  - Peer doesn't reply/forward at all
+- A hostile (or faulty) peer(s) doesn't reply to queries (a "dumb" peer)*
 
-- Peer wants to make search for particular information by particular peers
-  difficult
+- A hostile (or faulty) peer(s) tries to drop certain packets/queries wilfully*
   
-  - Forward incorrectly if a key and source IP are identified correctly
-  - Peer doesn't reply/forward at all
+- A hostile (or faulty) peer(s) forwards queries to incorrect destination peers
 
-- Peer wants to spam a particular identifier 
+- A hostile (or faulty) peer(s) gives false information during queries
 
-  - Store lot of dummy key-value-pairs with a specific key
+- A hostile (or faulty) peer(s)'s queries/replies include loads of rubbish, 
e.g., 
+  wrong XML-scheme, wrong string/text encoding, or doesn't otherwise follow 
the protocol
   
-- Peer wants to spam a random identifier
+- A hostile (or faulty) peer(s) performs many queries randomly
 
-  - Store lot of dummy random key-value-pairs 
-  
-- Delete peer/peers randomly/wilfully
+- A hostile (or faulty) peer(s) performs many queries wilfully with a certain 
key
 
- - perform queries randomly
- - perform queries wilfully
+- A hostile (or faulty) peer(s) stores lot of dummy random key-value-pairs
 
-- Byzantine-like peer/peers ?
+- A hostile (or faulty) peer(s) stores lot of dummy key-value-pairs with a 
certain key
 
- - Peer's reply includes loads of rubbish, e.g., wrong XML-scheme, wrong string
-   encoding, or not following a protocol itself
- - something else ?
-  
-  
-More to come...
+During the simulation process we will use a single hostile/faulty peer
+or a group of hostile/faulty peers (fraction of all peers). 
 
+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
 ======
 
-Nothing yet.
+.. Is there any issues ?
+
+None, yet.
 
 Changes
 =======