Since some time ago I am thinking about solving the bunch of security
issues which ware arisen in Gnet. This document is a preliminary
approach what try to establish the working scheme of some ideas which
I think could be useful for that subject. I also use some
considerations that I had read in the GDF. It is clear that this
security scheme requires some effort, but I think that making that
effort in security will be essential to a long-term success of Gnet.
At this point I don't give any individual definitions of messages
(although some definitions will be very obvious), so a more detailed
protocol definition will be needed if the proposal is considered
practical. I also leave some issues open for choosing, like certain
numbers designation and different possible options, for a better
public consideration. I spent some time and work trying achieve a
mostly complete solution, so please read it and try to understand the
whole system before criticizing. Although, of course, any comment,
suggestion, flaw warning or consideration are welcome. I hope you
could find this proposal useful. Once again, I'm sorry about my
english faults.


Gnutella Security Proposal

1 Introduction and considerations

This proposal suggest some complementary protocols to Gnutella in
order to built secure peer-to-peer network. The security issues that
this document address are those ones related to the broken of the
useful operation of the network. That include intentional attackers,
spammers and also "normal" servents who have a harmful behaviour to
Gnet.

Open security mechanisms are suggested not only because they are the
most suitable to a open network like gnet. The facts also had shown
that a open approach to security problems are largely more effective
that one based in proprietary knowledge or secret algorithms, since
when open anyone could detect and communicate the flaws of the
system, so the system need to be effective by itself, not by a
alleged ignorance of it.

I think that the cooperative Gnutella assumption have flaw in its
design: it suppose that all servents will be well behave, but a well
known history of internet abuse say something different, and even
worst, more success to Gnet could dramatically increase these abuse
practices. So, I think that for a long term successful network it
must have security between its basic features. That proposal try to
make a scenario where any host could be bad behave, but the network
remains operational by rejecting that host. This try to make a
environment hostile to hostiles, within several checkings and
countermeasures included in the network, so it not only will be
useful to protect against known attacks, even also it could give some
tools useful to fight against future attacks.

A assumption was made about that most (or at least some of them)
servent authors (and may be other people too) are willing to make
certain efforts to secure Gnet. This include not only implementing
the security extensions but also supplying some services like the
certification and audit services, in a similar way that the host
cache services are offered. Likely, any successful servent author
will be attracted by self interest in owning those services.

In order to fight against the problems of securing a distributed
network, with no central point of trust, this proposal use precisely
this characteristic, a huge number of peers involved, to use it as
obstacle against hostiles. Several schemes use a mass policy (it is
needed a lot of nodes to get something), so a hostile user need to
own a great portion of the network to get its objectives, what is,
obviously, impracticable.

The proposal is divided in three main protocols which each one covers
a implementation aspect, altogether trying to achieve a wide
protection. Although they could be implemented separately, the three
protocols have interactions with the others so they are
interdependent for effectiveness.

1.1 Time synchronization consideration.

Since several aspect of this proposal use time related
considerations, a minimum time synchronization may be useful. Large
different time settings could also cause problems in established
features like download mesh, so it should be general interest to make
some improvements in this issue. In the GDF was proposed that the
servents make some kind of access to time servers, but this issue was
never become realized. Anyway, a more basic approach, that could be
valid for every servent, is to establish some minimal time checking
when handshaking. A time headers could be exchanged when connecting
and then, If the time difference exceeds a establish maximum (maybe
half an hour), the connection is rejected and a error is reported (to
the previously non-connected to Gnet node) in order to suggest the
user to adjust its computer time setting. GMT is presumed when naming
any time examination.

2 Gnutella Certification Acquisition Protocol (GCAP)

2.1 Description

This protocol establish a mechanism of identifying individual users
by certificates. Those certificates use e-mail addresses for
acquisition but they could be anonymous (they use a GUID for
identification), since the goal of this protocol is to establish
particular node identification within Gnet, and not to identify
people. The e-mail mechanism is useful because a attacker or hostile
don't have a infinite number of e-mail to retry, but it is not so
costly to any user, who even could create a mostly anonymous account
in any public web e-mail service. I think that the user will be glad
of the little effort of give that e-mail if, in exchange, he get
connect to a mostly secure network. Giving e-mail for registration is
also a common internet practice.

The certificates are issued by any Gnutella Certification Authority
(GCA). The GCAs are constituted like a distributed peer to peer
network, since there isn't central point or root of certification.
Several GCAs will likely be founded by the servent authors, though
any well known entity or community could also become GCA. The GCAs
relate to each other by trust, so the GCAs will establish a mutual
relationship (and therefore, establishing a connection to each other
service, see 2.7) with others GCAs they trust. In order to a GCA
certification be effective, it will be needed that the GCA list one
trust also trust each other. Due to the mutual trust establishment
between servent authors, eventually a well know group of GCAs will
arise that all trust each other. Although theoretically any GCA will
trust only the GCAs he chose, and also any individual servent can
also select what GCA derived certificates he trust, likely all the
servents will mostly trust this well known group. Note that servents
with certificates issued by a GCA not in the well-trusted GCA group
will be expelled to the margins of the network, and eventually
excluded.

