CRISP Requirements Discussion draft-ietf-crisp-requirements-02.txt

1
CRISP Requirements Discussiondraft-ietf-crisp-req
uirements-02.txt

• Andrew Newton
• 55th IETF, November 19, 2002
• Atlanta, GA

2
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)

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

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

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

6
3.2.9 DNS Label Referencing

• The service MUST use DNS2 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.

7
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

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

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

10
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 thats fine
  but escrow has requirements unto its self that
  may be in opposition to the requirements under
  discussion.

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

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

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

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

15
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).

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

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

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

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

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

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

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

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

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

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

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