PLEASE GO AT http://users.skynet.be/glu/${file}.htm

	Sign In Sign-Up



		CLICK HERE FOR AN MORE UP TO DATE AND BANNER FREE VERSION 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. This document is dedicate to whoever is the writer of the "Knowbuddy's Gnutella FAQ". 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. I think there is space for improvement in those two area (even it is working the way it is). It would be possible to reduce the quantity of unecessary message propagation and also to use other routing technique that do no reduce the not so famous anonymity of a Gnutella net. From a protocol point of view, Gnutella flooding looks a lot like the flooding of LSA (Link State Advertisement) in the OSPF (Open Shortest Path First) routing protocol. It is a very strong and relyable technique, but each node receave almost as many copy of the message as the number of directelly connected neighborgh. If the number of edge is 'n' and the number of vertex is 'p', then the number of transmitted copies of a flooded message (like a search message) is p+p-(n-1). Other flooding technique or flooding limitation technique do exist, they all have their limitation and not always applicable for Gnutella. Spanning Tree (802.1d): This protocol is well known for it's convergence delays. It reduce the mesh topology into an active spanning tree. Every broadcast are propagated accross the forwarding interface. This protocol is having a very slow convergence time and require a unique id for each node and interface of the network. It is also very eassy to disturb the active topology just by announcing itself as the new root of the spanning tree. This technique is thus not applicable for a large network with very dynamic topology and possibly not conforment node (or denial of service node). Source Route Brindging: Source route brindging (used in token ring environnement) use a special message to broadcast or flood the network in search for a particular host. This message is called explorer (aka All Route Explorer). The request is send once as a single copy (just like a search in Gnutella). Each active bridge from the network (in our case each node of the Gnutella net) propagate the explorer and record the followed path (Bridge number + Ring number) in this explorer. If the explorer was already seen on the opposit ring, it is not propagated a second time. This reduce the flooding to a certain extend (even if you could receave as many request as the number of path from the sender to you). To limit even further the radiation of those request, a limit (like TTL) is set for every explorer. This technique could be easy to implement this into any flooded message from the Gnutella protocol. Each node (Gnutella servents) need to have an (almost) unique number. This number will be appended to the list of node the message was send accross. Each node need to know the unique id of it's neighborg. A message (flooded message) is only propagate to neighborg that are not already in the list (embeded in the message). This technique is to be used together with the OSPF one currently in use. If you are not familiar with token ring, you can think of it as an BGP AS_PATH attribute into any search request. Multicasting: is a good alternative to flooding. However it require a multicasting routing protocol (like PIM, MOSPF, DVMRP, ...) and the knowledge or announcement of multicator node (potentially all servent making search) and interested party (node offering file). Those protocol are not that eassy to implement and assume a certain stability or have bad convergence time or not scalable. However, some idea could be used to reduce the flooding. In particular, if a message is receaved twice from two different neighborg, one could use that information to announce that one of the path is to be 'closed'. This is not applicable just now and need deep rethinking of Gnutella net. Firewall limitations and possible solutions Can't transfer from behind a firewall to behind a firewall It 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 firewall One 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. Possible developpement 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 NT). The nice thing is that the Gnutella net you have connection to don't have to be the same... One could imagine multiple Gnutella net with no interconnection at all between them, and a user could connect to all off them. This somehow could solve some scalability problem. If we find a practical limit to the size of a Gnutella net, then we can start to build other one. Just like IRC started with one network, and now you have more than one... 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. Now, if someone want to increase anonymity and still go accross firewall, it is possible to implement a Gnutella like protocol on top of ICMP message (Ping). This kind of hidden channel has already been used with some success for distributed denial of service attack. However, because ICMP is well known for hacking purpose, it start to be monitored and block more and more. 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. This mean that if you implement a private Gnutella net using a Gnutella Proxy Server, you also need to make sure that none of your private servents connect directly to a servent from the public Gnutella network. This is very difficult to control. So if Alice and all the other behind the Firewall only connect to the Proxy Server, then it is fine. Another possible use for Gnutella proxying is to intercept search result and spoof them with your own address and then if you receave a download request, to request if from the original servents. That way anybody could serve as a cache and take it's own copy of the file. Please see similar idea in my rendez-vous solution to communication from behind different firewall. 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. If peaple start to use Gnutella servents for fun from a corporate network behind a firewall, because of the push technique, they are in great danger. What if by mistake the share a directory mapped from their corporate server. In a matter of second, all the corporate file could be at disposal of the user of the public Gnutella network. This mistake could be intentional, and Gnutella seems to be the easyest tool ever for that kind of information leakage. Because of current binary distribution of Gnutella servents, maybe the beast (trojan) is already inside a lot of corporate network. Hopefully given the quantity of traffic generated and the unsuccessfull connection attempt made before trying to push, usage of Gnutella should be fastly detected (if someone read the log). 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. This lead me to belief that if policying is to be implemented, it must be a local decission only and not a request action based on information not locally confirm. There are certainly many possible Denial of Service attack to the public Gnutella network. This could be unintended because of servents that misbehave, or this could be intentional to disturb or make impossible the use of Gnutella. If I was working for a big music corporation, I would hire a few hacker to build me a Gnutella destruction kit. Gnutella seems to be build like the internet, with collaborative effort and implicit trust. This mean that like TCP/IP, Gnutella is not robust enough to support any constructed attack. The distributed and non-centralised nature of a Gnutella network of servents make it really difficult to protect the network. If future Gnutella like protocol (Gnutella NG) are not build with protection against DoS attack as a goal (rather than as a patch) then it will continue to be weak. Please forget about requested feature and try to focus on the fondamental: anonymitty, security, robustness... David GLAUDE glu@who.net

5627		The content of this page is copyrighted: ©David GLAUDE. Printer Friendly Version