The most probable scenario will be that initially only exists 2 or 3
GCA, group that later could be increased with others. The GCAs could
be root-CA or also be a sub-CA of a well know root CA like verisign.
This second approach would be interesting for new GCAs or community
GCAs who are willing to be trusted.

Each GCA establish a open service (see 2.7) which are connected to
the other GCA services which it trust. In order to issue the
certificates a open protocol is established, so any user could obtain
a certificate in the GCA he chose. Likely each servent will request a
certificate in the GCA Service supply by its author, but anyway it
also could be requested to any other GCA. A vendor-tied GCA is not
considered useful, first because any system to assure it (like a in-
code private key) could be broken, second, because the open issuing
policy gives several advantages: keeps gnutella open, since any new
servent could use the existing GCAs, and also lets the GCAs become
independent of vendors, since despite who founded it, It don't need
vendor related implications.

Each GCA have two public keys (each one may be 2048 bits), used to
sign the certificates and other subjects (like ban messages). One is
used to normal certificates, and the other for CCS (see 2.3.3).
Obviously the private keys never should be disclosed. The public-
private key of the GCA will be periodically renown by updating the
CATL (see 2.5.2).

2.2 Certification Acquisition.

Typically during the installation process a servent will request a
certificate (it could also import a existing certificate). The
certificate acquisition is split in two phases, first a request is
made to a GCA service giving a e-mail address and the user public key
(may be 1024 bits),. which correspondent private key will used to
sign queryhits, pushes, and other messages. Then a confirmation e-
mail is sended to that address with the GUID of the future
certificate. After that, the registration is completed when the user
connect again supplying that GUID, and then the certificate is issued.

Cause shorten revoke lists, the certificates have a short expiration
time (maybe 6-12 months), but it could be automatically renewed in
their last validity month by using again the e-mail.

Note that the number of issued certificates could give also some
approximate measurement of the number of users.

2.3 Certification levels.

There are tree levels of certification, those levels are establish in
relative terms for a servent by its CA Trust List (see 2.4.2), but,
since I think that will be likely that a well known group of GCA will
be in the trust list of most users, for a general point of view that
level will be establish relative to this well known group:

2.3.1 Non-Certificated Servent (NCS)

These are all the present servents, (and possible future server
without GCAP). Eventually these Non-certified servents only could
become leaf nodes, and later disappear. Note that a Certified Servent
could be also be consider as a NCS for other node who don't include
that certificate issuer in its trust list (likely because it was
issued by a GCA outside the well-known GCA group).

2.3.2 Certificated Servent (CS).

It is a servent which own a normal certification given by a GCA.

2.3.3 Confirmed Certificated Servent (CCS).

It is a servent who was prove trusted and useful to the network. This
is made by accrediting uploads (The GCAs will also give that
certificates to well-known people). When resolving conflicts (see 3),
a CCS message is more valued than other from a normal certified
servent.

A CCS is accredited by a certificate issued by a GCA with a different
public key that the one it used for sign a normal certificate. In
order to get that certification each time that a servent give a
upload that servent could ask for a upload ticket (UT). The ticket
consist in a indication dated and signed by the downloader private
key accompanied by that user short certificate. After completing the
download, the downloader should sent that ticket when requested. A
ticked issued by a CS will have 1 point value and a ticket issued by
a CCS a greater value (may be 20). Only tickets issued by different
servents (with different certificates) are valid. When a servent
reach a given number (may be 1000) of points (within a establish
time) that servent could connect to its GCA, send all the tickets
with its correspondent certificates (which need to be issued by a GCA
that this GCA trust), and then after checking those tickets, the GCA
will send a confirmation e-mail in order to issue a CCS.

Note that in order to get a CCS a malicious user need to obtain a
huge number of certificates (1000), or instead of that he need to was
obtain 50 previous CCS. Note also that a CCS don't give any great
privilege or capacity of harm the network (it only become more
trusted than other nodes, but not decisive), so the great effort
needed for a malicious user in order to get a CCS will be no
compensated. Note also that even the existence of CCS is not needed
to this proposal work properly, it only make more trust valuable some
nodes messages and quicken the complaints points accumulation.

Initially few CSS will exists, since that certificates will be only
issued by GCA to direct known people, but in a matter of time its
number will increase with more tickets issued and more value for
tickets issued by CCSs.

2.4 Implementation.

In order to go from the insecure actual network to full implement
this proposal will be need a progressive level of implementation.
This level is indicated by CATL (see 2.5.2) a phase number that could
be eventually updated online by the server vendor.

Phase 0. GCAP enabled servents are released and certificates are
issued (including CCS), but not special certification is required for
any connection.

Phase 1. Only Certified servents are allowed to be ultrapeers,
therefore all old remaining ultrapeers are disconnected of Gnet, but
tolerated as leaves. GCRP (see 3) will begin being used. GCCP (see 4)
would being also used. In phase 1 we already get a lot of the
security benefits of this protocols.

Phase 2. All servents must have a Certificate, including leaf nodes.

2.5 Certification format.

