By the way you can pull-request the test scripts too! Juan
2015-08-03 23:01 GMT+02:00 Juan Álvaro Muñoz Naranjo <[email protected] >: > Man this is really interesting, thanks for sharing. I hope Leo can review > them too. > > One remarkable result here is the fact that having a second trusted peer > does not have a real impact on malicious peer expulsion. I realize now that > this is due to how the Str technique is designed. Not for GSoC, but maybe > we should think of a evolution of the protocol that reflected the > aggregation of trusted peers. Cristóbal, that might be intersting if it has > not been researched yet. > > In light of this, can I ask you to run another couple of experiments with > more trusted peers? Say 4 and 8, and see what happens... I just want to > confirm that adding those peers does not accelerate malicious peer > expulsion. > > Also, could you run an experiment in which malicious peers kept entering > the team? I mean, in a real environment an adversary would not give up so > easily since when computational resources are cheap (by cheap I mean that > you can launch a lot from a single machine, or you can create a botnet by > infecting other people's machines and use that botnet to attack the team). > In that situation the best possible result would be to keep expulsing > enough adversaries per iteration so that the quality of the stream is > enough to be played back. > > Very good work Ilya ;) (see below, I reply inline) > > To be honest, I dont see how splitter can determine malicious peers if >>> there more than 50% of malicious peers in the team. Could you please advice >>> some direction? >>> >>> My feeling is that we can only maintain control of the team if the > number of peers is below 50%, as you say. Cristóbal, I think this is an > interesting result to prove with a theorem. > > Juan > > > >> Thanks! >>> >>> >>> 2015-07-28 12:36 GMT+05:00 L.G.Casado <[email protected]>: >>> >>>> Dear ILshat, >>>> >>>> Your reputation system, as many others, may produce false positive and >>>> false negative. >>>> >>>> False positive: a bunch of malicious peers complaint about a well >>>> intended one. >>>> False negative: a bunch of malicious peers does not complain about a >>>> malicious peer. >>>> >>>> About time on the team: a malicious peer can perform correctly for a >>>> long period and suddenly make an attack. >>>> >>>> It is not an easy task. >>>> >>>> Best, >>>> >>>> Leo >>>> >>>> >>>> >>>> El mar, 28-07-2015 a las 12:00 +0500, Ilshat Shakirov escribió: >>>> >>>> As I said we can assign some reputation parameter to each peer. Let's >>>> say that we exclude peer P from the team if Q > X, where X some threshold >>>> value and >>>> >>>> where I_i = 1 if i-th peer marked peer P as malicious and 0 in the >>>> other case. >>>> w_i can be assigned by the time of existing peer in the team. So if >>>> peer exists in team from the start of streaming, and it hasn't complaints >>>> from the other peers, it has the maximum reputation value (w_i parameter). >>>> So the question is how to choose w_i more optimal (and the threshold >>>> value X respectively). >>>> >>>> 2015-07-28 1:08 GMT+05:00 Juan Álvaro Muñoz Naranjo < >>>> [email protected]>: >>>> >>>> Hi again, >>>> >>>> Also, I wanted to develop heuristic for the excluding malicious peers >>>> from the team based on the all the team (not only trusted peers). Do you >>>> have any ideas? I think about smth like: 'exclude peer if more than x% of >>>> the team marked it as malicious'. Also, we can assign 'reputation' to each >>>> peer, so some peers will have more influence on the decision of excluding >>>> peer. What do you think? >>>> >>>> >>>> >>>> >>>> Yeah, we've been considering it. The problem with the x% solution is >>>> that i can easily turn against us. Imagine the attacker controls a high >>>> percentage of the nodes in the network (that would be easy, just run a huge >>>> number of peers > x% in a small number of machines and you've got it) and >>>> starts complaining against valid peers. The valid peers would be expulsed >>>> by the splitter. That would be an easy DoS. >>>> >>>> So, to reduce the impact of attackers, let's say that we set x to 50%: >>>> the attacker would need to control more than half of the team in order to >>>> expulse someone. But let's say the attacker controls 45% of the peers. Not >>>> enough to expulse anyone, but now he can act inversely: he uses that 45% of >>>> malicious peers to send corrupted chunks to a set of peers smaller than >>>> 50%. Those affected legal peers will not be able to play 45% of the >>>> packets, so they will probably abandon the team due to playback quality >>>> problems. Again a DoS. And the attackers will not be expulsed since the >>>> splitter did not receive at least 50% of complaints! >>>> >>>> Any idea on this? >>>> >>>> Juan >>>> >>>> >>>> >>>> Thanks! =) >>>> >>>> >>>> 2015-07-23 2:01 GMT+05:00 Juan Álvaro Muñoz Naranjo < >>>> [email protected]>: >>>> >>>> Hi Ilshat, >>>> >>>> first of all thanks for your update, it was very interesting. Just one >>>> thing: when the DS technique is completed we'll send the public key under a >>>> X.509 certificate format. Ideally this certificate should be signed by a >>>> trusted certificate authority and contain information about the >>>> organization managing the splitter to offer some degree of trust. The >>>> certificate might even be distributed with the software, or be given by the >>>> web page if we were in a web player with WebRTC. Otherwise the attacker >>>> might send its own public key to the peers impersonating the splitter. But >>>> for now it is ok like that. >>>> >>>> Now, let's get to the point. How to run the experiments. Vicente >>>> already suggested the use of tools/create_a_team.sh in a previous message >>>> (thank you Vicente!). Also, Cristóbal suggests this: >>>> https://github.com/cristobalmedinalopez/p2psp-chunk-scheduling/blob/master/tools/run_experiment.sh >>>> These solutions are for experiments in one machine of course, which is >>>> enough for us. If you need more peers you should be able to combine several >>>> machines by running one script per machine. Of course, we're interested in >>>> seeing how peers' buffers are filled with chunks and not in video playback: >>>> as you can see, both scripts send the video signal to /dev/null. >>>> >>>> Which experiment to run? We propose the following: we're interested in >>>> average expulsion times for an attacker, and if all of them are expulsed >>>> after a given time. Also, the average percentage of gaps in the peers' >>>> buffers (so we can see if playback is possible in presence of attackers and >>>> after how long). I think you should measure time in terms of sending rounds >>>> (you know, one round would be the splitter sending one chunk to every >>>> member of the team). >>>> >>>> So, let's say that you have a team of 100 peers. From that team, a >>>> percentage of peers will be malicious: 1%, 10%, 25%, 50%. I imagine a plot >>>> in which the X axis is time (number of rounds) and in which we depict: >>>> number of remaining malicious peers in the team (because some of them will >>>> be expulsed) and average filling of peers' buffers. Ideally, as the number >>>> of remaining malicious peers decreases the filling of buffers should >>>> increase. >>>> >>>> Showing the number of complains from peers in the first technique would >>>> be also interesting. >>>> >>>> Another thing to measure would be the percentage of bandwidth used for >>>> real multimedia data (this is, how many bytes from the total are really >>>> used for transmitting the video). You can compare the baseline (no security >>>> measures, just plain video without malicious attackers) against both >>>> techniques. >>>> >>>> So, for running these experiments you'll need to decide which >>>> information you want to store from each peer (buffer filling percentage at >>>> each iteration, how many malicious peers at each iteration, how many bytes >>>> were sent and how many of them were used for video, how many complains >>>> arrived to the splitter in every iteration). Am I forgetting anything? >>>> >>>> My suggestion is run the experiment for the first technique and see how >>>> it goes. Make sure to run the experiment more than once, say 5 times, and >>>> then get the average of them all. >>>> >>>> Good work, >>>> >>>> Juan >>>> >>>> 2015-07-21 20:06 GMT+02:00 Vicente Gonzalez < >>>> [email protected]>: >>>> >>>> Hi Ilshat, >>>> >>>> did you try tools/create_a_team.sh? >>>> >>>> (I tested to run up to 100 peers in my 8HG Mac machine) >>>> >>>> Regards, >>>> Vi. >>>> >>>> >>>> On Sun, Jul 19, 2015 at 8:36 PM Ilshat Shakirov <[email protected]> >>>> wrote: >>>> >>>> Hello!, >>>> >>>> Sorry for the long delay. >>>> >>>> Here is status update about CIS of rules project: >>>> http://shakirov-dev.blogspot.ru/2015/07/5-6-7-week.html >>>> >>>> Also, I need some help with testing a big (ie, 20 peers) p2psp-teams. I >>>> want solution that allows to reproduce testing experiments easily. So the >>>> commenting lines (to remove need in running vlc) is not suitable for this. >>>> I've wrote simple script which runs several peers (in one machine) and >>>> here is result >>>> <https://www.evernote.com/shard/s427/sh/0b070670-8de9-4a61-acec-562035cfc3ef/7403917d3ca736eea6d60da8ba23543b>. >>>> I think it's quite hard to understand smth in this (and reproduce). So, >>>> what is the best solution for testing p2psp-teams and gather some stats? >>>> >>>> Thanks! >>>> >>>> 2015-06-25 16:13 GMT+05:00 Vicente Gonzalez < >>>> [email protected]>: >>>> >>>> >>>> >>>> On Wed, Jun 24, 2015 at 5:48 PM L.G.Casado <[email protected]> wrote: >>>> >>>> Hi all, >>>> >>>> El mié, 24-06-2015 a las 16:44 +0500, Ilshat Shakirov escribió: >>>> >>>> Ok; Is there any option run peer without running a player? I'm going to >>>> run all peers in one local machine, is it right? >>>> >>>> >>>> >>>> >>>> At this moment, the easiest way to test a lot of peers in one machine >>>> is to connect to each peer a NetCat client [ >>>> http://netcat.sourceforge.net/]. It is not the most efficient >>>> solution, but you should be able to run hundreds of peers in a 8GB machine. >>>> However, is quite simple to avoid sending the stream in each peer. Just >>>> comment (temporally) the code that feeds the player. >>>> >>>> Regards, >>>> Vi. >>>> -- >>>> -- >>>> Vicente González Ruiz >>>> Depto de Informática >>>> Escuela Técnica Superior de Ingeniería >>>> Universidad de Almería >>>> >>>> Carretera Sacramento S/N >>>> 04120, La Cañada de San Urbano >>>> Almería, España >>>> >>>> e-mail: [email protected] >>>> http://www.ual.es/~vruiz >>>> tel: +34 950 015711 >>>> fax: +34 950 015486 >>>> >>>> >>>> >>>> -- >>>> -- >>>> Vicente González Ruiz >>>> Depto de Informática >>>> Escuela Técnica Superior de Ingeniería >>>> Universidad de Almería >>>> >>>> Carretera Sacramento S/N >>>> 04120, La Cañada de San Urbano >>>> Almería, España >>>> >>>> e-mail: [email protected] >>>> http://www.ual.es/~vruiz >>>> tel: +34 950 015711 >>>> fax: +34 950 015486 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Mailing list: https://launchpad.net/~p2psp >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~p2psp >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> -- >>> Mailing list: https://launchpad.net/~p2psp >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~p2psp >>> More help : https://help.launchpad.net/ListHelp >>> >> -- >> -- >> Vicente González Ruiz >> Depto de Informática >> Escuela Técnica Superior de Ingeniería >> Universidad de Almería >> >> Carretera Sacramento S/N >> 04120, La Cañada de San Urbano >> Almería, España >> >> e-mail: [email protected] >> http://www.ual.es/~vruiz >> tel: +34 950 015711 >> fax: +34 950 015486 >> >> -- >> Mailing list: https://launchpad.net/~p2psp >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~p2psp >> More help : https://help.launchpad.net/ListHelp >> >> >
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
