Internet Engineering Task Force David Kessens Draft ISI Expires February 1998 Wilfried Woeber ACONET David Conrad APNIC RIDE referencing Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes two variants of a proposal on how to find information regarding some critical resources (domain names, IP addresses and routing registry information) on the Internet. The proposed solution uses globally unique registry identifiers that are derived from a domain name in use by a registry. Introduction use your domain name as the global registry identifier register in DNS where to query for the data query the appropriate server using the local identifier Kessens [Page 1] Draft RIDE referencing August 1997 Discussion Advantage: no central authority needed Disadvantage: the same thing. Variant of the prososal: double tree. IANA managed registries.int tree. Detailed proposal globally unique registry identifier local to the registry unique identifier example: KH1-ARIN KH1 is local identifier ARIN is global registry identifier (last part of domain name can possibly be omitted) example: ISI-DOM suffix is not globally unique ISI-DOM is local identifier INTERNIC is global identifier What do we store in DNS? - server, protocol and protocol options - what kind of data is available: IPv4 193/8, 194/8, 195/8, 62/8 Domain .NOM, .STORE, ... AS 100-300, 1000-2000 Note: IANA is authoritive for most of this data! Which records to use: new record, TXT record, kitchen sink, reusing old record Security considerations The two different schemas described here have somewhat different properties regarding security. Kessens [Page 2] Draft RIDE referencing August 1997 The IANA delegated model is in principle a very secure way of providing identifiers that indeed point to the registry that contains authoritive data regarding the allocation of Internet resources, provided that DNS security mechanisms get implemented soon. The situation for contact information pointers is somewhat different. While the IANA delegated model provides trusted pointers to trusted repositories of such data, anybody has the ability to register whatever contact data they want to such a trusted registry, and thus not providing much extra trust in the data itself. The distributed approach has no guarantees whatsoever that one can trust that a pointer points to a trusted party, since their is no system in place that checks if registries are trustable. However, the poiters itself are reliable provided that DNSSEC is widely used. Also, the RIDE mechanisms itself provides ways of retrieving the pointed to data and letting an individual registry decide after parsing the data if it contains enough and good enough information to accept the reference. Acknowledgments We would like to thank Carol Orange and everybody that contributed to the work of the RIDE IETF working group in general, for their various comments and suggestions. References [1] D. Kessens et. al., draft-ride-classes-00.txt, March 1997 Author's Address: David Kessens, ISI 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 USA davidk@ISI.EDU Wilfried Woeber Vienna University Computer Center - ACOnet Universitaetsstrasse 7 A-1010 Vienna Austria Woeber@CC.UniVie.ac.at David Conrad Kessens [Page 3] Draft RIDE referencing August 1997 APNIC Japan davidc@apnic.net Kessens [Page 4]