The certification are issued in standard format (X.509) containing a
public key supply by the user, but it identify the user by a issuer
chosen GUID and non by name. (Note that in the rest of this document
I will use GUID meaning this GUID which figure in the servent's
certificate, not the GUID used to identify individual messages,
unless notice otherwise). Of course, this will be the server-id sent
as last data on queryhits. So the certificate is anonymous, and the
user e-mail used in order of obtaining the certificate may not be
included in the certificate. A Gnutella short certificate (GSC)
version is also issued. This version is used for a less b/w
consumption in certain operations. It only include the GUID, the user
Public Key, the expiration date, the GCA number (see below) and, of
course, the signature of the GCA (it also could include a checkpoint
date if that feature is determined, see 2.5).

2.5.1 The GCA-Number

The GCA number is a 16 bits number registered in a GDF database
identifying the GCA. The 0 is reserved for no-certificate meaning and
a two consecutive numbers are assigned to each GCA. The odd number is
used in its normal certificates (CS) and the even number is used in
the confirmed certificates (CCS). This number will be used in several
messages for b/w saving, since the GCA public keys that a servent
need to know are only these ones in its CATL, so therefore given a
GCA Number a servent should know the corresponding public key.

2.5.2 The Certification Authority Trust List (CATL).

Each servent implementation should have a configurable CATL, that
list include the GCA who are trusted. The information included is the
GCA Public keys with its associated GCA-Numbers. The current value of
the GCAP implementation phase (see 2.3) is also included. The list is
initially shipped with a default values with the servent, but the
implementation MUST have the ability of a on-line update of that
list. That update would take account of the inclusion or exclusion of
trusted GCAs, new GCA Public keys, and also a new value of the GCAP
implementation phase. This update should be propagated within gnet by
a message ad hoc (signed by that GCA public key), so all servents
certified by the same GCA will update its CATL and broadcast this
message again.

2.6 Certification use and validation.

Certifications are used and verified (This means checking its
consistency with the GCA public key, not consulting the GCA revoked
list) in any successful connection establishment. That include a
normal connection to Gnet, a download/upload connection, and a GCA
service connection (except obviously, when obtaining a certificate).
Revocation lists are kept by the GCAs, and also cached revoked list
are kept (between sessions) by each individual servents (see 3), so a
revoked user (a user using a revoked certificate) who often try to
reconnect is most suitable to be cached. A more detailed
recommendation should establish when to check a GCA revocation lists
on a certification validation, or only using the checkpoint (see
below).

The problem with that is to get the revoked certificate servents out
the network, for what It is needed a up-to-date revoke information
while don't bring to halt the GCA services with a excessive
requesting of that information. A proposed scheme is that each
servent is responsible to request a certificate checkpoint of its own
certificate to the GCA if the previous checkpoint is more than a week
old. This checkpoint will be implemented as GUID and date info signed
by the GCA, or including a checkpoint date in the short certificate
which is issued again, showing either way that the certificate remain
active. Then, in order to admit a connection, each servent must show
its complete or short certificate with an updated checkpoint less
than a week old. So, if the cached revoked list are kept
approximately for a week, a revoked certificate will be practically
useless, since, first, when it was revoked was also cached (see 3),
and later its checkpoint expire and obviously it can't get other one.

The Goal is that a abusing or hostile user will have its certificate
revoked by GCRP sooner or later, so since there is needed some effort
to obtain each new certificate (create a new e-mail address), the
abusing become impractical. Additionally the certificate existence,
and its relative difficulty of obtaining, allow to establish the
circle checking protocol (GCCP) which also enhance the GCRP
effectiveness.

Although this is not the main objective of the certification scheme,
certifications could be also used to give the user a trust valuation
of queryhits. Each queryhit should be signed and accompanied by the
GCA-Number (see 2.4) of the certificate (possible in a GGEP block),
and (depending on the CATL) the program display to the user if the
source is a NCS, a CS or a CCS. If the user decide to download, the
GCA number is verified from the certificate (a false GCA-Number given
in a queryhit could cause a complaint, see 3).

2.7 GCA Services.

Each GCA should establish one or more GCA Service (GCA-S). Those
services are in charge of issuing and supporting certificates. They
also act as auditors by GCRP (see 3). Each GCA-S are connected to
others GCA-S of the same GCA and to the GCA-S of others GCA it trust.
So a parallel p2p network of GCA-S is constituted. This network links
to other trusted GCA are created by private mutual consultation
between the different GCAs. Then, when two GCA agree to be linked,
the connection is establish with a challenge-response way and then as
usual the messages are kept encrypted by a symmetric key.

The GCA-S make all the possible consultations to the others in order
to assure its operation. For example, a GCA-S should check if the e-
mail is blacklisted in the others GCA-S in order to issue a
certificate to this e-mail. Also when a GCA-S act as auditor, and
detect a abuser who certificate is issued by other GCA-S, the other
one is notified.

Each servent in Gnet should connect when needed to that GCA-S network
throw the GCA-S issuer of its certificate. The GCA-S must take some
security measures against DOS Attacks, fake complaining, and others
kind of attacks. So they should keeps a cached list of IP and
certificate (GUID) of requesting host and rejecting, banning or even
the revoking the certificate when a given number of repeated attempts
was made. Due to the same reason, or due to a GCRP resolution,
individual e-mail addresses could also be blacklisted permanently.
Also a e-mail domain could be blacklisted if a great number of
violations by its addresses is detected (be careful about not
including here public webmail domains which would be used by
hostiles).

