RE: DoS attack ?

Patrik Fältström <paf@cisco.com> Fri, 07 December 2001 08:18 UTC

Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GNY00K04SEIMD@eListX.com> (original mail from paf@cisco.com); Fri, 07 Dec 2001 03:18:18 -0500 (EST)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GNY00K01SEHMB@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 07 Dec 2001 03:18:17 -0500 (EST)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GNY00K01SEGMA@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 07 Dec 2001 03:18:17 -0500 (EST)
Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GNY00J5JSEGHL@eListX.com> for ietf-irnss@lists.elistx.com; Fri, 07 Dec 2001 03:18:16 -0500 (EST)
Received: from [0.0.0.0] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA02731; Fri, 07 Dec 2001 09:14:06 +0100 (MET)
Date: Fri, 07 Dec 2001 07:33:52 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Subject: RE: DoS attack ?
In-reply-to: <7FC3066C236FD511BC5900508BAC86FE4364D0@trestles.internal.realnames.com>
To: Nicolas Popp <nico@realnames.com>, 'John C Klensin' <klensin@jck.com>, YangWoo Ko <newcat@spsoft.co.kr>
Cc: ietf-irnss@lists.elistx.com
Message-id: <23656972.1007710432@localhost>
MIME-version: 1.0
X-Mailer: Mulberry/2.1.1 (Mac OS X)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <7FC3066C236FD511BC5900508BAC86FE4364D0@trestles.internal.realna mes.com>
List-Owner: <mailto:ietf-irnss-help@lists.elistx.com>
List-Post: <mailto:ietf-irnss@lists.elistx.com>
List-Subscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=subscribe>
List-Unsubscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=unsubscribe>
List-Archive: <http://lists.elistx.com/archives/ietf-irnss>
List-Help: <http://lists.elistx.com/elists/admin.shtml>, <mailto:ietf-irnss-request@lists.elistx.com?body=help>
List-Id: <ietf-irnss.lists.elistx.com>

--On 01-12-06 10.09 -0800 Nicolas Popp <nico@realnames.com> wrote:

> You can also do what most search engines would.
> You return a (small) range of ranked results in the set of results and
> your last result is a referral back to you for the next range in the
> set...Then you try to detect automated crawlers that recursively follow
> the referrals and slow them down to a halt.
> 
> So, just from that standpoint, it could be useful for the protocol to
> support the notion of results set range (query) as well as referral
> (response).

We have been through this when looking at other protocols....and I would
urge you to learn from earlier mistakes (and successes).

(1) One practical path is to give in the protocol a way for the server to
say "I'm sorry, but I will not do that operation you requested. Instead I
did the following". This generic response can be "you only got 10 records
even though the result set is larger".

(2) As soon as you do "paged results", you force the server to keep state.
Depending on whether the protocol is stateful or stateless, it is harder or
easier for the server to know when to remove the cached search. Further, as
soon as you start doing pages results, you end up getting problems with
sorting the result, handling of database changes between the two fetches
(i.e. can the server re-issue the query for the second fetch, or do the
server really have to cache the result set and return the second part at
the second fetch) and million of other problems.

So, my suggestion is "don't go there".

    paf