Official eMule-Board: Housekeeping In The Routing Tables - Official eMule-Board

Jump to content


Page 1 of 1

Housekeeping In The Routing Tables A few thoughts

#1 User is offline   Nissenice 

  • clippetty-clopping...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 4231
  • Joined: 05-January 06

Posted 24 September 2011 - 10:55 AM

Something I've had in mind for a looong time. To make use of the fact that when the Kad-part of eMule is running, most often also the eMule's file-sharing part is running as well:

How about trying to add peers to the routing bins which are both running Kad and with whom there is or has been an exchanging of files? The larger the size of exchanged files the better it is and best if the exchanging goes in both directions.

This would, I belive, make it practically impossible for an attacker to completely fill up a routing table with adversary nodes. Well, if one exclude the fact that faked files could be shared from an adversary peer also running an adversary node as well. Plus the fact that some peers may downlad such files. But even so this would be a challenge, a war between computer resources.

This would most likely have no effect on bins with contacts close to our own KadID, as the likelihood that two peers are both sharing files and both having their KadID's close to each other is almost zero. But as the distance grows, especially outside of the tolerance zone, the probability to find such a contact would increase.

:)

This post has been edited by Nissenice: 13 December 2011 - 10:08 PM

0

#2 User is offline   Nissenice 

  • clippetty-clopping...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 4231
  • Joined: 05-January 06

Posted 13 December 2011 - 10:10 PM

Changed the topic title from "Add Known Clients To Contacts List".



Hi

After the client has been up running for a while the size of the network can fairly well be estimated. How about we use this knowledge together with other informations about the network as for example the distribution of IPs known to the client, and the expected distribution of IDs, which in the latter should be uniform, to do some housekeeping in the routing table.

IPs: At the moment there is a limit set on how many IDs which are allowed to come from IPs in the same /24 subnet. This limit is currently set to 10 and I think it is 2 for every routing bin.
After some session uptime and perhaps together with information stored from previous sessions this condition could be strengthened in the sense that whenever possible the routing table tries to replace nodes with IPs which are too close and replace some of them with other nodes from different parts of the IP space, but still would serve the same purpose as the replaced nodes.
As I've got it, nodes with IDs far away from the own clients ID, e.g. outside of the tolerance zone it belongs to, can esaily be switched with other nodes as their purpose is mainly to act as first contacts when the own client is making searches and it needs to get in touch with nodes whos IDs are close to searched targetID. While nodes with IDs close to the own ID are mainly used by other nodes when searching for a targetID close to own client's ID.
This means that the closer we got to the own client's ID the more nodes at the same distance are known to the own client
I think it's even possible to strengthen the size of the subnets even further to e.g. /22 subnets during this housekeeping.

IDs: Something similar could be done when it comes to KadIDs. If nodes with IDs unnecessary close to each other are found in the routing table, there is a replacement mechanism which tries to replace one or more randomly chosen of these contacts with other nodes which would serve their purpose in the routing table as good as the replaced ones.
As above, the farther away from the own clients KadID the more candidates there exists which can replace the nodes which are under consideration. And the closer the IDs are the less candidates could act as substitutes. The closest ones we are stuck with as it is preferrable that we have knowledge about them, because with this method it can't be judged which are good or bad. To do that other means of evaluation is needed.

So what are the advantages? Well, to pollute a routing table more resources are needed. It wouldn't help much against the ongoing Chinese node insertions attacks. But it would decrease the effect they have on other searches on IDs close to an ID they are attacking. Without increasing their resources and changing strategy when it comes to IDs they would definately suffer when it comes to the number of injected contacts in ordinary peers routing tables.

:bounce:

This post has been edited by Nissenice: 13 December 2011 - 10:17 PM

0

#3 User is offline   Nissenice 

  • clippetty-clopping...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 4231
  • Joined: 05-January 06

Posted 09 January 2012 - 11:07 PM

Ok, I just got a small idea, when struggeling with writing a post about another... :P

Peers/nodes that starts during an ongoing attack such as the Chinese one are likely to have their routing tables poisoned faster and by more attacking nodes than peers/nodes running 24/7.
The reason for this is that recently started nodes have their bins only partially filled so they are more vulnerable to direct and indirect injections, let's say during the first hour or so.
With direct injection I mean received Hello_requests from attacking nodes and by indirect I mean received Kademlia2_responses (and Hello_responses?..).
24/7 running nodes have most of their bins in the routing table already filled, except for the bins with contacts whos IDs are close to ownID.

Now, we don't have any influence on the speed with which the attackers are sending Hello_requests, for instance. But, we do have an influence on when and how often we expose ourselves to indirect injections and here comes the idea:

