[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz] attacking gisp peg comments
From: |
Tuomas Lukka |
Subject: |
[Gzz] attacking gisp peg comments |
Date: |
Wed, 11 Jun 2003 13:37:58 +0300 |
User-agent: |
Mutt/1.5.4i |
> ==========================================================================
> 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
- [Gzz] attacking gisp peg comments,
Tuomas Lukka <=