Re: [Gzz] PEG: Attacking against GISP

[Tuomas Lukka]

On Fri, Jun 06, 2003 at 12:35:53PM +0300, Hermanni Hyytiälä wrote:
> 
> ==========================================================================
> PEG attacking_gisp--hemppah:
> ==========================================================================
> 
> :Authors:  Hermanni Hyytiälä
> :Date-Created: 2003-06-05
> :Last-Modified: $Date: 2003/06/05 13:42:50 $
> :Revision: $Revision: 1.4 $
> :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 against the GISP P2P software. The program is used to test
> GISP's
> robustness against hostile attacks.  

Used -> intended to be used / tried / ...

This is a plan, not the post-factum documentation.


> In this document we mean with "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. 

Umm, bad choice of words - recommend "hostile peer", "faulty peer"

> The harmfulness of a peer be a consequence of the fact
> that a peer is faulty, or a peer is wilfully malicious. 

Let's start with plain maliciousness... Anything that faultiness can do,
malice can do better.

> Disclaimer
> ==========
> This program is only used for research purposes and
> the goal is to improve GISP's resilience against hostile attacks.

.. author has stated that blah blah -- give background.

> Research problems
> =================
> 
> For determining whether GISP is resilient against hostile attack, 
> we want the answers to the following questions:

Incorrect: 

GISP does not appear to address the attacks against DHT systems
described in [...] and [...].

The question is *how* much harm can a peer do.

> Simulation method
> ==================
> 
> We will perform simulations on a single desktop computer. We intend
> to use GISP's native code as much as possible. We start our 
> simulation process by creating simple scenarios in which:
> 
> - A hostile (or faulty) peer(s) doesn't reply to queries (a "dumb"
> peer)*

(but takes part in forming of the network?) ... 

> - A hostile (or faulty) peer(s) tries to drop certain packets/queries
> wilfully*
>
> - A hostile (or faulty) peer(s) forwards queries to incorrect
> destination peers
> 
> - A hostile (or faulty) peer(s) gives false information during queries
> 
> - A hostile (or faulty) peer(s)'s queries/replies include loads of
> rubbish, i.e., 
>   wrong XML-scheme, wrong string/text encoding, or doesn't otherwise
> follow the protocol
>   
> - A hostile (or faulty) peer(s) performs many queries randomly
> 
> - A hostile (or faulty) peer(s) performs many queries wilfully with a
> certain key
> 
> - A hostile (or faulty) peer(s) stores lot of dummy random
> key-value-pairs

> - A hostile (or faulty) peer(s) stores lot of dummy key-value-pairs with
> a certain key

Does GISP allow several values per key?

> During the simulation process we will use a single hostile (or faulty)
> peer
> or a group of hostile/faulty peers (fraction of all peers) in the test
> network. 
> 
> By using above scenarios, we want to clarify GISP's properties with
> regard to research 
> questions.
> 
> *=We start the simulation process with these scenarios.  

Next you should describe the exact scenarios you want to try,
so start with the dumb peer and specify it exactly.

Then run the test.


> Issues
> ======
> 
> .. Is there any issues ?
> 
> None, yet.

ISSUE: When should we discuss this with the author of GISP?

        Tuomas