Assume we have a mechanism which identifies attacked IDs alternatively attacking nodes ID's, also assume that such information is stored between sessions.
Then the order of sent search_requests, publish_requests etc. could be rearranged such that if the requested ID is too close to a suspected attacked ID the request is delayed (put last in queue), so that the bins have a chance to get filled with hopefully honest contacts.

This post has been edited by Nissenice: 09 January 2012 - 11:15 PM

0

#4 User is offline   Some Support 

  • Last eMule
  • PipPipPipPipPipPipPip
  • Group: Yes
  • Posts: 3628
  • Joined: 27-June 03

Posted 10 January 2012 - 09:01 PM

I'm not sure what this should accomplish. I mean as far as I read, those attackers try to impersonate/intercept/blackhole certain IDs - a classic Kad attack. They "poison" routing table only in so far as that they deliver a lot more IDs which are closer to the target ID than legit nodes. As long as eMule cannot figure out which nodes are malicious, implements a trust system or whatever (which might not acutally be possible in the current network structure) the attacker can reach its goal if he has enough ressource (IP addresses) available. At which point we fill our routing bins doesn't really matters here, as the result stays - we cannot reach (publish, store, search) the attacked ID.

Now if there is an attack to take over nodes by completely filling their routing table with fake IDs thats something different, but this attack needs MUCH more ressources to reach a significant part of the network population.

#5 User is offline   Nissenice 

  • clippetty-clopping...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 4231
  • Joined: 05-January 06

Posted 17 January 2012 - 06:55 PM

It's true that it wouldn't accomplish anything against attacks on IDs as the ongoing attack, but that was not what I had in mind.

I was thinking of a situation where the attackers not only attacks IDs, but also attacks the peers themselves (or a subset of them) which are found to be sending search_requests to several (over a certain threshold) of the different IDs which are of interest to the attackers. Imo it would be reasonable to believe that such a peer probably shares/downloads other files which are related to files the attackers at that moment are attacking. Therefore they could choose to try attacking the source directly by injecting contacts in the peer's routing table which will affect Kad's quality of service for the peer.
And a useful way, to begin with, is to make use of the attacking nodes or their successors which the peer will encounter while publishing or searching for an attacked ID.

First, I can't say if this happening at the moment. I'm just trying to figure out what could be happening. Second, I don't know if they have the resources. I'm quite sure they have access to enough number of IPs, though.
I'm also sure they will not leave Kad alone and just go away...

If my math isn't completly off, 80 contacts in a peer's routing table covers 50% of the ID-space and 130 contacts covers 75% and therefore contacts among them acts as start for 50% respectively 75% of the searches.
I believe, at best (worst from our perspective) a third of these is needed by an attacker if it's maliscious contacts can be positioned as every third contact in a routing table ordered by distance as every search then can be hijacked if the adversery contact always presents new maliscious contacts which are closest to the searched ID. So, optimally 44 bad contacts can hijack 75% of the searches.

View PostSome Support, on 10 January 2012 - 10:01 PM, said:

Now if there is an attack to take over nodes by completely filling their routing table with fake IDs thats something different, but this attack needs MUCH more ressources to reach a significant part of the network population.

I wonder if it wouldn't be more efficient to attack a small part of the nodes in the network at a time. This would be a continuation on how the servers were attacked. Much less resources would be needed and it would be very hard for the rest of the network to detect.

This post has been edited by Nissenice: 17 January 2012 - 07:11 PM

0

#6 User is offline   Some Support 

  • Last eMule
  • PipPipPipPipPipPipPip
  • Group: Yes
  • Posts: 3628
  • Joined: 27-June 03

Posted 17 January 2012 - 09:57 PM

Quote

If my math isn't completly off, 80 contacts in a peer's routing table covers 50% of the ID-space and 130 contacts covers 75% and therefore contacts among them acts as start for 50% respectively 75% of the searches.

Not sure what you mean with those numbers. When Kads starts a search it uses some of the closest IDs it finds in the routing table for the target ID as starting point, so it depends on the number of contacts you have in your routing table how many searches will be intercepted. Depending on the kind of attack the redunant searching might hurt (ending the search with fake results) or help here. But if we ignore the redunant searching aspect, you need 50% bad nodes to intercept 50% of the searches.

Quote

I wonder if it wouldn't be more efficient to attack a small part of the nodes in the network at a time. This would be a continuation on how the servers were attacked. Much less resources would be needed and it would be very hard for the rest of the network to detect.

The point is if you attack a small part of the network with such a method, this small part might not work anymore but the rest of the network doesn't cares too much - a small number of keywords and files won't be found anymore while the attack is ongoing but all in all its not really what an attacker would want to archive. And as soon as you move on to some other ID space of the network, the other one will recover pretty fast.

  • Member Options

Page 1 of 1

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users