CRISP Requirements Discussiondraft-ietf-crisp-requirements-02.txt

Andrew Newton

55th IETF, November 19, 2002

Atlanta, GA

7 Security Considerations

• Option 1: append

This document contains requirements for the distribution of queries against a mesh of participants and the possible generation and distribution of index hints both of which could be used in the development of DDoS attacks against the entire mesh or used to create data mining efforts by Direct Marketers (see Section 2.4.7)

7 Security Considerations

• Option 2: append

This document contains requirements for the distribution of queries among a mesh of participating service providers. Protocols proposed to meet these requirements must be able to protect against the use of that distribution system as a vector of DDoS attacks or unauthorized data mining.

3.2.4 Domain Information Lookup

• Option 1: append

The domain information set MUST be able to express and represent arbitrary information and extensions on a individual registry/registrar basis such as license agreements, authorized use policies or extended status notifications and/or marketing/for sale notices.

3.2.4 Domain Information Lookup

• Option 2: append

The domain information set MUST be able to express arbitrary textual information for extensions on a individual service instance basis. Examples of such information are license agreements, authorized use policies, extended status notifications, marketing/for sale notices, and URI references to other sources.

3.2.9 DNS Label Referencing

The service MUST use DNS[2] to determine the authoritative source of information about domain names. It is the intention of this requirement that a client be able to determine via DNS and query the servers or set of servers of the domain registry delegating the domain name, the domain registrar responsible for registering the domain name if one is applicable, and the domain registrant of the domain name. The service SHOULD provide procedures or mechanisms to allow this determination if it cannot be done using DNS. This allows the service to operate when an operator chooses not to take advantage of DNS label referencing and during periods of transient or erroneous state of DNS configuration.

3.2.9 DNS Label Referencing

• Nobody disagrees with it (once it has been explained to them)

• Nobody likes how it is worded

• Nobody has suggested alternate text

2.4.7 Abusive Users

• Option 1: add

Abusive users use the directory services of Internet registries as a source of email addresses, postal addresses and telephone numbers. Often a direct marketer as associated with junk postal mail, spam/uce and dinner time telephone solicitations.

2.4.7 Abusive Users

• Option 2: add

The directory services of Internet registries are often the target of practices by abusive users. Using information obtained from Internet registries, abusive users undertake certain activities that are counter to the acceptable use of the information as intended by a registry, registrar, or registrant. Many times, these practices violate law in the jurisdiction of the user, registry, registrar, or registrant. One example is the use of Internet registry information for the use of sending unsolicited commercial email.

3.2.6 Escrow Support The service MUST provide a means to escrow data of

domain registrars to an escrow entity using a common schema. This escrow capability SHOULD be "off-line" and "out-of-band" from the normal operations of the service.

Option 1: Since 3.2.6 is out of band and out of scope

lets remove it. If an entity wishes to use the schemas defined by crisp for escrow that’s fine but escrow has requirements unto its self that may be in opposition to the requirements under discussion.

3.2.6 Escrow Support

• Option 2: rewording

The CRISP schema MAY be usable in other protocols or support systems. As an example, a registrar MAY choose to use the CRISP schema as part of an off-line, out-of-band escrow service in order to enhance the ability to reuse the escrowed data in systems with disparate backed servers"

3.2.6 Serialization Support

• Option 3: rewording The schemas used by the service SHOULD be

capable of off-line serialization.

Off-line serialization allows for implementation independent operations such as backup and recovery, load-balancing, etc.  This MAY also make possible data escrow capabilities and other usages, however such usages are out of the scope of this document.

3.1.8 Query of Access Levels

If a query cannot yield a valid response due to insufficient permissions, the service MUST provide the client with an error response indicating this condition.  The service SHOULD NOT provide a mechanism allowing a client to determine if a query will be denied before the query is submitted.

3.1.8 Query of Access Levels

• Option 1: reword If a query cannot yield a valid response due to

insufficient permissions, the service MUST provide the client with an error response indicating this condition.  The service MUST provide a mechanism allowing a client to determine if a query will be denied before the query is submitted according to the appropriate policies of the operator.

3.1.4 Level of Access The service MUST allow the classification of data as being

either privileged or non-privileged, for the purpose of restricting access to privileged data. Note that this requirement makes no assumption or prescription as to what data (social or operational) might be considered privileged, but merely provides the ability to make the classification as necessary.

The service MUST be capable of serving both privileged and non-privileged data.

The service MUST be capable of authenticating privileged entities and ensuring that only those entities have access to both privileged and non-privileged data.

The service MUST be capable of providing access to non-privileged data without requiring authentication of any type (i.e. anonymous access).

3.1.4 Level of Access

• Option 1: rework Implies only two levels of access. Rework so that there

may be multiple levels of access.

No text yet proposed.

3.1.9 Authentication Distribution

The service MUST NOT require any Internet registries to participate in any particular distributed authentication system. The service SHOULD allow the participation by an Internet registry in distributed authentication by many centralized authorities.

3.1.9 Authentication Distribution

• Option 1: reword The service MUST NOT require any Internet

registries to participate in specific authentication systems. The service SHOULD allow the participation by an Internet registry in federated, distributed authentication system of their choosing.

3.2.3 Domain Registrant Search

The service MUST provide the capability of searching for registrants by exact name match or a reasonable name subset. This search must comply with Result Set Limits.

The service MUST provide a mechanism to distribute this search across all applicable domain registries and registrars. The service SHOULD have a means to narrow the scope of a search to a specific TLD. The service MUST be able to specify to the client an empty result set should the search yield no results.

3.2.3 Domain Registrant Search• Option 1: reword

The service MUST provide a lightweight mechanism to distribute this search across applicable domain registries and registrars. The service SHOULD have a means to narrow the scope of a search to a specific TLD. The service MUST provide a mechanism to restrict the scope of a search to specific TLDs, registrars and registries. The service SHOULD provide a mechanism for operators to opt-out of this search or series of searches. The service SHOULD NOT distribute queries to operators that have opted out. The service MUST be able to specify to the client an empty result set should the search yield no results.

3.2.3 Domain Registrant Search

• Option 2: modify option 1 Rework language concerning opt-out so as

not to imply an inter-service provider protocol. Such a protocol would be out of scope.

3.2.3 Domain Registrant Search

• Option 3: rework Remove second paragraph of 3.2.3.

Add a base requirement (in the 3.1 section) specifying that the following for referrals that they 1) must not be “generic”, 2) must have context and 3) possess the ability to pass back CRISP-opaque tokens.

3.2.5 Nameserver Search

The service MAY allow the ability to list all domains hosted by a specific nameserver given the fully-qualified host name or IP address, if applicable, of the nameserver. The service MAY provide a mechanism to distribute this search across all applicable domain registries and registrars.

3.2.5 Nameserver Search

• Option 1: remove 10,000 & 100,000+ host names on one nameserver

make it useless

Allows one to recreate a non-published zone file when lots of data mining is allowed.

• Option 2: modify Make reference to Section 3.1.1 Data Mining.

3.2.11 Query Settlements

• Option 1: add

Any search mechanism used to distribute a query to all applicable domain registries and registrars for Nameserver Search (3.2.5) or Domain Registrant Search (3.2.3) MUST contain provisions for cost recovery through a settlements mechanism.

3.2.11 Query Settlements

• Option 2: Out Of Scope

• Option 3: Specify the use of CRISP-transparent transaction

tokens. Uses of the tokens for financial settlement or other uses are out of scope.