Glutella: Glu's throughts about Gnutella (v 0.1)
I am intelectually seduce by Gnutella concept and all the doors it open
to other developpement. Unfortunatelly, I don't have time (and time to
recover skills needed) to make my own Gnutella client. I don't even have
time to invent Gnutella the Next Generation. However, I founded the time
to read FAQs, description of the protocol, problem in the current implementation
and ideas from other on what should be done. Using my imagination, experience
and knowledge (and a little bit of time)... I think I can help by writing
down my throughts about Gnutella now and possible futur of Gnutella.
Enhanced flooding technique to avoid unecessary traffic
One of the main base for the Gnutella net to work is the flooding technique
and associate reverse routing used.
Firewall limitations and possible solutions
Can't transfer from behind a firewall to behind a firewallIt as been writen by knownbuddy the folowing:
"Servents are also smart enough to compensate for firewalls. If you are behind a firewall that can only connect to the outside world on certain ports (80, for instance) you will just need to find a servent running on port 80. Since the servents can serve on any port, you are likely going to find one that is serving on a firewall-friendly port. Also, if you are trying to download a file from a servent that is behind a firewall, you can ask the firewalled servent to push the file to you since you will not be able to connect to it directly. The only thing the protocol cannot compensate for is file transfers between two servents behind two different firewalls. In such a case, there really isn't anything that can be done."
Well, there is a possible solution to that kind of problem: find a relay on the reachable public ip world. With some minor change to Gnutella, then Servents on the public internet could serve as a relay between two servents behind different firewalls. Here is a possible scenario, the requester assume that the servents having the interesting file is also behind a firewall, and assume it is not the same one. Then it request for anybody on the public internet to serve as a relay. It receave a certain among of answer from friendly servents ready to share their bandwidth. It randomly choose one of those possible relay, and ask him to be ready to receave connection from the two servents behind those firewalls. Then the requesting servent connect to the relay servent, and ask the servents with the interesting file to push it to the relay.
With the relay function, the request for rendez-vous point and an almost standard push request, we can allow anybody to exchange file with anybody else. The relay function is quite easy to implement. What need to be investigate, is the best way to implement new messages to request for a rendez-vous point (the relay). The relay can take the opportunity that every bytes from the exchanged file are gonna get accross, in order to take it's own local copy. In fact, some servents could passively start to build their own collection of files from the Gnutella net, just by accepting a lot of relay. You don't need to search anymore, just be the man in the middle.
Have my private Gnutella net behind my firewallOne could want to have with friends and collegue their own private Gnutella network and still participate into a larger public Gnutella net. If we are behind the same firewall, we don't need the special relay trick to exchange file. In fact we don't need the push technique either. If we are behind the same firewall, my network 10 and your network 10 are the same. Now you could test that by trying to connect, but I have another idea.
If you want your own private Gnutella net, you could speciffy some kind of a private autonomous system, or community string that would be unique to your compagny, or your private address space. Then you will share that unique identifier with friends from your compagny. This information need to accompagny every usefull (data transfert related) message (could be into the GUID?). Then when you want to initate a file transfert, you check first if we are part of the same community=same private network. If such is the case, then you can make a direct connection. Otherwise, and if both use private address space, you need to find a relay wiling to help on the real internet.
Now, if you want to protect your private Gnutella net from download from the other side of the firewall, you just need to refuse to do push and use the security from the firewall and network addresse translation on the network. So a Gnutella user interface should detect we use private ip address and in such case ask for a unique community string. Also the user interface should permit to disable push capabilites.
Of course if you are at the boundary between your private Gnutella net and the public Gnutella net, you will have special rules concearning request propagation. There is no need to propagate (except if dual homed) push from outside to inside as they will be block.
Stealth client - multi-homed client
This is a special kind of client that do not show itself and does not give
any information out about it's presence, ip address, number of files and
kilobytes. In fact, we have nothing to share! We are a read-only kind of
client and only when the user ask for a search or a download, we will have
to showup. Now such a Steath client can have a single connection to the
Gnutella net, but it can be also dual-(or multi-)homed. This mean I have
more than one connection to the/a Gnutella net, but I do not propagate
any information from one side to the other one (if it was a ip router it
would be like a no ip routing from cisco or disable ip forwarding from
Comments on Knowbuddy's Gnutella FAQ
Other argument for not using UDP, but maybe ICMP then.
Firewall don't like UDP and won't accept UDP comming from the outside world.
If UDP is use, then the application (Gnutella servents will have to implement
their own relyability layer). This will make the software implementation
a lot more complex and difficult to troubleshout.
Gnutella Proxy Server part of a Firewall?
Well, I have already try to setup a private Gnutella Network, and as soon
as one of the Gnutella servents get in touch with the real Gnutella net,
the privacy is broken. On most firewall today, we let the traffic go outside,
just because it is way to difficult to define what is require and what
is not. Some may limit to HTTP access, relaying on port number 80 for the
destination, but you have a lot of http server working on another port.
Gnutella is a trojan and a dangerous security issue!
Most application, when use on a private network, behind a Firewall are
not dangerous for the user and dissimination of secret/sensitive corporat
document. If you install a personnal web server on your PC, your company
firewall will protect you from external access and still let you share
files with other within the company.
Anti Search Query Spoofing and DoS attack.
If any mecanism is implemented in order to be able to Ban an IP address,
then this mecanism could be used to try to ban an innocent user. There
is definitively a need for policying the traffic generated by the connected
neighborg and take action if the traffic they generate is unwelcome our
outside statistical expectation, bandwidth usage. This kind of technique
is already implemented inside BGP, if your peer does reset the BGP session
too frequently, you gonna stop trusting that peer and temporary ban him
(quarantain). That way you avoid too much flapping on internet's highway.
The content of this page is copyrighted: ©David GLAUDE.
Content last updated: Thu Jan 31, 2002.
This file generated: Fri Apr 26 12:17:46 CEST 2002 .