2.7.1 Gnet to GCA-S related messages

The Gnet servent/GCA-S communication is synchronous. The connection
is establish by the Gnet servent in order to deliver a particular
message and then disconnected. Messages need to be defined for, at
least, the next subjects:

2.7.1.1 Requesting a certificate (First steep). And response.
2.7.1.2 Requesting a certificate (Second steep). And response.
2.7.1.3 Updating the checkpoint of a certificate. And response.
2.7.1.4 Renewing a certificate. And response.
2.7.1.5 Making a complaint (see 3). And response.

2.7.2 GCA-S to other GCA-S related messages.

The communication between GCA-S is asynchronous and based on
permanent connection. Messages need to be defined for, at least, the
next subjects:

2.7.2.1 Asking if a e-mail is blacklisted. This message is sent to
all other trusted GCA-S.
2.7.2.2 Answering about if a e-mail is blacklisted. This message is
replayed to GCA-S who ask about it..
2.7.2.3 Requesting to revoke a foreign certificate (see 3). This
message is sent only to the GCA-S who issued that certificate.
2.7.2.4 Sending a abuser identified broadcast (see 3). This message
is sent to all other trusted GCA-S.
2.7.2.5 Asking about the complaint points (see 3) of a given IP or
GUID. This message is sent to all other trusted GCA-S.
2.7.2.6 Answering the complaint points (see 3) of a given IP or GUID.
This message replayed to GCA-S who ask about it.
2.7.2.7 Asking about the Public key of a given GUID. This message is
sent only to the GCA-S who issued that GUID certificate.
2.7.2.8 Answering the Public key of a given GUID. This message
replayed to GCA-S who ask about it.
2.7.2.9 Setting a new one or cancel a old one of its publics keys.
This message is sent to all other trusted GCA-S, and the will
initiate a update of its users' CATL (see 2.5.2)..


3 Gnutella Conflict Resolution Protocol (GCRP)

3.1 Description.

The resolution of conflicts between servents (one server think that
other have a bad behaviour) is resolved by the GCA-S (acting as
auditor) using normally a mass number policy. This means that a mass
number of different servents complaining about some other node can't
be wrong, because they are the precisely the network. This way, a
attacker or hostile node who have impact in a lot of nodes will be
subject of a lot of complaints too. So a attack which affect a few
nodes will be ignored, but that attack is also less important to the
network (if a attack or abuse affect few nodes by time, but it keep
doing it, anyway it will generate a lot of complaints).

When a servent see some servent behaviour he thinks is a attacker or
abuser, he make a complaint about it to its GCA-S. When a established
number of complaints reach a GCA-S, it mark that node as abuser and,
additionally to revoking the certificate (or requesting to revoking
to the GCA-S who issued it), it begin to respond to complaints to
that node with a special message, the ban message. This message is
signed by the GCA Public key (obviously, using the correspondent
private key), containt the IP and certificate GUID (if known) of the
abuser, and it is transmitted to the complainer. Then the complainer
may broadcast that message, which will be received by the adjacent
nodes, who check its signature, broadcasting it again (up to a given
TTL, that must be high, may be 12) and keep that abuser node info (IP
and GUID of certificate, if known) in a ban and revoke certificates
cache. The IPs are banned temporarily (may be 2 hours), but the
certificates are revoked permanently and it should keep cached for a
week. After a time is likely that no more complaints arrive, because
most servents (ultrapeers) will have that hostile cached.

In order to check if a node is considered abuser the next general
policy is used (see more details in 3.2):

- Each complaint have a value. The value is establish depending on
the reason of the complaint (see 3.2) and who is making the complaint
(a CCS complaint would have a x10 or x20 more value that a CS
complaint). Of course, only certified servers could make complaints.
Since a node (identified either for IP or certificate) can't make a
lot of repeated complaints (see 2.6 comment about DOS attacks) the
complaints should be make by different servents.

- Each GCA-S keep a lists as big as possible (trying to kept a day or
more) of complained (denounced in complaints) nodes and its value
points. Two different lists are kept for all the different complaint
reasons for a host, one identified by certificate Id (GUID), and the
other by IP. When a item on a list reach a establish points threshold
(a non certified node have lower threshold), its certificate (if it
have) is revoked (or requested to revoked to other GCA-S), and a ban
message replied as said above. If the hostile is identified only by
IP but not by certificate, a abuser identified broadcast (see
2.7.2.4) is sent to the other GCA-S, in order to those GCA-S begin to
treat it as abuser too. If a GCA-S receive a complaint about a
already revoked certificate, it must act in the same way that a
discovered abuser sending the ban message to the complainer.

- Any servent which receive a ban message should check if any of its
connected nodes are the one in this message, and therefore close the
connection to it. Of course that ban message need to be signed by a
GCA in its CATL. The ban should be cached temporarily by IP and in
certificate revocation cache up to one week (at least by ultrapeers),
broadcasted to its TTL, and the cached bans IP and revoked
certificates should be transmitted to each new established connection
(at least to ultrapeers).

