Subject: [Fwd: Re: [Ietf-not43] Re: Requirement 3.1.8]

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Mon Aug 25 10:18:30 2003

Oops, I forgot to include the list in my reply. Thanks Andrew to make me 
aware of this.

Cheers,

Peter

-------- Original Message --------
Subject: Re: [Ietf-not43] Re: Requirement 3.1.8
Date: Mon, 25 Aug 2003 14:58:05 +0200
From: Peter Gietz <[email-masked]>
Organization: DAASI International GmbH
To: Andrew Newton <[email-masked]>
References: <[email-masked]> 
<[email-masked]>	<[email-masked]> 
<[email-masked]>	<[email-masked]> 
<[email-masked]>	<p06001a01bb680d15d9b0@[129.46.227.161]> 
<[email-masked]> <[email-masked]> 
<[email-masked]> <[email-masked]> 
<[email-masked]>

Andrew Newton wrote:

> Peter Gietz wrote:
> 
>>
>>> This is an interesting approach.  It would probably need to be worked 
>>> out more thoroughly on paper first.  However, you would also need to 
>>> include the qualifying matching rules and search scope.
>>
>>
>>
>> Why matching rules? Do you want to distinguish between string and 
>> substring search here?
>>
>> With scope I am not so sure either, since the policy should rule for 
>> whole subtrees. It shouldn't matter if the client makes basedn, 
>> onelevel or subtree searches, the access policy should be the same.
>>
>> I don't want to get this too complex. What might be added is the 
>> server side sizelimit (the maximum of entries a server will be willing 
>> to give back to the client), which should be one number for all naming 
>> contexts of the server.
> 
> 
> People will be attempting to mine data from these servers.  That is a 
> fact of life.  I know our service will not allow somebody to do a 
> subtree search in the contacts DIT.  For RLDAP, we excluded any partial 
> string matching if they didn't give use the first three letters of the 
> name (e.g. cn=*, cn=b*, and cn=bob*).  Therefore matching rules, search 
> filters, and scope will be allowed and disallowed depending on what the 
> person is attempting to do.

I still think that it is easier to prevent mining by a serverside size
limit than by specifying policy rules with parameters like scope and
matching rule. As I said, including such paramenters will make the
policy definition and interpretation quite complex. To get the
functionality of your example, we would notonly have to specify if
substringmatch is allowed and additionally the minimum length of the
substirng. The latter would have to be implemented as dedicated FIRS
feature since there i s no standard way of specifying substring length.

Is there another opinion on this in the group besides Andrew's and mine?

Cheers,

Peter

> -andy

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 T?bingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Mon Aug 25 10:27:59 2003

> feature since there i s no standard way of specifying substring length.

You can count on size limits by the server.

For the record, I do not favor the capabilities list.  I was just 
stating what it would need to express to be account for the policies of 
the server operator.

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 25 11:10:14 2003

on 8/25/2003 9:18 AM Peter Gietz wrote:

> matching rule.

Mining-prevention is provided through a variety of mechanisms. Section
5.3.2 of firs-core identifies some query-level restrictions.

  [...] The size limit field specifies the maximum number of entries
  that a server should return. For the FIRS service, this setting
  SHOULD be set to a value between 25 and 100. [...] Servers MAY
  truncate answer sets if the client specifies a larger value.

  [...] The time limit field specifies the maximum number of seconds
  that a server should process the search. For the FIRS service,
  this setting SHOULD be set to a value between 10 and 60 seconds.
  [...] Servers MAY stop processing queries after the time limit if
  the client specifies a larger value.

Section 5.3.3 identifies some volume restrictions:

  Specifically, server operators MAY restrict the amount of information
  provided to specific clients and/or users over a given amount of
  time, within reason. For example, servers MAY restrict clients to an
  arbitrary number of queries per-hour or per-day, or may impose
  mandatory time intervals between queries, and so forth. Servers
  which refuse to process a query due to volume policy SHOULD reject
  the connection and/or query using the "unwillingToPerform" response
  code ("53"), and SHOULD provide explanatory text in the error
  message.

  Clients MUST be prepared for connection requests and queries to be
  denied for any reason, and MUST treat these conditions as
  non-permanent failures. Clients MAY retry the operations if a known
  error condition is corrected (such as authentication errors), but
  SHOULD NOT automatically generate retry attempts.

