p2psp team mailing list archive

["L.G.Casado" <leo@xxxxxx>]

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 <
> juanalvaro83@xxxxxxxxx>:
> > 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 <
> > > > > juanalvaro83@xxxxxxxxx>:
> > > > > > 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/p2ps
> > > > > > p-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 <
> > > > > > vicente.gonzalez.ruiz@xxxxxxxxx>:
> > > > > > > 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 <
> > > > > > > im.shakirov@xxxxxxxxx> 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. 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 <
> > > > > > > > vicente.gonzalez.ruiz@xxxxxxxxx>:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On Wed, Jun 24, 2015 at 5:48 PM L.G.Casado <
> > > > > > > > > leo@xxxxxx> 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: vruiz@xxxxxx
> > > > > > > > > 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: vruiz@xxxxxx
> > > > > > > http://www.ual.es/~vruiz
> > > > > > > tel: +34 950 015711
> > > > > > > fax: +34 950 015486
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> -- 
> Mailing list: https://launchpad.net/~p2psp
> Post to     : p2psp@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~p2psp
> More help   : https://help.launchpad.net/ListHelp