[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/13 03:06:24

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

Log message:
        couple issues resolved

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/attacking_gisp--hemppah/peg.rst.diff?tr1=1.28&tr2=1.29&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.28 
storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.29
--- storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.28     Thu Jun 12 
10:03:53 2003
+++ storm/doc/pegboard/attacking_gisp--hemppah/peg.rst  Fri Jun 13 03:06:24 2003
@@ -4,8 +4,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-05
-:Last-Modified: $Date: 2003/06/12 14:03:53 $
-:Revision: $Revision: 1.28 $
+:Last-Modified: $Date: 2003/06/13 07:06:24 $
+:Revision: $Revision: 1.29 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -37,6 +37,61 @@
 that attacks.
 
 
+Issues
+======
+
+ISSUE: When should we discuss this with the author of GISP?
+
+ISSUE: Does GISP support "free-choice" during lookups?
+
+       RESOLVED: No, the current Java implementation does not support
+       "peer-choice". However, the protocol specification of GISP-3.4 allows 
+       the "free choice".
+
+ISSUE: Is GISP peer able to determine if an another peer is
+       not "useful" or not (not just PING scenario)  ("a peer can discard
+       information of unreachable peers")
+       
+       RESOLVED: Yes, there are directions in the protocol specification
+       how GISP peer should handle undesirable messages and peers:
+       
+       "3.6. Security Behavior
+
+       For the security of the entire system,
+       each peer SHOULD deal with possible attacks.
+       A peer SHOULD detect undesirable messages such as:
+       A message that is not valid.
+       A message with <peer> or <insert> elements
+       whose millisecond to live (ttl) is too big.
+       A message or its elements are
+       already received in a short period of time.
+       A whole or a part of an undesirable message
+       SHOULD be discarded.
+       A peer MAY record the undesirable message or its information
+       for the future security purpose.
+
+       A peer SHOULD also detect undesirable peers such as:
+       A peer which never respond.
+       A peer which rarely responds.
+       A peer which sends undesirable messages.
+       A peer which sends too many messages.
+       An undesirable peer SHOULD be removed from the peer routing table
+       and SHOULD NOT be included in outgoing messages.
+       A peer MAY record the undesirable peer information
+       for the future security purpose."
+       
+       Please notice, however, the word "SHOULD".
+       
+ISSUE: Related to the previous issue, how (non) "uselessness" is 
+       determined by a GISP peer and is it a reliable method ?
+       
+       RESOLVED: No, the current GISP implementation does not address 
+       "uselessness" properly, since GISP peer only observes reply 
+       timeouts, i.e., the time which has been passed since last
+       reply.
+
+
+
 Research problems
 =================
 
@@ -172,20 +227,11 @@
 
 Hypothesis:
 
- 
-  
-  
-- GISP has average of O(log n) lookup length in a static network, where n is 
-  the total number of peers in the network, since GISP uses Chord-like routing 
-  table
-  
-.. to different PEG ?
-  
 - It is expected that (popular) data items can be found with fewer hops in 
   *some cases* in GISP network w.r.t Chord network, since GISP extends Chord's 
   routing table to have more information as a cache
   
-.. more specific, what effects cache has ?
+.. more specific, what effects cache has, formula ?
 
   
 - GISP's lookup failure rate increases linearly with the fraction of "dumb" 
@@ -233,49 +279,6 @@
 We will compare (and validate) our test results with the Chord's 
 performance and fault tolerance properties.  
   
-Issues
-======
-
-ISSUE: When should we discuss this with the author of GISP?
-
-ISSUE: Does GISP support "peer-choice" during lookups?
-
-ISSUE: Is GISP peer able to determine if an another peer is
-       not "useful" or not (not just PING scenario)  ("a peer can discard
-       information of unreachable peers")
-       
-       RESOLVED: Yes, there are directions in the protocol specification
-       how GISP peer should handle undesirable messages and peers:
-       
-       "3.6. Security Behavior
-
-       For the security of the entire system,
-       each peer SHOULD deal with possible attacks.
-       A peer SHOULD detect undesirable messages such as:
-       A message that is not valid.
-       A message with <peer> or <insert> elements
-       whose millisecond to live (ttl) is too big.
-       A message or its elements are
-       already received in a short period of time.
-       A whole or a part of an undesirable message
-       SHOULD be discarded.
-       A peer MAY record the undesirable message or its information
-       for the future security purpose.
-
-       A peer SHOULD also detect undesirable peers such as:
-       A peer which never respond.
-       A peer which rarely responds.
-       A peer which sends undesirable messages.
-       A peer which sends too many messages.
-       An undesirable peer SHOULD be removed from the peer routing table
-       and SHOULD NOT be included in outgoing messages.
-       A peer MAY record the undesirable peer information
-       for the future security purpose."
-       
-       Please notice, however, the word "SHOULD".
-       
-ISSUE: Related to the previous issue, how (non) "uselessness" is 
-       determined by a GISP peer and is it a reliable method ?
 
 Changes
 =======