[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/11 07:02:04

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

Log message:
        resolved an issue

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/attacking_gisp--hemppah/peg.rst.diff?tr1=1.21&tr2=1.22&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.21 
storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.22
--- storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.21     Wed Jun 11 
05:28:52 2003
+++ storm/doc/pegboard/attacking_gisp--hemppah/peg.rst  Wed Jun 11 07:02:03 2003
@@ -4,8 +4,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-05
-:Last-Modified: $Date: 2003/06/11 09:28:52 $
-:Revision: $Revision: 1.21 $
+:Last-Modified: $Date: 2003/06/11 11:02:03 $
+:Revision: $Revision: 1.22 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -197,7 +197,40 @@
 
 ISSUE: Does GISP peer is able determine if an another peer is
        not "useful" or not (not just PING scenario)  ("a peer can discard
-       information of unreachable peers")    
+       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 prevous issue, how (non) "uselessness" is 
+       determined by a GISP peer and is it a reliable method ?
 
 Changes
 =======