3.2 Verification and abuse types.:

There are two general types of abuses, and each one require its own
particular policies:

3.2.1 Connection abuses.

These are abuses detected by a direct connected host. So rejecting
the abuse host will be easy: simply disconnect it. All GCRP compliant
servents acting as ultrapeers must check a agreed set of rules
against its direct connected nodes. This rules are establish to
reject not only attackers but also servents which have a bad or
harmful behaviour with the Gnet.

Upon implementation of GCCP (see 4) the ultrapeer faking hops problem
(changing the hops value to simulate that the message arrives from
other ultrapeer) will be minimized, so that connection checking will
be very effective. We will distinguish between relayed traffic
(traffic which comes from other ultrapeers) and "owned traffic"
(traffic generated by the ultrapeer itself or its leaves). A
ultrapeer is consider to have a limited responsibility upon its
leaves messages (because it could fake its leaves), the working
scheme of that responsibility is shown in the rule checkings below.

A set of limits will be agreed within this protocol, and they are
checked per a given time (per minute, or perhaps, because it could be
less affected by peaks, per 5 minutes or even more). All this limits
are related to "owned traffic". These limits would include:
- A limit of querys.
- A limit of queryhits.
- A limit of total b/w spent.
- (may be) A limit on re-quering. That is checked by keeping a list
of query search text after stripping non alphanumeric character
(including whitespaces).

Any ultrapeer which break this limits will be disconnected and a
complaint sended to a GCA.

In the same way, a ultrapeers should checks limits in the same
subjects against its leaves, so a leaf shouldn't spent more than a
(may be) 10% consumption of any of the ultrapeer limits (or it could
be disconnected and complained by the ultrapeer in the same way). So
a leaf node should care about not breaking its limits too.

Additionally a ultrapeer should have a control algorithm to prevent
break its limit in a high load condition. Obviously it will enforce
the limit to its leaves before limiting itself. A simple algorithm
would be to give the default 10% of its own limit, but in a high load
condition, for example if it have reached 90% of its limit, then its
leaves limit will be decreased to 5% or
1/<number_of_connected_leaves>, whatever less. Even if reaching 95%
of the limit, then don't relay any leaf message at all. After a high
load condition the leaf who had more spending will be penalized by
keeping this reduced limit for a while.

This limits will not only set a fence against attackers, they will
also decrease the practical effect of bad behaviour servents, and
improve the b/w manage and balancing on Gnet. The limitations will be
mostly harmless, for example: if a node is sending a lot of queryhits
and then it can't send more due to it reach its queryhit or b/w
limit, it is very likely that these dropped queryhits wouldn't work
to download since a lot of previous queryhits would initiate a lot
of downloads yet.

Additionally any ultrapeer should check some basic bad behaviours of
its direct connected ultrapeer and leaf nodes, this checkings should
include (but not only):
- Sending queryhits (hops=0) with a GUID different of its certificate
GUID. Or, if it don't have certificate, with multiple GUIDs.
- Any leaf node who sends messages with hops > 0.
- Sending queryhits (hops=0) with other IP that the one observed (see
details below 3.2.1.1).

As said, when a ultrapeer or leaf node is disconnected because this
policies, a complaint is sended to the GCA, so eventually a frequent
abuser will be banned of the network.

3.2.1.1 Remote-IP checking.

