p2psp team mailing list archive

[Ilshat Shakirov <im.shakirov@xxxxxxxxx>]

Hello!,

Here are some final results of testing STrPe&STrPe-DS mechanisms.

STrPe-DS | Persistent attack:
https://docs.google.com/spreadsheets/d/1iSNQwanXT10XravpkfPz706ASdeIv3NvUOF0QqMU3rg/edit#gid=0
STrPe-DS | On-off attack:
https://docs.google.com/spreadsheets/d/1AcrhbcFvd_iRISeDa26ObRiApPHpV4-BqPoRipiKRcc/edit#gid=0
Network usage (by rounds):
https://docs.google.com/spreadsheets/d/1LhypThplzYVpiNWfnuLH73H-ZagznKO2BYzjCk1dXdE/edit?usp=sharing

The really interesting result is network usage sheet. The both mechanisms
have very low overhead (no more than 10%, service messages, like list of
bad peers, chunk_check message and so on) costs very low traffic.
Tests was performed in the team with 10 peers (9 well-intended peers and
one trusted peer).

About STrPe-DS:
Also, in case of persistent attack and on-off attack mal. peers was
discovered very fast. Also, number of trusted peers in the team doesnt
affect on this speed (at all). So, in on-off attack I performed tests only
with 1 TP.
Because of this speed, mal. peers don't have time to do much harmful effect
on the team, it can be seen on buffer_filling graphs.

Currently, Im preparing last blogpost.

Thanks!

2015-08-18 18:36 GMT+06:00 Ilshat Shakirov <im.shakirov@xxxxxxxxx>:

> Hello!,
>
>
>> They are nice results.
>>
>
> Thanks!
>
>
>> What 40% on-off attack means?
>>
>
> In 40% of cases peer sends poisoned chunk instead of correct chunk.
>
>
> 2015-08-18 17:34 GMT+05:00 L.G.Casado <leo@xxxxxx>:
>
>> Dear Ilshat,
>>
>> They are nice results.
>> What 40% on-off attack means?
>>
>>
>> Best,
>>
>> Leo
>>
>> El mar, 18-08-2015 a las 17:24 +0500, Ilshat Shakirov escribió:
>>
>> Hello!,
>>
>> Here is small status update.
>> I've implemented new types of attack for malicious peers:
>> -persistent attack
>> -on-off attack
>> -selective attack
>> -bad-mouth attacj (for strpe-ds only)
>>
>> Also, I've added new option --checkall for STrPe trusted peers. If this
>> option is enablde, then TP sends every received chunk to splitter to check.
>>
>> Here is some tests I performed for STrPe mechanism:
>> Persistent attack (with checkall option) :
>> https://docs.google.com/spreadsheets/d/1iNva1mvO9NETj8fJ9oZpy1VhAUYxJi4K7gUojqzSEqI/edit
>> On-off attack (40%) :
>> https://docs.google.com/spreadsheets/d/1-sLkrjdNQHx-jXxWeVYz4pmnd6qgC1D3MuVnbhQ4lYE/edit?usp=sharing
>>
>> For each configuration Ive performed 5 experiments, on last tab the
>> result table is presented.
>>
>> I've made next observations (for STrPe):
>> - there is need to increase splitter's buffer, since it have to check
>> chunks which can be deleted from its buffer. I've performed tests with
>> --buffer_size 1024 (256 by default). I think that buffer should smth like 4
>> * team_size.
>> - with check all option number of TP doesnt affect speed of expulsion
>> mal. peers (in case of persistent attack). Every mal. peer is excluding for
>> 1 splitter round in average.
>> - in on-off attack number of TP affects on speed of excluding peers. So,
>> more TPs - more chances to send posioned chunks to TP.
>> - there is very small affect on buffer correctness for all the team.
>> Average for the team is between 0.95 and 1.
>>
>> Also, here is my testing plan :
>> https://docs.google.com/document/d/13oSUgkRrmUh8nM3mMe5FEmwBlSfrxs0NXkei0JVubBo/edit?usp=sharing
>>
>> Currently, Im performing tests for STrPe-DS mechanism (according to my
>> test plan).
>>
>> Thanks.
>>
>> 2015-08-14 2:03 GMT+05:00 Ilshat Shakirov <im.shakirov@xxxxxxxxx>:
>>
>> Hello!,
>>
>> Here is two raw data sets with result data from experiments with STrPe
>> and STrPe-DS:
>>
>> STrPe:
>> https://docs.google.com/spreadsheets/d/13xzEwQKbB58p0K8VyQjvez2L-QABP_ouelbqmWMSE7w/edit#gid=1026220953
>> STrPe-DS:
>> https://docs.google.com/spreadsheets/d/1YZnLaWrjAJRgXZ2LQrHhgewOnzL1Fm073ix6dULmwpc/edit#gid=1531244678
>>
>> As you can see in STrPe number of TP affects on speed of expulsion mal.
>> peers. It happens because TP selects next chunk to check randomly from its
>> stream of chunks. Resp. if we have more TP then it will take less number of
>> rounds to expel all TP.
>> You can check it in code here:
>> https://github.com/P2PSP/p2psp/blob/cis/src/trusted_peer.py#L55
>>
>> Also, you can see that in STrPe-DS if we have more mal. peers, we have
>> more rounds to expel all mal. peers. It happens because including new mal.
>> peers take 0.5 - 1 round, and resp. we have more rounds to include all mal.
>> peers to the team. In the simple persistent attack mal. peers excluding
>> almost at the same time they sended poisoned chunk to TP.
>>
>> Why a TP does not check every chunk?
>> In a persistent attack, peers will be detected directly.
>>
>>
>> Because it can reduce the performance of TP and the system (I think)
>>
>> Again, for persisten attack this is true, but not for the more
>> sophisticated ones.
>>
>> What kinds of attack should I perform?
>>
>> Also, I think I know how to compromise Third Trusted Party (and resp.
>> perform selective attack) for only log(n) time.
>> Attacker should perform attack on the half of the team. If mal. peer was
>> excluded, then in given half exists TP. Then this half divide to new 2
>> halfs and so on. So, we can find all the TPs in O(log2(n)) time.
>>
>> Thanks!
>>
>>
>> 2015-08-12 15:43 GMT+05:00 L.G.Casado <leo@xxxxxx>:
>>
>> Hello,
>>
>>
>> El mié, 12-08-2015 a las 15:27 +0500, Ilshat Shakirov escribió:
>>
>> Hello,
>>
>> N-1, is set because there is one Trusted peer, does it?
>>
>>
>> Yes, because trusted peer doesnt check itself.
>>
>>
>> How is set X, random check yes/no?
>>
>> I think yes. In the first impl of STrPe trusted peers checked every 255
>> received chunk.
>>
>>
>> Why a TP does not check every chunk?
>> In a persistent attack, peers will be detected directly.
>>
>> The random check could be seen as malicious peer performing  a kind of
>> selective attack.
>>
>> About current progress:
>> I've found a small bug in the initialization of big teams (i.e. 100
>> peers) with enabled STrPe-DS. In 2-3% of cases peer hangs up and do nothing.
>>
>> Then, they should be expeled soon.
>>
>> Also, Ive prepared a raw data from STrPe experiments (Ive performed
>> experiments with 100 peers, 1-2-4-8 trusted, and 10-25 malicious). And
>> since trusted peers in STrPe checks chunks randomly from all the peers in
>> the team, it can take long time to expel all the malicious peers. It
>> happens because TP selects chunk to check from all stream, although it
>> should select chunks from each peer.
>>
>>
>> I think to check randomly has no sense if trusted peer is in system
>> without resources limitations, which should be the case.
>>
>> If we implement this, then Juan will be right and number of TPs in the
>> team won't have impact on mal. peer expulsion. Now, if we have more TP, we
>> have more chances, that TP will check chunk from mal. peers and will
>> exclude it.
>>
>> Yes, checking them all, just on TP is enough for persistent attack, but
>> it is not the case for other attacks.
>>
>> Also, STrPe-DS don't have such problem, because I've implemented next
>> logic:Every S seconds splitter selects new peer from all the team and TP
>> from trusted peers and do 2 requests to gather complains from the team.
>>
>> So, mal. peers will be excluded almost in the same time they ve sended
>> poisoned chunks to TP.
>>
>> Again, for persisten attack this is true, but not for the more
>> sophisticated ones.
>>
>> Thanks!
>>
>> Best,
>>
>> Leo
>>
>> 2015-08-12 15:08 GMT+05:00 L.G.Casado <leo@xxxxxx>:
>>
>> Dear Ilshat,
>>
>> El mié, 12-08-2015 a las 12:04 +0200, L.G.Casado escribió:
>>
>> BC = 1 - M / (N - 1 + 1) = 1 - M / N,
>>
>>
>> Sorry, the formula was fine:
>>
>> (N-M)/N= 1-M/N
>>
>> Please, answer the other questions.
>>
>> Thanks,
>>
>> Leo
>>
>>
>>
>>
>>
>>
>>
>