|
Reduce Useless Overhead Don't put firewalled nodes in the routing table
Group: Members Posts: 1658 Joined: 23-April 04
Posted 08 October 2007 - 07:28 PM
I've noticed, when putting my eMule behind a NAT on a non forwarded port, that other KAD nodes tries to send KADEMLIA_HELLO_REQ requests aswell as KADEMLIA_REQ packets towards my NAT'ed port. Unfortunatly most of those packets get dropped as they don't come from an IP address that I did recently contact.
eMule v0.50a [NetF WARP v0.3a] 0
Group: Members Posts: 1658 Joined: 23-April 04
Posted 15 June 2008 - 09:07 PM
Bumping this thread as eMule still sends KADEMLIA2_HELLO_REQs while being Firewalled. Althought this doesn't really pose any problem for the client sending them it causes firewalled contacts to pop in and out of the routing tables and being returned in search requests coming from other clients. So, bandwidth is wasted by clients trying to contact this firewalled node as they can't get throught.
eMule v0.50a [NetF WARP v0.3a] 0
Group: Yes Posts: 3669 Joined: 27-June 03
Posted 15 June 2008 - 09:20 PM
Sending KADEMLIA2_HELLO_REQ while beeing UDP firewalled is fine imho (without looking closer at it right now), as the Firewalled client should still build up its own routing table, which is needed for search/source requests. However now that the UDP state is explicit checked we should probably tell the remote node about it so that it can act properly (so not adding the firewalled node to its own routing table).
Group: Members Posts: 1658 Joined: 23-April 04
Posted 15 June 2008 - 10:08 PM
True that they need to build the routing tables, however they should get all the information they need throught the use of KADEMLIA2_REQ. But yes adding a 'Firewalled' tag to the hello packets would do the job once the majority of the clients start supporting this tag. (actually thought suggesting that)
eMule v0.50a [NetF WARP v0.3a] 0
Group: Yes Posts: 3669 Joined: 27-June 03
Posted 15 June 2008 - 10:41 PM
Quote True that they need to build the routing tables, however they should get all the information they need throught the use of KADEMLIA2_REQ. Results obtained from KADEMLIA2_REQ cannot be trusted before they are checked to be alive and valid. This is one of Kads security "features" as it makes sure that bad nodes cannot injected and spread (what happens if this fails could be seen on the DNS injection you found
Group: Members Posts: 1658 Joined: 23-April 04
Posted 15 June 2008 - 11:17 PM
The suggestion of using the PING/PONG opcodes was primarily because it was already there so there wouldn't be any need to change the protocol then. I didn't think the integrity of the routing tables of firewalled clients would be of much problem as it would only be used for boot strapping search queries and would not spread to other nodes.
eMule v0.50a [NetF WARP v0.3a] 0
Group: Yes Posts: 3669 Joined: 27-June 03
Posted 16 June 2008 - 12:40 AM
Quote I didn't think the integrity of the routing tables of firewalled clients would be of much problem as it would only be used for boot strapping search queries and would not spread to other nodes. Well, the aim is to have a all nodes beein resistant against injection (and other attacks of course). With a bad routing table kad will just not work properly (or worse). Also as we need to check regulary anyway and a Hello Handshake isn'T much mroe traffic than the ping, it is the safe way to go
The advantage of your proposal is that its effects would spread faster through the network as less nodes need to update to make it work as intended. But given that it was this way for years and that the security loss would be significant enough (imho), i still prefer the tag/flag based solution.
Btw, did you look at my other suggestion about providing information already in the KADEMLIA(2)_RES packet wether it is any point performing a STORE/GET towards the contact responding. Yes but i'm not sure about this yet. I do like to keep the protocol "clean" in the way that each packet does excactly what it is supposed todo, and a Kad_Req search is supposed to find other nodes close to a given ID and not to check if you have keywords, notes, sources or future stuff stored about this key. I admit it might save some traffic, but not that much that its a must have. So I will see.. as i said not sure yet. (责任编辑：) |
