RE: DoS attack ?

John C Klensin <klensin@jck.com> Fri, 07 December 2001 17:08 UTC

Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GNZ00404GYOQ5@eListX.com> (original mail from klensin@jck.com); Fri, 07 Dec 2001 12:08:48 -0500 (EST)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GNZ00401GYNQ3@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 07 Dec 2001 12:08:47 -0500 (EST)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GNZ00401GYNQ2@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 07 Dec 2001 12:08:47 -0500 (EST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GNZ0027FGYMZ0@eListX.com> for ietf-irnss@lists.elistx.com; Fri, 07 Dec 2001 12:08:46 -0500 (EST)
Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.22 #1) id 16CORj-000Iji-00; Fri, 07 Dec 2001 17:06:00 +0000
Date: Fri, 07 Dec 2001 12:05:43 -0500
From: John C Klensin <klensin@jck.com>
Subject: RE: DoS attack ?
In-reply-to: <23656972.1007710432@localhost>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>, Nicolas Popp <nico@realnames.com>, YangWoo Ko <newcat@spsoft.co.kr>
Cc: ietf-irnss@lists.elistx.com
Message-id: <208750488.1007726743@localhost>
MIME-version: 1.0
X-Mailer: Mulberry/2.1.1 (Win32)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE
Content-disposition: inline
References: <23656972.1007710432@localhost>
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 Friday, 07 December, 2001 07:33 +0100 Patrik Fältström
<paf@cisco.com> wrote:

>> 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".

I think, given this and what I wrote earlier, we are in violent
agreement.  I would only add, to both your comments and mine,
that keeping state in a distributed system -- one in which a
"first" query could reach one server and a subsequent one could
reach a second one-- is terribly complex technically.  While it
is, of course, possible to be sure that all queries in a
sequence go to the same server (e.g., by opening a TCP
connection for the query and keeping it open until the query is
completely satisfied) such things don't have very attractive
performance or scaling proper for high-demand,
frequent-repetition, short processes.

    john