All GCRP compliant servents must sent the Remote-IP header when
connecting. Then this IP will be the only one used in queryhits and
other messages (push and pong). Using other one could generate a
complaint and be reported as abuser. If a host have the suspicion
about other host is giving a false remote-IP (because it is different
of other's reported), It should disconnect, but never use other IP
that the connection reported. The remote-IP will be also obviously
used by a host to specify when himself is firewalled by NAT.

3.2.2 Content abuses.

These are abuses related to information contained in messages, like
queryhits, so the direct connected host don't see any problem, only
the servent who use that information notice the problem.

There are two subtypes here: content faked and reference faked. The
first is when a host referenced in the queryhit is real, but the
content is fake in some way. Possible cases are:
A. The GUID/IP address don't serves the promised file.
B. The GUID/IP address serves a different file which don't match the
offered hash.

Note that since each queryhit should have a signature (at least in
implementation phase 2), you know that a queryhit is actually sent by
a servent, (elsewhere be are in case C, see below). In phase 1 a
ultrapeer could fake its Non-certified leaves queryhits to blame
them, but this is a very limited attack (to its leaves), and easy to
discover, since the leaves begin to receive several request of files
they don't have, so they will disconnect of this ultrapeer and they
also will complaint about it (remember that a often abuse cause often
complaints and the abuser is revoked and banned).

This subtype abusing is treated as usual: when a abuse is detected a
complaint is sended to a GCA-S. When a GCA-S see that a point
threshold is reached, it begin to send ban messages to the
complainers. Since the ban message should have a TTL bigger than
query and queryhits, that message should reach adjacent nodes to the
abuser, so this nodes will disconnect it. Then due to ban
broadcasting, the abuser will became rejected off the whole network.

The second subtype (reference faked) is when the information about
the content is false (which also could cause a DOS attacks to a three
party). Possible cases are:
C. The Data/GUID/signature of the queryhit is modified or faked.
D. The IP address is intentionally random or non-existent (Push also
tried without response).
E. The IP address/service is not a Gnutella servent (neither a HTTP
server, which could be used too).

The problem here is to correctly identify the originating servent in
the second subtype (reference faked). Again, GCCP (see 4) helps
prevent faking hops, the problem is reduced but no eliminated. A
malicious node will try two approach:
- Two or more nodes chained sending queryhits with faking hops and
signatures.
- Two or more nodes chained modifying other's queryhits which they
relay. This problem is also minimized since they only can modify
queryhits which route exactly throw their chain (throw both nodes),
not by only one of them.

GCCP don't prevent a ultrapeer faking messages of its leaves. So
here, like in connection abuses, the ultrapeer must take some limited
responsibility of its leaves. If a queryhits is created by a leaf,
the ultrapeer connected to that leaf which relay the queryhit must
signed it too, and add its GUID, GCA-Number and IP (possible in a
GGEP extension).

The case C may be some cases easy to discover (always discovered if
option 3.2.2.2 below is used). If a node trying to download (remember
that when connecting to download the short certificates, including
public keys, are exchanged) discover that the signature of the
queryhit is fake, it make a complaint about the relaying ultrapeer
which are in the queryhit too (see above). This complaint it is a
special case since there isn't needed a accumulations of complaints,
the certificate will be revoked immediately. That is because even
with single complaint which contain a invalid signature/data and,
over it, the right signature of a ultrapeer, incriminate that
ultrapeer completely (remember that a host know the public key of its
direct connected host, so it never shouldn't let pass a invalid
signature).

Two options are proposed below to identify the originating servent,
one with a approximation approach, and the second with a very strong
identification. Both are related to discover the origin in a
ultrapeer relaying chain. So, they determine what ultrapeer was the
first in relaying a malicious or fake queryhit. The reference fake
complaint therefore ever make against the first relaying ultrapeer,
and not the (possible) originating leaf. This is because although a
ultrapeer have certain control about its leaves queryhits (it should
check the IP sended in the queryhit, see 3.2.1.1). A malicious leaf
could sent queryhits with its real address but never respond to
upload or push request, trying to blame its ultrapeer. That is a very
limited attack, but anyway note that in both options below a push-
complaint (a special kind push, see below) is routed back to the
originating node. So a ultrapeer could easily prevent that attack by
keeping a list of push-complaints originated by diferents host, then
when that list reach a threshold the leaf is disconnected (and a
complaint sent about it), that way a innocent ultrapeer never reach a
dangerous complaint count in a GCA-S.

3.2.2.1 Option A.

When a queryhit is not working, both by connect or push (Case D) or
the host referenced by the IP seems to be a not Gnutella servent
(Case E), a node could send a additional Push, marked with a
complaint flag. Note that these pushes will be quite few than normal
pushes since the are only sent due to broke in push route or attack.
The way of distinguish between the two cases is that in the second
case the push-complaints will accumulate in the proximity of the
abuser. Likely, the hosts neighbours of a abuser will receive a lot
of this Push-complaints. So, when a threshold push-complaints of
different host are relayed (this message, like a normal push, have to
be signed and GUID indicated), they disconnect the host and send a
complaint (to the GCA-S) with the IP and certificate GUID. A often
abuser will be often disconnected and complained by this reason, so
it will become eventually banned.

To avoid the faking of push-complaints each ultrapeer keeps a per
connection list of last relayed queryhits where each element is a
GUIDs with its hops-to-TTL seen in the queryhit. Since a chain of two
(due to GCCP, see 4) push fakers only could send that push in the
route of received queryhits, and with the hops up to the hops-to-TTL
kept in that list, its horizon will be very limited. Obviously a
ultrapeer will limit the amount of push-complaints relayed with the
same complainer-GUID.

This option have the advantage that queryhits don't have more b/w
consumption than present queryhits (except for the signature), but
have other weak features. The main disadvantages is that the abuser
will cause complaints to its near hosts, and that a faking push-
complaint is reduced, but possible (specially by intercepting other's
queryhits).

3.2.2.2 Option B.

This option is based in that each node relaying a queryhit add its
GUID and signature to the queryhit, so the final receiver will have
the entire signed path of the queryhit. The bandwidth consumption of
this option won't be so high, since queryhits (and pushes) are
routed, not broadcasted. Using a SHA-1 hash (with other hash will be
short) to sign the first hop signature will spent 36 bytes (16 GUID +
20 signed hash) so the last relay in a path of 7 hops will add
36*6=216 bytes to the queryhit, with a average spent of 126
additional bytes in each hop of the path.

We take advantage of that information sent it within the pushes to
route them back. Therefore, a push is routed back using that GUID
list, simply each node in the path use the last GUID which will be
the certified GUID of a one of its direct connected hosts (unless
that host quit, and then the path is broken). Then remove that last
GUID of the list and sent the push to that one. This eliminate the
need of kept push-GUID route-list, and makes a more reliable delivery
of pushes, since they only could fail cause a node quit and not
because a item in a route-list is lost. Each ultrapeer also kept a
GUID-hops list (see above 3.2.2.1) of relayed queryhits to prevent
push faking.

We also create two new messages: a Push-Complaint (don't merge with a
GCA-S complaint) and Push-Answer. The Push-complaint is like the
precedent push, but include the entire query message instead of the
GUID list. The Push-Answer is a message which contains a list of
certificates (a list with a certificate corresponding each GUID in
the queryhit). The Message ID (I mean the Message ID/GUID of the
Gnutella message header) of the push-Answer are the same of the Push-
Complaint which cause it.

Each ultrapeer must keep a list of the host certificates which it
have a direct connection in the last half-hour, that is, the
connected nodes, and the nodes what quits in last half-hour (should
be a short list anyway). Remember that when the connection is
established, a servent exchange certificates with the other servent.

When a queryhit is not working, (see 3.2.2.1), a node could send a
Push-complaint. This message is treated this way:
1 - It is sent back using the GUID list of the included queryhit.
2 - If a node cannot sent back the push-complaint (because the
previous node quits), it create a push-answer message by itself,
appends the disconnected node certificate and send it forward (bound
to the push-complainer node).
3 - By the GUID-Signatures list included in the queryhit each node
knows how many hops remains to the origin. So, after sent back
message, they set a 30*<remaining_to_origin_hops> seconds timeout for
a response.
4 - If the push-complaint reach the origin (this would be very rare),
this node create a empty push-answer and it send the message forward
by the same route that the queryhit (remember it have the queryhit
sent in the push-complaint). The origin should also try to upload
like a normal push.
5 - Then Each node in the path appends the short certificate of the
PREVIOUS node to the push-answer message. Remember that each node
needs to know the certificate of the nodes it is connected
6 - If the above timeout expires and the waited push-answer are not
received, or a node precisely quits after requesting to it the push-
answer, the servent will create this push-complaint-answer message by
itself, set the certificate of the previous node and send it forward
anyway. It also close the connection (with that node which refuses to
sent the push answer) if the other node didn't quit, and send a
strong (valued) complaint about that node.

Now we will see how that work. If the push path isn't broken and no
one in the chain are faking nothing (this will be very rare) the
certificate list will reach the push-complainer. It will receive
before that the upload connection too, so it should forget the
complaint (if no upload connection was received a low points
complaint will also be generated, but that will be very very rare to
happen).

If the push path is broken (remember that this can only occurs due to
node quitting, not due to push route table problems), a certificate
list beginning with the node which quit will reach the push-
complainer. Then the push-complainer make a complaint about that node
(this complaint have higher points that the previous one). This
complaint is generated because this situation will also be related to
a abuser. A innocent node which quits only will be complained for
this reason one or a few times (in the moment when quitting), other
different thing will occur to a abuser or faker (a lot of complaints
will be sended, see below).

A faker will be always discovered if the push-compliant complete its
cycle. If the faker modify other's messages, the signatures won't
match with the certificates. It is easy to know who in the chain make
the fake (either if fake data or signatures): it is only needed to
check the signatures with the public keys know by the certificates in
reverse order. That is, the last signature is checked first, and so
on and so forth. The host after the first which checking fail is
inevitably the guilty (remember that a host know the public key of
its direct connected host, so it never shouldn't let pass a invalid
signature). A certificates faker is discovered simply by checking the
certificates. If one certificate is wrong the host after it in the
chain is the guilty. Note that a certificate signed by a GCA not in
the CATL is also considered wrong.

This will lead to a fake signature complaint (like Case C above, see
3.2.2), which could be checked by the GCA-S with examining the
queryhit (or the certificate list) in the same way (you have the
signature of the faker which show its abuse) so the certificate will
be revoked immediately.

Likely, a abuser or faker won't let the push-answer complete its
cycle which incriminate itself. He will opt either by not sending the
Push-answer (see step 6), or acting like its malicious partner quits
(due to GCCP they need to work in couples). So the first generates a
strong complaint, and the second option generates a no so strong
complaints, but break the couple. Then the node which relays the push-
complaint will kept a list of 2nd grade disconnected nodes after push-
complaint (it control that by GCCP), so its partner will need to use
other certificate, and so on and so forth (the certificates aren't
infinite). Anyway the abuser/faker will be complained a lot of times
and eventually revoked/banned.

This option prevent completely hop faking is in a sensible message
like queryhits. It enforces a very secure faking prevention since all
abuses will be complained and eventually rejected. It also assure
that it is impossible to fake push-complaints (because it should
include the chain-signed queryhit), so push-complaints attacks are
not possible. It have some b/w consumption, but I think it is
justified by its security benefits. Queryhits are routed and are
medium packets so some additional bytes don't increases a general b/w
spending of Gnet. Push-complaints and push-answers have high size,
but they will be rare packets. So, I strongly recommends that second
option.

3.2.2.3 Content abuses early verification.

Content abuses have very higher harm effect that connection abuses,
since the second ones could be rejected precisely in the point where
they harm. However, the content abuser have the advantage to the
security that they could be verified by a three party (that could be
a completely trusted party, like a GCA), not only by the direct
connected node like the connection abuses. So this could be used to
reject them early.

To assure that the these complaints are truth and to quicken the
process, the GCA-S must take all the possible actions. That include
that they should checks the signatures of the supplied queryhit (see
below 3.3), asking other GCA-S for the public key if unknown (not
short certificate was attach) throw a 2.7.2.3 request. Also, when
certain minimum threshold complaint was reached for a host, a GCA-S
should ask others GCA-S (throw a 2.7.2.5 request) about that host,
adding the other's complaints points to its ones to quicken the
rejection..

In order also to quicken the rejection a GCA-S MAY establish a
initial threshold less than the normal. When that threshold is
reached it may check the abuse by itself just in case that its have a
low work load at that moment. For example, a threshold of 1000 points
will be establish to declare a abuser, but, if 300 complaint points
are reached, a mostly idle GCA-S may try to download the complained
file and see if match its hash value. So if that is true the host is
immediately declared abuser. In case of a "reference faked
complaint", the GCA-S may also try to connect to the IP (if the
queryhit is not marked as firewalled), so if failed, the originating
of the queryhit isn't declared immediately abuser (because may be
that the connection fail, it is firewalled even without notice it, or
that the host was quit the network yet), but its points are increased
dramatically (for example by 200), because that check is obviously
trusted.

