[Gzz] attacking gisp peg comments

[Tuomas Lukka]

> ==========================================================================
> PEG attacking_gisp--hemppah:
> ==========================================================================
> 
> :Authors:  Hermanni Hyytiälä
> :Date-Created: 2003-06-05
> :Last-Modified: $Date: 2003/06/11 09:28:52 $
> :Revision: $Revision: 1.21 $
> :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. The program is intended to be used to test GISP_ P2P software's 
> robustness against hostile attacks.  

Probably should explain "first version" and when you do the next one,
start a new peg.

The idea would be that you start the experiments once the PEG is accepted.

> In this document we mean with "hostile 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 is a consequence of the fact
> that 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.
> 
> Additionally, the author of GISP has stated that he will address 
> attacks as they become a problem. This inclines to think 
> that writing an attack program will get the author to address 
> that attacks.

inclines *us*

> We expect that GISP's fault tolerance is at least at the same level as 
> Chord_'s 
> fault tolerace since GISP's routing table is based on Chord's routing table.
> 
> Chord's general properties:
> - O(log^2 n) messages are required to join/leave operations 
> - O(log n) lookup efficiency
> - Routing table maintains information about O(log n) peers
> - Routing table requires information about O(log n) of other peers
>   of *efficient* routing, but performance degrades gracefully
>   when that information is out of date 
> - Only one piece of information per peer need to be corect in 
>   order to guarantee correct (though slow) routing queries  

Do you *KNOW* whether this works for GISP with dumb peers or not?


> Eventually, we will compare (and validate) our test results with the Chord's 
> fault tolerance properties.

Not eventually.

YOU NEED TO MAKE A REAL INFORMATIVE STATEMENT ABOUT WHAT THE RESULTS
WILL BE THAT COULD BE RIGHT OR WRONG.

You're still shielding yourself by making really vague statements.
*NOT* good. You have to put yourself on the line by making some *real*
predictions which will be such that when *I* look at the predictions
and test results I can immediately see whether the predictions were right
or not -- and the probability of making the correct predictions randomly
should be really small!

> Simulation Process: 
> - 9*10^k normal peers, 1*10^k "dumb" peers, where k = 1..3
> - n*10^k normal peers, d*10^k "dumb" peers, where k = 1..3, n = 1..9
>   and d = 1..9

What?

> - For a normal peers ID is in the format "peer1, peer2..." and for a "dumb" 
> peer 
>   ID is in the format "dumb1, dumb2..." 

Is this relevant? Just say "different spaces"

> - Create 5000 key/value items in the network (the format is "key1, key2...", 
>   "value1, value2...")

Same here: these are irrelevant details.

> - Perform 2500 queries randomly with *normal* peers (random peer selection  
>   and random query selection)

Why 2500?

> - Test case is performed with loop (e.g., while(true) etc)

Another irrelevant point

> - "Distributed" peermap is based on Java's HashMap data structure 
> (synchronized)
> - Use org.apache.log4j package for logging information

And some more.


> Scenario #2 (dynamic "dumb"): 

Let's postpone this to the next PEG.

> Issues
> ======
> 
> ISSUE: When should we discuss this with the author of GISP?
> 
> ISSUE: Does GISP support "peer-choice" during lookups?
> 
> 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")    

"Does .. is able" isn't proper English.

        Tuomas