4 ms·

> Skimming over the code it seems like it's doing fairly egregious bittorrent spec violations. It's true and even understated: magneticod is not only selfish b

> Skimming over the code it seems like it's doing fairly egregious bittorrent spec violations. It's true and even understated: magneticod is not only selfish but also incredibly aggressive. It will literally contact a thousand (and if your network allows, even more) nodes every single second and deceive them by forging thousands of ids to create the impression that it is "very close" (in terms of XOR-distance used in DHT Kademlia) to the every single node. Please have a look at this website (although it is a bit old): https://dsn.tm.kit.edu/english/2936.php https://dsn.tm.kit.edu/english/2936.php There are on average 7,000,000 DHT peers in the network and less than a quarter of the nodes stay longer than 12 hours in the network (i.e. the node you contacted this morning might be long gone at the evening). There are quite a few public papers[0] describing various Sybil-attacks on BitTorrent DHT, so it's not something unknown. BEP 42[1] tries to mitigate the issue by making node IDs dependent on the IP address of the node, but as far as I know not many clients (if any) implements it. I spoke too much but one last point: These attacks -given the scale of BitTorrent DHT- I doubt to be disruptive, but they are more dangerous for the privacy of the peers. One can gather thousands of IP addresses each day as easily using the same technique. (See http://opentracker.blog.h3q.com/2007/02/12/perfect-deniability/ http://opentracker.blog.h3q.com/2007/02/12/perfect-deniabili...) [0]: https://www.usenix.org/legacy/event/woot10/tech/full_papers/Wolchok.pdf https://www.usenix.org/legacy/event/woot10/tech/full_papers/... [1]: http://www.bittorrent.org/beps/bep_0042.html http://www.bittorrent.org/beps/bep_0042.html

the8472 10y ago
I'm not sure what you're trying to argue here. That it's ok to misbehave because there are papers describing how to do it? That it's ok to be selfish because there are enough compliant nodes to compensate for it?
- yebyen 10y ago
  I didn't see anything about "OK" -- it says attacks, right there in the comment. I think "Please Read this" is for magnetico author, or for potentially benevolent PR submitter.
  - the8472 10y ago
    > is for magnetico author Going by the username and github account he is the author.
    - boramalper 10y ago
      I am.
- boramalper 10y ago
  > That it's ok to be selfish because there are enough compliant nodes to compensate for it? Yes. Of course, I do not have data nor the foresight to claim that its short or long term effects are negligible, but I really doubt if it's not the case. > That it's ok to misbehave because there are papers describing how to do it? Not because of that, but I was pointing out that the technique is nothing new, and probably numerous real attacks of much greater scale (with the intention of actually disrupting the network) using the same techniques must have been launched many times before magnetico. If BitTorrent DHT survived those, surely it is more resilient than you tend to think. ---- I would love to hear the opinion of a BitTorrent developer though. I'll try to e-mail them tonight and ask for their opinion. =)
  - the8472 10y ago
    > Yes. Of course, I do not have data nor the foresight to claim that its short or long term effects are negligible, but I really doubt if it's not the case. And what if people see your solution and try to build an end-user thing out of it so that millions of users could run it at home? When building something in a P2P network you always should consider whether it would still work if the majority of the network behaved like that. > If BitTorrent DHT survived those, surely it is more resilient than you tend to think. Yes, the rain forest is also quite resilient. Nothing wrong with logging a few more trees, right? I'm saying your kind of reasoning is responsible for tragedy of the commons outcomes. You're not even trying to make your nodes a good citizen in the network because "others do it too". -- Anyway, such behavior can be detected and if it becomes more common other clients will probably implement blacklisting for it.
    - boramalper 10y ago
      > DHT indexing already is possible and done in practice by passively observing get_peers queries. But that approach is inefficient, favoring indexers with lots of unique IP addresses at their disposal. It also incentivizes bad behavior such as spoofing node IDs and attempting to pollute other nodes' routing tables. Source: DHT Infohash Indexing < http://www.bittorrent.org/beps/bep_0051.html http://www.bittorrent.org/beps/bep_0051.html > Figurative speech aside, bittorrent.org acknowledges the need & the issue, and calls it bad, not "egregious". The paper[0] mentioned in the BEP 51 proposal describes more or less how magnetico works ("horizontal attack") and states in conclusion that > Through an extensive measurement study since December 2010, we have identified that both of these attacks are happening in the real network. We have analyzed their exact behavior through honeypots and have shown the scale of the on-going activities. We must stress that we have no concrete proof of actual malicious activities; our work only shows that the scale of attacks is large enough for this to be a concern. Repeating for the last time (as I feel this slowly creeps into a flame war): 1. As I have said, these technique is already in use. This means that the network is more resilient than you claim and the chances that a few hundred (or thousand, in future) magnetico instances will harm the network is near zero. I could answer in a more direct way if you did not use rain forest metaphor and addressed the issues you see more directly. 2. magnetico uses a similar but also a lot different technique. The horizontal (Sybil) attack requires the offending node to maintain its identity: "First, the attacker only has to answer two types of messages, `PING` and `FIND_NODE`; he can ignore every other message."[0] magneticod, in contrast, answers only `GET_PEERS` and `ANNOUNCE_PEER` queries, which are essential for the remote node to register itself as a peer downloading the torrent. magneticod will send hundreds of `FIND_NODE` queries per second[1] using forged node IDs, and that's all! According to the BitTorrent DHT protocol[2], "after 15 minutes of inactivity, a node becomes questionable." Hence, presumably, magneticod should be forgotten & removed from the routing table after it does not answer several `PING` queries. Consider that `FIND_NODE` queries that magnetico makes are targetting (at every single time) totally random nodes, so same set of nodes will not be targeted ever (statistically speaking). The problem is, BEP 51 is still a draft and AFAIK no clients in the wild implements it, so it's simply impractical to write a DHT search-engine depending on this particular behaviour. Once it becomes more widespread (hopefully together with BEP 42), magnetico will (and has to) drop its current technique and support the new and proper one. [0]: https://www.cl.cam.ac.uk/~lw525/publications/security.pdf https://www.cl.cam.ac.uk/~lw525/publications/security.pdf [1]: https://github.com/boramalper/magnetico/blob/257912a12f862d9f4ca3c5970df57f3a62d29c66/magneticod/magneticod/dht.py#L225 https://github.com/boramalper/magnetico/blob/257912a12f862d9... [2]: http://www.bittorrent.org/beps/bep_0005.html http://www.bittorrent.org/beps/bep_0005.html

