Dcat: added wiki links for QKR and QKA

2005-03-20T05:16:06Z

added wiki links for QKR and QKA

← Older revision		Revision as of 05:16, 20 March 2005
Line 13:		Line 13:
	generally expire after a relatively long period of time.		generally expire after a relatively long period of time.

	Search clients request a query key by sending a query key request to a hub, which		Search clients request a query key by sending a [[QKR\|query key request]] to a hub, which
	includes the intended return address for the key. The hub generates a key unique to		includes the intended return address for the key. The hub generates a key unique to
	that return address and dispatches it there. This makes it impossible to get a query		that return address and dispatches it there. This makes it impossible to get a query
Line 21:		Line 21:
	When receiving a query from a foreign node, Gntuella2 hubs check the query key		When receiving a query from a foreign node, Gntuella2 hubs check the query key
	against the one they have issued for the query's requested return address and		against the one they have issued for the query's requested return address and
	proceed only if there is a match. If and only if the query key matches will the query		proceed only if there is a match. If and only if the query key matches will the [[QKA\|query
	acknowledgement be sent, or the search processed locally and forwarded to local		acknowledgement]] be sent, or the search processed locally and forwarded to local
	leaves and neighbouring hubs.		leaves and neighbouring hubs.

Dcat at 05:13, 20 March 2005

2005-03-20T05:13:45Z

New page

== Introduction ==

In an environment where a single query injection may result in a number of
responses, acting as a virtual "traffic amplifier", it is desirable to verify that the return
address is indeed that of the original sender. This prevents the network from being
used as a method of generating a large-scale traffic generator.

The Gnutella2 network uses a system of "query keys" to solve this problem.

Before a search client can transmit a query to a particular hub, it must obtain a
"query key" for that hub and include it in the transmission. Query keys are unique to
the hub generating them and the return address with which they are associated and
generally expire after a relatively long period of time.

Search clients request a query key by sending a query key request to a hub, which
includes the intended return address for the key. The hub generates a key unique to
that return address and dispatches it there. This makes it impossible to get a query
key for an IP which is not controlled, and prevents keys from being shared between
two nodes (key stealing).

When receiving a query from a foreign node, Gntuella2 hubs check the query key
against the one they have issued for the query's requested return address and
proceed only if there is a match. If and only if the query key matches will the query
acknowledgement be sent, or the search processed locally and forwarded to local
leaves and neighbouring hubs.

This has several positive effects. If a query does not have a valid key for the
receiving hub, it will not be processed and will thus not generate a traffic
amplification effect which may be used in a denial of service attack on a third party
host. Secondly, the query key mechanism ensures that queries are only processed if
they were transmitted from a host which has control over the host in the return
address (in the normal case, this is the same host). This means that flood control
mechanisms can remain just as effective as in the TCP case. Similarly, host blocking
is possible as the original query source can be verified.

Search Security - Revision history

Dcat: added wiki links for QKR and QKA

Dcat at 05:13, 20 March 2005