[netfinity]

When doing a search for a popular keyword, you will naturaly get a lot results. In order to avoid fragmentation eMule limits the number of results to 50 in each response packet. If there is more results, those will be sent in separate packets.

Now it turns out that if the search returns file descriptions, we may easily end up with fragmented IP packets. This is because a file description result is around 100 bytes (estimated with ethereal traces) each and 50 of them gives around 5 kB of data. With a compression of 30 - 50 % (estimated with ethereal traces) this gives us a packet size of 2500 - 3500 bytes wich is greater than the MTU size of 1500 bytes. Result is that each packet containing file description results will be split in atleast two IP packets.

My suggestion is that instead of using a fixed limit of 50 results, force a send when the bytes in the packet exceed the MTU when a 40% compression ratio assumed.

Eg.

...
uint32 uLen = sizeof(byPacket)-byIO.GetAvailable();
if (uLen + 100 > 2500)
{
    ...
    CKademlia::GetUDPListener()->SendPacket(byPacket, uLen, uIP, uPort);
    ...
}
...

/netfinity

[elboiler]

Hi! I just would like to say that packet fragmentation in Kad searches is true. So I searched here and found this topic.

I use Jetico as firewall. It has a rule which "deny (denies) all fragmented packets". This rule makes kad searches results almost to zero. Disabling that rule in Jetico, kad searches are great and very fast.
Jetico can log every time that a fragmented packet is received... if you need more information (log entries), just ask.

So... ehm... I'm not a skilled programmer, sorry I can't really help you... just want to say that you may take care of that issue and try to solve it in next eMule version, please. Could be Netfinity's suggestion a good one?

Thanks
Bye

This post has been edited by elboiler: 29 July 2006 - 12:16 AM

[Kry]

Sorry to say it, but denying fragmented packets is so wrong. SO wrong.

[Haos]

As i know Jetico, nothing s there without the purpose. Possibly some exploit based on packet fragmentation.

[Enig123]

Look'n'Stop also blocked many fragmented UDP packets when kad is on. Is it possible to do something on emule side to avoid generating fragmented packets?

[DavidXanatos]

For what reason do firewalls blcok fragmented packets, where is the danger in such?

David

[netfinity]

Most probably the firewall blocks them because it has to keep track of what fragments are linked as there is no UDP or TCP header in the fragmented packets which is needed to route the packets properly if it's a NAT.

Possibly, you could make a DOS attack by generating a lot of fake fragments that the receiver has to queue til all fragments of the packet has been received which never happen's as the bad guy had made sure of that.

/netfinity

[Haos]

I dunno if that`s the problem, but somewhere i heard about the exploit to craft a packet looking like a harmless one (possibly fragmented) to make it bypass the firewalls. It is as a info return channel from a trojan client.

[leuk_he]

Just google for fragmented udp and you understand why some choose to block it:

http://www.security....ocument397.html

and the teardrop DOS attack is alos based on fragmented (udp) packets.

It is just not good idea to block ALL fragmented udp packets as those firewalls do.

[netfinity]

Could be that simple that some NATs just don't have the necessary code to route fragmented packets. In order for a NAT to route a packet it doesn't just need the IP address but also the destination port number. This port number is in the TCP/UDP header which is only present in the first fragment, so if the NAT doesn't keep track of fragment headers it will only be able to route the first fragment but not the remainder.

This is cheap but normally fragmented packets are uncommon and might have been considered neglectable.

/netfinity

[kubba]

any statefull firewall/nat can cope with fragmented packets, droping any suspicious traffic.

[LorenzoC]

Jetico PF log (by default the rule is set on "reject", this is "accept"):
You can see the data splitted in 3 packets.
-----------------------------------------
20/08/2006 22:17:48.500 accept Allow All Fragmented Packets 1500 UDP incoming packet xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx 4672 5072 TTL: 118; TOS: 0; ID: B933; Frag offset: 0
20/08/2006 22:17:48.510 accept Allow All Fragmented Packets 1500 UDP incoming packet xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx TTL: 118; TOS: 0; ID: B933; Frag offset: 185
20/08/2006 22:17:48.510 accept Allow All Fragmented Packets 466 UDP incoming packet xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx TTL: 118; TOS: 0; ID: B933; Frag offset: 370 (last)
------------------------------------------
This happens when you make a search that gets many results with long description (es. "britney"), as said by Netfinity. I don't know how I could make a restrictive rule to allow emule only since the information about the KAD port is includes only in the first packet. There are the remote and local IPs but It is not useful for emule.

This post has been edited by LorenzoC: 20 August 2006 - 08:51 PM

[Haos]

Jetico solves application rules before system rules, so if you`ll make an app rule, allowing fragmented packets in a ruleset directory, then forward only emule traffic (from Ask user directory) to this rule directory, it should be restrictive enough as well as allow fragmented packets to emule client.

It should work, but i`d have to check it to be sure...

[LorenzoC]

I've studied Jetico for a while but I don't understand how to make it.
Application rules don't tell anything about fragments, so I can't connect "emule" to fragments.

It must be a System IP rule and they are allowed only inside the System IP Table. Then I can't connect Emule to fragments either, the IP could work but Emule needs "any - any". The port works only for the first fragment.

Now I've created a new IP rule in the System IP Table above the standard "reject" rule
That allowes UDP fragments, while the reject rule denies any protocol.

This post has been edited by LorenzoC: 21 August 2006 - 06:09 PM

[tHeWiZaRdOfDoS]

I want to push this topic.

Implementing such a workaround isn't much work but will help a lot of users who don't know why they aren't getting any search results off KAD and are instead posting here.

[CiccioBastardo]

Those fragmetned packets, however, use all the available payload, do they are more efficient than guessing the packet size. Which could still be wrong and bring to a fragmented packet.