3.3 Complaint format.

The complaint include information about the complainer: IP and
certified GUID, information about the complained: IP and certified
GUID, if known, and a reason code. The list of possible reasons
should be detailed here.

The content complaints should also include all the proofs the
complainer have, that include the queryhit message who originate it,
even the short certificate of the complained if known, (for example,
when complaining about a content faked issue, the complainer must
have the certificate of the other host because it was connected to
it).

3.4 Attacks based in complaint faking.

This complaints system benefit from the fact that in order to work, a
lot of different complaints (of different hosts) should complaint
about a few nodes. A group of few nodes complaining about a lot of
host (which a attacker will do) won't work.

The GCA-S will be less busy than they would seems, since they attend
a kind of request that will be very occasionally: a new certificate
when a new user enter the network, and complaints when a attack are
in progress (erroneous complaints will be a very seldom issue). So
keep information about a often complainer will be easy. Like I said,
the GCA-S will check that a host (checked both by IP and certificate
GUID) don't make complaints too often (and obviously don't make
several complaints about the same host). So the threshold should be
calculated in a way that will be needed more than (may be) 100 hosts,
with some ones CCS, complaining about the same host.

So, in order to be effective, a complaint attacker must have either
several hundreds of host, or a mere hundred with some ones being CSS
(and therefore uploading files for a time to get a CCS certificate).
Each one of this hosts must get a different certificate (and
therefore, have a different email). Even all this tremendous effort
will be used only to revoke some certificates, because the GCA will
discover sooner or later that the same group of host are ever and
ever complaining, and therefore it will revoke its certificates, and
banned its IPs, so all the attack effort will be clearly impractical.


