Hoi Frans,
Quote:
it occured to me that when implemented this widely anyone could go around crawling through gnutella and direct a distributed denial of service attack on any server on the net.
...
X-Host: 123.1.2.3:80
...
|
You're right. It has been implemented on a small, non-public scale only, so thank goodness for that. But someone could indeed create false requests which could lead to a DDoS.
Solution A, just sending the port (as the receiver can detect the IP by itself) seems most suitable in this case. The reason for a callback instead of keeping the port open is that the QUEUE (no emphasis) is used when a client is out of upload sockets. That indicates a limit set by either the end-user or as a precautionary limit on non-server operating systems like Windows 9x and Windows ME (which have terrible time opening and maintaining many socket connections).
I'd like to point out that with the introduction of a file mesh based on the HUGE proposal, the QUEUE will have a less important role. Nonetheless, it still has a good use so carefully examining all issues is a must. Thanks for pointing this important one out.
There have been several discussion about resolving an ID (similar to the ClientID [a GUID]) to an IP address, almost acting like an alternative to a DynDNS-like domain name (like DNS2GO, TZO), so an IP does not need to be transmitted at all times. However, in its current proposed form it could also cause a similar DDoS attack.
I'm glad you pointed this out, and it should have been obvious. There are a number of other areas in Gnutella that need to be addressed as well, but solutions are not always as easy to find as they may seem. I hope more people come forward in improving the vulnerabilites in Gnutella
Thanks again!