Then there is the new control text, which provides a way for a server to
tell a client which syntaxes are going to be allowed in the query.

So basically, servers have a lot of options for mining-prevention and
operators have a lot of buttons and knobs for preventing excess queries.

> As I said, including such paramenters will make the
> policy definition and interpretation quite complex.

I don't see any reason to include these right now. If at some time we
discover a specific need for this kind of stuff, we can update the
inetResourcesControl and change its OID accordingly. The versioning text
was specifically provided to allow that -- eg, if the server returns a
newer control (with a new OID) the client can issue an explicit query for
the version it understands.

 To get the
> feature since there i s no standard way of specifying substring length.

I'm not worried about this at the moment. If it becomes a universal, we
can try to accomodate it at a later date.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 25 12:00:33 2003

on 8/25/2003 10:10 AM Eric A. Hall wrote:

> Mining-prevention is provided through a variety of mechanisms.

BTW, the reason I've got an ARCH document separate from a CORE document is
so that concepts can be described separately from the frobs. This is a
good example area, where the numerous frobs scattered throughout CORE can
lose their unity, and so should be discussed holistically in ARCH.

As such, I've added the following text to ARCH to clarify the frobs that
are available in CORE.

Are there any other frobs that any of the operators feels they need to
have, and which are missing from this list?

6.5.	Query Restriction Mechanisms

[FIRS-CORE] defines several discrete rules that can be employed by server
operators to limit the quantity and rate of queries from any particular
client. Some of these restrictions include:

  * [5.3.3] Servers MAY refuse service to any client.

  * [5.3.3] Servers MAY impose arbitrary maximum limits on the
    number of queries issued by any particular client for any
    given time period, such as limiting clients to 50 queries-
    per-day or five queries-per-hour.

  * [5.3.3] Servers MAY impose arbitrary time intervals between
    successive queries from any particular client, such as
    requiring clients to wait five minutes between each query.

  * [5.3.1] Servers MAY restrict the object classes that any
    particular client can query for, and MAY restrict the
    matching filters that any particular client uses for any of
    the object classes that they are allowed to query.

  * [5.3.2] Servers MAY restrict the maximum length of time
    they spend on any particular query before terminating the
    query.

  * [5.3.2] Servers MAY restrict the maximum number of matches
    that will be returned before terminating the query.

  * [5.3.4] Server operators MAY define ACLs on entries and
    attributes in the database that restrict the data that is
    matched for any particular client.

Any of these restrictions MAY be defined by the operators of the server in
question, according to the policies deemed necessary by the operators of
that. For example, operators MAY apply different restrictions on ranges of
client addresses, or authenticated identity, or any other necessary
metric, or any combination thereof.

---

From: davidb at verisignlabs.com (David Blacka)
Date: Mon Aug 25 14:04:50 2003

> have, and which are missing from this list?

Arbitrary maximum limits on the number of result objects for any given time 
period for a particular client.

IMHO, this is the core of mining prevention, as it is actually directly 
measuring the correct thing (response objects per unit time).

I think that it should be possible to count some result objects and not 
others towards the limit.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: shane at ripe.net (Shane Kerr)
Date: Tue Aug 26 05:58:58 2003

David Blacka wrote:
>>BTW, the reason I've got an ARCH document separate from a CORE document 
> 
> is
> 

We use this today, and would be sad to see this go.  For instance, users 
can query the database to determine if space has been allocated, but may 
not care to see contact information.  We only count contact information 
against our rate limits - you can get all the AS information you want from 
the database.  :)

-- 
Shane Kerr
RIPE NCC