p2psp team mailing list archive

[Ilshat Shakirov <im.shakirov@xxxxxxxxx>]

Hello!,

Here is report for the second week:
http://shakirov-dev.blogspot.ru/2015/06/the-second-week.html
It's quite small, but I want to end the STrPe part of project by this week
(or may be by the next week), so I have some questions:

1. *Malicious peer* : Is there need to implement sending chunks after
splitter removed this peer from its (splitter) peer list?
2. *STrPe *: Is there need to implement expel message for peers? (message
about that peer A is malicious)
3. *Testing plan* : How it should looks like? I am preparing plan with
different kinds of attacks, smth like this:

>
> *STrPe:*
>
> *  On-off attack:*
>
> *    Confguration of team: 1 monitor, 1 trusted, 1 malicious which is
> reconnecting to splitter after detection*
>
> *    Expected: Malicious peer is detected every time it is reconnecting*
> *    Actual: ______*
>

> *  Bad-mouth attack:....*
>
The main question is about section 'Expected' : What params I should
mention in this section? Description '*Malicious peer is detected every
time it is reconnecting' *looks a little bit informal.

Thanks!

2015-06-01 13:22 GMT+05:00 Ilshat Shakirov <im.shakirov@xxxxxxxxx>:

> Hello!,
>
>
>> 1) Why a different socket is needed for poisoned chunks?
>
> Because in the other case, I have to override long method *process_next_message.
> *I thought that the solution with replacing socket is more clear.
>
> 2)Malicious peer relay chunks received from splitter. If the sppliter does
>> not send chunks to a malicious peer, What chunk is relayed?
>>
> In current impl no chunk is relayed if splitter doesn't send chunks to
> malicious peer. I will fix it later (in this week).
>
> 3) crc32 is not suitable as cryptographic hash function. See
>> http://en.wikipedia.org/wiki/Cryptographic_hash_function.
>>
> I will use sha256 instead. Is it ok?
>
> 4) I do not see the problem with 255. Trusted peer just send information
>> to the sppliter about the chunks received and who send them.
>>
> I think that it is the problem, because trusted peer can never send the
> chunks from malicious peer (if malicious peer will be lucky and its chunks
> won't be 255th in trusted peer).
>
> ps: about 2: is there need to implement this functionality; because if
> peer will not receive new chunks from splitter, he won't know the chunk
> numbers, and he cannot fake the chunk messages (since it doesn't know chunk
> numbers).
>
> Thanks!
>
>
> 2015-06-01 12:55 GMT+05:00 L.G.Casado <leo@xxxxxx>:
>
>>  Hello Ilshat,
>>
>> Please can you answer the following questions:
>>
>> 1) Why a different socket is needed for poisoned chunks?
>> 2)Malicious peer relay chunks received from splitter. If the sppliter
>> does not send chunks to a malicious peer, What chunk is relayed?
>> 3) crc32 is not suitable as cryptographic hash function. See
>> http://en.wikipedia.org/wiki/Cryptographic_hash_function.
>> 4) I do not see the problem with 255. Trusted peer just send information
>> to the sppliter about the chunks received and who send them.
>>
>> Best,
>>
>> Leo
>>
>>
>>
>> El lun, 01-06-2015 a las 00:51 +0500, Ilshat Shakirov escribió:
>>
>> Hello!,
>>
>>
>>  Here is the post about results of the first week:
>> http://shakirov-dev.blogspot.ru/2015/05/the-first-week.html
>>
>>
>>  Im currently in progress in preparing the plan of testing, I will
>> suggest the first version of it by the end of the second week.
>>
>>
>>  Thanks!
>>
>>
>>  2015-05-25 16:40 GMT+05:00 Ilshat Shakirov <im.shakirov@xxxxxxxxx>:
>>
>>  Hello!,
>>
>>
>>   I have just implemented and tested malicous peer, which simply sends
>> zero chunk to the rest of team. Here it is.
>> <https://github.com/P2PSP/p2psp/compare/master...ishakirov:master>
>>
>>  Yes, that's the first step, sending poisoned chunk to the rest. But
>> malicious peer is supposed to be smart, trying to avoid policies or
>> colluding with others...
>> In any case, STrPe-DS is more interesting in a real scenario.
>>
>>   Ok, so I will try to implement STrPe as soon as possible, and start to
>> implement STrPe-DS  with smart malicious peer. I think I should implement
>> bad-mouth and selective attacks, is it enough?
>>
>>  I use Linux.
>>
>>   The problem was solved on its own, so I can test everything in local
>> team. Thanks =)
>>
>>
>>
>>
>>   2015-05-25 16:28 GMT+05:00 L.G.Casado <leo@xxxxxx>:
>>
>>   Dear all,
>> El lun, 25-05-2015 a las 14:13 +0500, Ilshat Shakirov escribió:
>>
>>  Malicious peers will be smart and they can perform different types of
>> attacks.
>> Keep in main that the goal  is to check the efficiency of  STrPe and
>> STrPe-DS against those type of attacks.
>>
>> The first step is to implement STrPe. I think that the malicious peer
>> which will just send poisoned chunk (000..00) is enough for evaluating
>> STrPe. (am I right?)
>>
>> Yes, that's the first step, sending poisoned chunk to the rest. But
>> malicious peer is supposed to be smart, trying to avoid policies or
>> colluding with others...
>> In any case, STrPe-DS is more interesting in a real scenario.
>>
>>
>>  We have to agree about what experiments (number of malicious peers, type
>> of attacks, etc) are needed to check the results and your code.
>>
>> It's ok. I will prepare plan asap.
>>
>> Thanks.
>>
>>  It is rare the system go down for 5-10 sec. What is the environment you
>> are checking it?
>>
>> MacOS (yosemite); I run splitter, monitor and peer. When system is going
>> to down, the vlc out the error messages like *can't decode timestamp.
>> But it occurs from time to time, ie today morning all was ok =) And I
>> just check it again, all was ok.
>>
>> I use Linux.
>>
>> Best,
>>
>> Leo
>>
>>
>>
>>
>>
>>
>