4 Gnutella Circle Checking Protocol (GCCP)

4.1 Description

This protocol is only applicable to ultrapeers, leaf nodes will work
the same way as present. Node is used as synonym of ultrapeer unless
notice otherwise. This protocol assume that a ultrapeer have a very
limited number of connections to others ultrapeers (usually 3). Any
servent which have, or try to have a large, number of ultrapeer
connections (may be more than 9, or may be even more than 6) will be
rejected by the other servents and a complaint (see 3) generated
about it.

The goal of this protocol is to get a node surrounded by a circle of
nodes which check any message it relay with the other's signature. So
it isn't possible for a node to fake hops or modified a relayed
message. A way of breaking this circle check will be two malicious
nodes working together. But this make more difficult the hostile
task, and very limited: any hop-faked message will be 2-hops reduced,
so its horizon its reduced dramatically, also any modified relayed
message need to have the path throw the two nodes. (Note also that
option 3.2.2.2 above will prevent the entire hop-faking of
the "sensible" querhits message).

4.2 Connection establishment and updates.

Upon connection establishment a node exchange not only the its owns
certificates, but also the certificates of the nodes (only
ultrapeers) they also are connected (they must have those
certificates since connecting to them). So each node will kept a list
of the certificates to the nodes it is connected, and the
certificates of the nodes each of this nodes is connected to.
Supposing 3 connection per node, each node will keeps 9 certificates
(3 first grade, and 6 second grade neighbours).

Each time a node quits or a new connection is established, a update
is sended to the previously connected nodes advising that, and (in
that case) including the new connection certificate.

4.3 Message relaying and checking.

Each message should have two signatures appended: the present relayer
and the previous relayer. Each time a node relay a message it swap
the present relayer signature to previous relayer and put its own
signature on the present relayer position.

Each node, upon receiving a message, check that the present relayer
signature match it connected node public key, and that the previous
relayed signature match one of the connected node neighbours (its 2nd
grade neighbours in that direction). Any signature failure will
generate a complaint about this connected node (and obviously
disconnect it).

If option 3.2.2.2 is used no additional signatures should be appended
to the queryhit message since each relayer puts its signature yet.

4.4 Future considerations.

Leaf nodes signature checking and even third grade signature circle
checking would be considered. At present moment I think they don't be
implemented because the amount of data needed to be transmitted and
kept by each node; and because it also won't let legacy sevents
acting like leaf nodes in phase 1 implementation.