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

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/storm
Module name:    storm
Changes by:     Hermanni Hyytiälä <address@hidden>      03/06/05 09:34:08

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

Log message:
        more

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/attacking_gisp--hemppah/peg.rst.diff?tr1=1.1&tr2=1.2&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.1 
storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.2
--- storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.1      Thu Jun  5 
09:20:25 2003
+++ storm/doc/pegboard/attacking_gisp--hemppah/peg.rst  Thu Jun  5 09:34:08 2003
@@ -5,8 +5,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-05
-:Last-Modified: $Date: 2003/06/05 13:20:25 $
-:Revision: $Revision: 1.1 $
+:Last-Modified: $Date: 2003/06/05 13:34:08 $
+:Revision: $Revision: 1.2 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -18,37 +18,62 @@
 
 -PEG document for implementing killer program against the GISP P2P software
 -for research purposes only
--the goal is to evaluate GISP's resilience against hostile attacks
+-the goal is to improve GISP's resilience against hostile attacks
 
-Environment
-===========
 
-Nothing yet.
+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 ?
+
+Simulation methods
+==================
+
+- Use GISP's native code as much as possible
+
 
 Attacks models
 ==============
 
 - Peer just wants to make the network work slower
  
-  How this can be done ? Using extra network packets ?
+  - Extra network packets / random false queries
+  - Drop random packets
+  - Try to drop packets wilfully
 
 - Peer wants to make searches for some particular informations difficult
 
-  -Forward incorrectly if a key is identified correctly ?
+  - Forward incorrectly if a key is identified correctly
 
 - Peer wants to make life difficult for some particular peers,
   slowing down their queries
   
-  -Reply false information ? 
+  - Reply false information
 
 - Peer wants to make search for particular information by particular peers
   difficult
   
-  -Forward incorrectly if a key and source IP are identified correctly ?
+  - Forward incorrectly if a key and source IP are identified correctly 
 
 - Peer wants to spam a particular identifier 
 
-  -Store lot of dummy key-value-peers with a specific key ?
+  - Store lot of dummy key-value-pairs with a specific key
+  
+- Peer wants to spam a random identifier
+
+  - Store lot of dummy random key-value-pairs 
+  
+- Delete peer/peers randomly/wilfully
+
+ - perform queries randomly
+ - perform queries wilfully
+
+- Byzantine-like peer/peers ?
+
+ - Peer's reply is loads of rubbish (not following a protocol)
+ - something else ?
   
   
 More to come...