the8472 10y ago

I'm not sure what you're trying to argue here. That it's ok to misbehave because there are papers describing how to do it? That it's ok to be selfish because there are enough compliant nodes to compensate for it?

yebyen 10y ago
I didn't see anything about "OK" -- it says attacks, right there in the comment. I think "Please Read this" is for magnetico author, or for potentially benevolent PR submitter.
- the8472 10y ago
  > is for magnetico author Going by the username and github account he is the author.
  - boramalper 10y ago
    I am.
boramalper 10y ago
> That it's ok to be selfish because there are enough compliant nodes to compensate for it? Yes. Of course, I do not have data nor the foresight to claim that its short or long term effects are negligible, but I really doubt if it's not the case. > That it's ok to misbehave because there are papers describing how to do it? Not because of that, but I was pointing out that the technique is nothing new, and probably numerous real attacks of much greater scale (with the intention of actually disrupting the network) using the same techniques must have been launched many times before magnetico. If BitTorrent DHT survived those, surely it is more resilient than you tend to think. ---- I would love to hear the opinion of a BitTorrent developer though. I'll try to e-mail them tonight and ask for their opinion. =)
- the8472 10y ago
  > Yes. Of course, I do not have data nor the foresight to claim that its short or long term effects are negligible, but I really doubt if it's not the case. And what if people see your solution and try to build an end-user thing out of it so that millions of users could run it at home? When building something in a P2P network you always should consider whether it would still work if the majority of the network behaved like that. > If BitTorrent DHT survived those, surely it is more resilient than you tend to think. Yes, the rain forest is also quite resilient. Nothing wrong with logging a few more trees, right? I'm saying your kind of reasoning is responsible for tragedy of the commons outcomes. You're not even trying to make your nodes a good citizen in the network because "others do it too". -- Anyway, such behavior can be detected and if it becomes more common other clients will probably implement blacklisting for it.
  - boramalper 10y ago
    > DHT indexing already is possible and done in practice by passively observing get_peers queries. But that approach is inefficient, favoring indexers with lots of unique IP addresses at their disposal. It also incentivizes bad behavior such as spoofing node IDs and attempting to pollute other nodes' routing tables. Source: DHT Infohash Indexing < http://www.bittorrent.org/beps/bep_0051.html http://www.bittorrent.org/beps/bep_0051.html > Figurative speech aside, bittorrent.org acknowledges the need & the issue, and calls it bad, not "egregious". The paper[0] mentioned in the BEP 51 proposal describes more or less how magnetico works ("horizontal attack") and states in conclusion that > Through an extensive measurement study since December 2010, we have identified that both of these attacks are happening in the real network. We have analyzed their exact behavior through honeypots and have shown the scale of the on-going activities. We must stress that we have no concrete proof of actual malicious activities; our work only shows that the scale of attacks is large enough for this to be a concern. Repeating for the last time (as I feel this slowly creeps into a flame war): 1. As I have said, these technique is already in use. This means that the network is more resilient than you claim and the chances that a few hundred (or thousand, in future) magnetico instances will harm the network is near zero. I could answer in a more direct way if you did not use rain forest metaphor and addressed the issues you see more directly. 2. magnetico uses a similar but also a lot different technique. The horizontal (Sybil) attack requires the offending node to maintain its identity: "First, the attacker only has to answer two types of messages, `PING` and `FIND_NODE`; he can ignore every other message."[0] magneticod, in contrast, answers only `GET_PEERS` and `ANNOUNCE_PEER` queries, which are essential for the remote node to register itself as a peer downloading the torrent. magneticod will send hundreds of `FIND_NODE` queries per second[1] using forged node IDs, and that's all! According to the BitTorrent DHT protocol[2], "after 15 minutes of inactivity, a node becomes questionable." Hence, presumably, magneticod should be forgotten & removed from the routing table after it does not answer several `PING` queries. Consider that `FIND_NODE` queries that magnetico makes are targetting (at every single time) totally random nodes, so same set of nodes will not be targeted ever (statistically speaking). The problem is, BEP 51 is still a draft and AFAIK no clients in the wild implements it, so it's simply impractical to write a DHT search-engine depending on this particular behaviour. Once it becomes more widespread (hopefully together with BEP 42), magnetico will (and has to) drop its current technique and support the new and proper one. [0]: https://www.cl.cam.ac.uk/~lw525/publications/security.pdf https://www.cl.cam.ac.uk/~lw525/publications/security.pdf [1]: https://github.com/boramalper/magnetico/blob/257912a12f862d9f4ca3c5970df57f3a62d29c66/magneticod/magneticod/dht.py#L225 https://github.com/boramalper/magnetico/blob/257912a12f862d9... [2]: http://www.bittorrent.org/beps/bep_0005.html http://www.bittorrent.org/beps/bep_0005.html