Download PPT Version

CRISP Requirements Discussion
draft-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 nonprivileged 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
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.