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
Content last updated: Thu Jan 31, 2002.
This file generated: Fri Apr 26 12:17:46 CEST 2002 .