ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

cleanup

Browse Source
This commit is contained in:
Mark Andrews
2005-09-09 06:26:02 +00:00
parent 60eeb0dbae
commit 5ddeca3a82
8 changed files with 0 additions and 5034 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/draft/draft-arrouye-keywords-reqs-01.txt
-899
View File
@@ -1,899 +0,0 @@
INTERNET-DRAFT Y. Arrouye
February 15, 2002 RealNames Corp.
Expires August 15, 2002 T. W. Tan
National University of Singapore
X. Lee
Chinese Academy of Sciences & CNNIC
Keywords Systems - Definition and Requirements
draft-arrouye-keywords-reqs-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The DNS (Domain Name System), which was designed as a network
resource naming layer, is not able to serve today's Internet users
naming needs anymore. Attempts to change the DNS to adapt to those
needs, such as the IDN (Internationalized Domain Name) IETF effort,
are not only proving themselves unsatisfactory in many ways, they are
also limited by the nature of DNS itself. There is now strong
consensus that the solution for naming for the Internet requires
layers above DNS. For example, John Klensin has advocated a multi-
layered model that undertakes to address the naming needs of the
modern Internet. In Klensin's model, the layer immediately above DNS
is fully multilingual and user-friendly. It is expected that this
layer will support a variety of distinct services. This document
Arrouye and Tan [Page 1]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
presents the requirements of one class of naming service called
Keywords systems, of which there are several deployed today. These
requirements are presented from the perspective of Internet users,
for whom there exists no satisfactory standard naming system.
1. Introduction
The Internet has evolved from a simple interconnection of networks to
a global infrastructure supporting academic, personal, governmental,
and commercial communications. As a result, the Internet's main
naming system, the DNS, has seen its use change dramatically. As the
number of names in demand has increased, so has the realization that
there is a profound mismatch between a name meant to be used by
humans and one meant to be used by applications. Because they have
been the only names available for use on the Internet, domain names
could not remain simply resource names, but rather were pushed to
became the labels that every Internet user would ideally associate
with the content they sought to access. That push has not happened
smoothly. Attempts to change the nature of DNS names by
internationalizing them do not solve the main problem of the
awkwardness of DNS names in a versatile, multilingual, human-friendly
naming scheme for the global Internet.
As result of the apparent inadequacy of approaches that try to
improve the ability of the DNS to serve as a universal, human-
friendly naming scheme, there is now strong consensus for
establishing a new layer of naming on top of the DNS [DNSROLE,
DNSSEARCH]. This new layer will allow the Internet community to
redefine naming in light of actual needs, without having to change
the DNS or rely on its evolution. The community stresses the
necessity for the new layer to go beyond the needs of the Domain Name
System to realize an architecture capable of accommodating diverse
services, with separate ownerships, different scopes and distinct
operating models.
One of the operating and addressing models proposed as a component of
this new layer is Keywords systems. These systems offer a
multilingual naming layer that is human-friendly and simple to use.
Many Keywords systems that offer similar user experiences are in
existence today: RealNames, worldwide; CNNIC, in China; 3721, in
China; TWNIC in Taiwan; Netpia, in Korea; Nipa, in Thailand, and AOL,
within its own network. The proliferation of Keywords systems in the
Asia-Pacific region emphasizes the DNS's lack of support for non-
Latin scripts.
This document presents the requirements that define Keywords systems
that will be able to interoperate and expand their usefulness.
Arrouye and Tan [Page 2]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
The goals of this document are:
1. To present a clear list of Keywords requirements.
2. To document the Keywords user experience. This defines how
Keywords are being and should be used by Internet users.
3. To document properties of Keywords systems or Keywords objects
that are deemed useful in every Keywords system.
4. To provide a framework for discussion of Keywords systems and
their standardization.
In this document, the terms Keyword or Keyword name have the same
meaning, which is the name of a Keyword. The term Keyword object, or
Keyword resource descriptor, refers to a more complex object
containing properties, or facets, of which the Keyword name is one.
The Keyword object is described in detail in this document.
The definition of terms related to internationalization are those
introduced in [I18NTERMS].
2. User Requirements that are Met by Keyword Systems
Keywords systems should be architected to meet user expectations. The
industry generally agrees that the following are the basic
requirements of any successful Keywords system.
2.1. Unique Names and Identities
The Keyword name is the only element of the Keyword object that the
users manipulate. In order for Keywords to function as an effective
addressing system (see Direct Navigation Using Keywords), a name must
be associated with only one destination in a given context (cf.
context below).
The importance of the uniqueness of the names is reinforced by the
need to support the notion of online identity. One's identity needs
to be clearly and unambiguously defined, and thus unique.
2.2. Above DNS
The DNS in its current form cannot accommodate the Internet's current
naming requirements. Neither can it be changed significantly.
Keywords systems must exist separately from the DNS to offer
applications an independent naming interface. The common view of DNS
and other addressing system is to place the low level systems below
others, so DNS is viewed as above IP addresses, and Keywords systems
Arrouye and Tan [Page 3]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
would be viewed as above DNS and URIs.
2.3. Multilingual
Keywords must be available in all languages and scripts. Because
Keywords systems are implemented electronically, and because it is
agreed that it is practical to use a single encoding for the names,
the languages and scripts that Keywords must support are those of
that encoding that will be picked.
2.4. Context-Based
While the name is the most important element of a Keyword object, it
benefits from being supplemented by other attributes such as country,
language, type of application (also called service type in [SLS] and
[KLS]), etc. These attributes are also referred to as facets. (See
"Benefits of Direct Navigation" for a further discussion of context.)
2.5. Applicable Across Multiple Applications
Keywords must function in a broad variety of applications and
devices, such as the World Wide Web, mobile phones, e-mail, etc.
2.6. Multiple Interoperable Namespaces
Due to the complexities of languages, local usage and policy
differences in countries or application domains, it is neither
feasible nor practical to implement a single, worldwide Keywords
system. A differentiated, interoperable federation of Keywords
systems will provide the flexibility and depth needed. These Keywords
systems will be unified by a single resolution protocol that will
guarantee interoperability of the Keywords systems for applications.
3. Keywords User Experiences
There are two common user experiences associated with Keywords. The
most common one, and the one that makes Keywords appealing, is
navigation. The second one is discovery. These experiences are
described below.
3.1. Direct Navigation Using Keywords
The goal of all Keywords systems is to make it as simple as possible
to reach a given physical destination by using a simple human-
friendly name. A physical destination is anything that can be
described by a URI [RFC2396], so for example a Web page, an e-mail
address, or a WAP page on a mobile phone are all physical
destinations. Internet destinations are one kind of physical
Arrouye and Tan [Page 4]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
destinations.
The typical experience of a user of a Keywords system is as follows:
1. The user enters a Keyword in her own language in her application,
and eventually selects an action (e.g. "go" in a Web browser, or
simply hitting the "enter" key).
2. The application transparently uses a Keywords system to map the
Keyword to a physical address that is appropriate to its domain
(e.g. a Web address for a Web browser, an e-mail address for a
mail user agent, etc.).
3. The physical address that has just been obtained is used to
perform the user-specified action (e.g. load a Web page, send e-
mail to a specific mailbox, etc.).
This is called direct navigation, as it lets a user go directly to a
destination using this simple name.
3.1.1. Benefits of Direct Navigation
Direct navigation is what makes Keywords systems appealing to users
as an addressing system. Keywords systems are designed with the
objective of providing the best user experience: intuitive names that
deliver expected results. This section looks at a few benefits of
Keyword systems.
1. Users see Keywords as actual Internet addresses, and they work
just like any other addressing system. Contrarily to traditional
Internet addresses, they are easy to remember. The critical part
of the Keywords navigation experience is in the second step, where
the application uses the Keyword input by the user to obtain a
physical address. This can be done today using proprietary
protocols or CNRP (Common Name Resolution protocol) [CNRP],
although it is likely that if Keywords systems are deployed on a
large scale a more compact protocol will be designed. What is
important to understand is how the application uses the Keyword as
well as other data to make a query to a Keywords system.
2. A given Keyword object may contain different physical addresses
for different applications, which is akin to saying that Keyword
objects are identified by a combination of name and application
type. That application type (also called service type in [SLS] and
[KLS]) makes up some of the context that is passed to a Keywords
system, along with a name (also part of that context), in order to
identify a given Keyword object. Whenever the context is fully
specified, a Keywords system will return at most one matching
Arrouye and Tan [Page 5]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
Keyword object. This notion of context is key to the resolution of
a Keyword query into a physical address.
3. The more context is available, the more powerful a Keywords system
can be, and the better user experience it can provide. For
example, just by introducing the language as an element of
context, one can then use a global name like BMW, or Coca-Cola,
and access content in the appropriate language. Obviously, such a
language facet contributes to the human-friendliness of the system
by allowing not only the Keyword names, but also the content they
refer to, to be in the user's language. Such a language context is
also quite easy to obtain, since operating systems as well as
applications already support the notion of a user-selected
language (such as one's browser language setting) or locale.
Note that direct navigation does not mean that the only thing that
can happen to a Keywords user is either to get to a destination or
get nowhere. A Keywords service, when there is no matching Keyword
object for the user's query, may return a list of approximate
matches. It is up to the application to use that list and interact
with the user as needed to pick between these matches if desired.
Applications may also choose alternate behaviors such as using a
search engine, or combining the approximate matches with other
heuristics, etc...
3.1.2. Definition of the Context
It is very tempting to make a long list of desirable facets of a
Keyword object. Location and industry category, for example, are two
properties that are often mentioned, and more facets are regularly
offered for consideration.
An important lesson learned from operating Keywords system so far is
that it is very difficult to ask users to supply context that is not
already available to the application. Not only does this usually
bring up user interface issues, it changes the user experience from a
"type the name, get what you want" to a less direct, much more
painful experience that drives users away from the system. It is also
worth noting that asking for determination after the user has input a
partial context that can match a number of Keyword objects, has the
same effect of breaking the user experience and discouraging her. The
key to context information in a Keywords system is that context must
be implicit (i.e. known a priori to the application) in order to
offer a good user experience.
As a result, one must be very careful in introducing facets that need
to be part of the context. On the other hand, one should always ask
the registrant of a Keyword to provide as many facets as possible, in
Arrouye and Tan [Page 6]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
order to be able to use them later, as applications improve and
become able to supply meaningful values for those facets as part of a
query to a Keywords system.
3.1.3. Manipulation of the Context
While the user should only be required to enter a name in order to
reach a destination, it is desirable that the hidden parts of the
context can be manipulated by the user. This is usually done by
providing settings that can be used to do these manipulations. For
example, a Web browser typically offers a way to set language
preferences, from which the language context can be drawn.
3.2. Discovery of Keywords
We have so far described the experience of a user who uses a Keyword
in order to get to a physical address. There is also a need for users
to discover Keywords. Discovery may happen either when a user is not
able to supply all the facets necessary to make a single
determination, or when she only has partial data such as a few words
of a multi-word Keyword.
Discovery services are valuable because they offer users a way to
browse a Keywords namespace and explore its content. They need to be
separate from direct navigation in order to preserve the directness
of the navigation experience. It is however possible to offer
discovery as a fallback after a failed navigation experience, as long
as the two experiences are clearly distinct.
3.3. Other Variations
In some environments, such as mobile phones, typing a full Keyword
may prove cumbersome. It is thus a good experience, in these
environments, to support some form of automatic completion of partial
Keywords. The navigation may not be direct then, because confirmation
from the user is needed, but the overall experience of using Keywords
is improved because of the diminished pain factor in entering the
names.
4. The Keyword Object
We have so far described the Keywords user experience and looked at
two of its aspects. We have said that Keywords system contain
Keywords objects that contain a number of facets. This section
describes facets that make up a Keyword object. There are two kinds
of facets, depending on whether they are used as part of the context
or not:
Arrouye and Tan [Page 7]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
1. Key facets are part of the context that is necessary to establish
a one-to-one mapping between context and a physical address. The
name and the service type are good example of such facets.
2. Informational facets carry information that is useful but not
required as part of the context. A description of a Keyword is a
good example of such a facet.
Key facets are always required. Some informational facets may be
optional, and others may be required. In this section, the facets are
listed with an indication of their kind.
One should note that some facets may make sense for some service
types and not for others. The categorization of facets below is
intended to ensure that the facets that are key are required for all
service types. Also, it may be interesting to allow optional context
facets, whose presence can improve the user experience.
4.1. Name (Key Facet)
The name is the most visible part of a Keyword system, as it is what
users see, remember, and then use in order to navigate. It is also
what defines one's online identity.
It is widely agreed that DNS and other Web-addressing systems (such
as the URI) cannot create human-friendly names. To be human-friendly,
a name must satisfy a number of conditions. It should be easy to
remember. Familiar brand names should be transferable to the
Internet naming system with no change if possible. Names should be
available for the whole user population, and should be available in a
user's native languages and scripts. Finally, the syntax of names
should be flexible enough to allow for desirable names. One will note
that that lack of syntax not only makes the names easier to remember
and use, it also opens the door to the use of Keywords through voice
recognition technology available today.
Issues pertaining to names are discussed further in the "Multilingual
Support" section.
While it is useful to have syntax free names, some restrictions can
be placed on name availability in order to preserve existing
namespaces. For instance, if a Keywords system offers a transparent
interface to namespaces like DNS, ENUM, etc... it can prevent the
subscription of Keywords that follow the syntax of these namespaces
in order to avoid confusion between the different namespaces.
4.2. Service Type (Key Facet)
Arrouye and Tan [Page 8]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
The service type is used to describe a class of applications that
provide a given service to users. For example, tentative service
types are "web," "e-mail," "mobile web," and even "dns" or "phone."
The service type is a primary mechanism to support the reuse of one
given name to denote different bits of information (which are
accessed through a given physical address).
4.3. Service Provider (Key Facet)
Because there are many different Keywords systems in existence, there
is a need to be able to refer to them to determine which system a
Keyword belongs too. That is the purpose of a service provider facet.
The facet is part of the context that defines the uniqueness of a
Keyword, allowing distinct Keywords provider to have their own
Keyword object for a given Keyword.
4.4. Language (Key Facet)
The language facet denotes the language of the Keyword. It can be
used, for example, to enable language-specific rules of
normalization, or simply to determine how to display a CJK name made
of unified Han characters.
There are many standards or would-be standards for the identification
of languages. The IETF standard for languages is defined in
[RFC3066], which obsoletes [RFC1766], still cited by many protocols
and IETF work documents. Also note that [RFC2277] says that language
tagging in IETF protocols should be done using this standard. The
biggest advantage of using language tags as defined in [RFC1766] is
that existing protocols and applications support them, which makes it
easy to obtain a language facet value as part of the Keyword request
context without user interaction.
An oft-cited categorization of languages is the one produced by SIL
International. Known as the Ethnologue [ETHNOLOGUE] their work
categorizes and uniquely identifies more than 6,700 languages used in
228 countries. There have been proposals to make the Ethnologue
categorization available as an Internet categorization, and one could
indeed use i-sil-xxx to refer to the Ethnologue language code xxx in
perfect conformance with [RFC1766], but today's applications are not
aware of Ethnologue language codes.
4.5. Content-Language (Key Facet)
The content-language facet describes the language of the content that
is accessed through the physical address. For instance, if the
Keyword named "Deutsche Telekom" has the Web physical address
http://www.telekom.de/dtag/ipl2e/cda/t1/ then the content language
Arrouye and Tan [Page 9]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
should be English since that is the language of the content.
This facet can be used for language negotiation, which is supported
in some protocols already. he facet uses the same standard as the
language facet to identify the language.
4.6. Country (Key Facet)
The country facet refers to the country for which the content
accessed through the physical address is intended. Countries are
indicated by using country codes from ISO 3166 [ISO3166]. ISO 3166 is
a three-part standard. The part relevant to current countries is ISO
3166-1. It standardizes names of countries and associates them with 2
and 3 letter codes referred to as alpha-2 and alpha-3, respectively.
Internet usage, primarily stemming from RFC3066, is to use the
alpha-2 variant.
Applications are only starting to support separation between language
and countries. Such a separation is very important, because it
enables to offer a good service to ethnic groups in a given location.
When language and country are mixed, only the populations large
enough to have a recognized dialect in that country can be serviced.
In order to provide backwards compatibility, it is permissible to use
the country component of an RFC3066 language tag in order to
determine the value of the country facet.
4.7. Physical Address (Informational Facet, Required)
This facet contains the address that the Keyword overlays, i.e. the
real name of the data that are accessed using the Keyword. It is
proposed that this facet always be a URI, which may require the
definition of new URI schemes for existing addressing systems. The
URI was designed as an extensible addressing system, and it would be
nice to take advantage of its properties for the physical addressing
component of Keywords systems.
4.8. Description (Informational Facet)
While key facets are necessary for querying a Keywords system,
informational facets are useful when displaying Keywords in listings,
such as the ones that a discovery service may provide. The
description facets describes a Keyword in a few sentences, in such a
way that its meaning is obvious to a reader.
There must be one description for the language of the Keyword, i.e.
if the Keyword is associated to Korean content, there must be a
Korean description. It may be desirable to support additional
descriptions in other languages.
Arrouye and Tan [Page 10]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
4.9. Location (Informational Facet)
This facet is often mentioned as something that is very useful. One
of the main problem is to decide what kind of location to use. Valid
suggestions include: a system like country, province, zip code, or a
subset thereof; ISO 3166-2; latitude, longitude, altitude; ECEF
(Earth-Centered, Earth-Fixed); and probably others. Note that it is
possible to go from one of the fine-grain systems to the coarser-
grain ones, but that the (lack of) availability of mapping tables may
be a factor. It is also possible to support more than one location
notation at the same time.
For applications like mobile phones, the location of the user
relative to cell towers (whose locations on or above Earth are
themselves known) is known by the mobile phone operator and could be
made part of the context. Note that this particular example raises
some privacy issues that the operator or service need to take care
of.
4.10. Category (Informational Facet)
There has been talk of the necessity of having some sort of industry
category facet in the next Internet naming layer, and of making it
part of the facets that determine the uniqueness of records in this
layer. While we agree that such information is useful meta-data that
can be used in a discovery service, there are some problems with
making such a category part of the context:
- Even though one may argue that the categories listed in WIPO's Nice
agreement [WIPO-NICE] are encompassing enough for industry
categories, there is no established standard for non-industry
categories. The development and ratification of such standard is a
very big task in itself.
- Applications do not support categories. If they did, it is doubtful
that a typical user could come to grasp with the big tree of
categories. And if only the top-level classes were to be offered to
users for selections, they would be lost even more since those
classes mix things such as computer software design and animal
grooming. And the fact that our [Ed.: RealNames'] marketing lady
calls us monkeys does not make that really clearer for everyone.
As a consequence of these problems, Keywords systems do not support
such data as a key facet, but only as an informational one.
5. Multilingual Support
Arrouye and Tan [Page 11]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
It is understood that today, the best way to manipulate names for
multiple scripts is to rely on encoding those names using Unicode
[UNICODE]. This is the proposed encoding of names for Keywords
system. References to characters or character sequences in this
document are made using Unicode.
5.1. Human-friendliness can also be achieved by helping users get the
desired result through some normalization of the names that are used.
For example, it is desirable to treat the sequence <U+0065 LATIN
SMALL LETTER e><U+0301 COMBINING ACUTE ACCENT> as equivalent as
<U+00E9 LATIN SMALL LETTER E WITH ACUTE> (the former sequence being a
canonical decomposition of the second one [UTR15]). But other
features of human-friendliness, for example respecting alternate
spelling rules for German, or handling traditional versus simplified
Chinese writing systems, are not always understood, or simply agreed
on. There is a need to define the requirements necessary for the
interoperability of Keywords systems, and what features can be used
to distinguish different services between each other. These issues
are discussed at a further point in this document.
Note that the discussion of normalization above is not a discussion
of Unicode normalization. It is a discussion of string normalization
that may use Unicode normalization as a tool. A better term may be
string preparation, and it would be desirable to use the framework
defined in [STRINGPREP] for such a normalization, if possible. Note
that there may be a need for different Stringprep profiles for
different languages, something that Keywords systems can support
thanks to their rich set of facets.
Different names normalization on top of the default normalization may
be an interesting service differentiator.
5.2. Traditional and Simplified Chinese
The Chinese language can be written in two forms: Simplified Chinese
(SC), used in the People's Republic of China (PRC) and Singapore; and
Traditional Chinese (TC) used in Taiwan, Hong Kong, Macau, and by
most Chinese people overseas. One of the issues that face naming
systems is that one name registered in one form may be used by users
writing the other form. Also, mixed form names may be an issue for
the same reason.
A common fallacy is to believe that there is a straightforward 1-to-1
mapping between the forms. Some of the Chinese characters of one form
have 1-to-many mappings, others have many-to-1 mappings, and others,
when in groups, cannot be easily converted without risking changes in
the meaning of the converted sequence. Also, some characters are used
in both traditional and simplified Chinese. As a result, the problem
Arrouye and Tan [Page 12]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
of matching Chinese input to registered Chinese names is complex.
However, Keywords systems may be able to offer a better solution than
existing systems to the problem of handling traditional and
simplified Chinese names.
First of all, Keywords systems fully support the notions of country
and language. Because the choice of using traditional and simplified
Chinese was dictated by countries, that support will help solving
that problem. For example, one common objection to mapping between
Traditional and Simplified Chinese forms is that the Unicode code
points for Traditional Chinese are also used in Japanese and Korean.
Having the language available prevents unwanted alteration of names
in these languages. Also, the availability of the country could lead
to different mapping rules agreeable to that particular country.
6. Conclusion
We have presented the requirements for Keywords systems, the Keywords
user experience, as well as some design and architecture
considerations.
Keywords systems, which are already deployed worldwide, will
represent an important component of the next Internet naming
architecture.
7. References
[CNRP] N. Popp, M. Mealling, and M. Moseley, Common Name Resolution
Protocol (CNRP), draft-ietf-cnrp-10.txt, June 2001.
[CONTLANG] H. Alvestrand, Content Language Headers, draft-alvestrand-
content-language-02.txt, May 2001.
[DNSROLE] J. Klensin, Role of the Domain Name System, draft-klensin-
dns-role-01.txt, May 2001.
[DNSSEARCH] J. Klensin, A Search-based access model for the DNS,
draft-klensin-dns-search-01.txt, July 2001.
[ETHNOLOGUE] SIL International, The Ethnologue,
http://www.ethnologue.org/.
[I18NTERMS] P. Hoffman, Terminology Used in Internationalization in
the IETF, draft-hoffman-i18n-terms-05.txt, January 2002.
[IDNWG] IETF IDN Working group,
http://www.ietf.org/html.charters/idn-charter.html.
Arrouye and Tan [Page 13]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
[ISO3166] ISO 3166 Maintenance Agency, ISO 3166 Standard,
http://www.din.de/gremien/nas/nabd/iso3166ma/.
[KLS] Y. Arrouye, V. Parikh, and N. Popp, Keyword Lookup Systems As a
Class of Naming Systems, draft-arrouye-kls-00.txt, August 2001.
[NAMEPREP] P. Hoffman and M. Blanchet, Stringprep Profile for
Internationalized Domain Name, draft-ietf-idn-nameprep-07.txt,
January 2002.
[PROVREGWG] IETF Provreg Working Group,
http://www.ietf.org/html.charters/provreg-charter.html.
[RFC1766] H. Alvestrand, Tags for the Identification of Languages,
RFC 1766, March 1995.
[RFC2277] H. Alvestrand, IETF Policy on Character Sets and Languages,
RFC 2277, January 1998.
[RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource
Identifiers (URI): Generic Syntax, RFC 2396, August 1998.
[RFC2916] P. Faltstrom, E.164 number and DNS, RFC 2916, September
2000.
[RFC3066] H. Alvestrand, Tags for the Identification of Languages,
RFC 1766, January 2001.
[SLS] M. Mealling and L. Daigle, Service Lookup System (SLS), draft-
mealling-sls-00.txt, July 2001.
[STRINGPREP] P. Hoffman and M. Blanchet, Preparation of
Internationalized Strings ("stringprep"), draft-hoffman-
stringprep-00.txt, Septermber 2001.
[UAX15] M. Davis and M. Duerst, Unicode Standard Annex #15: Unicode
Normalization Forms, March 2001
(http://www.unicode.org/reports/tr15/).
[UNICODE] The Unicode Consortium, The Unicode Standard, Version 3.0,
Addison-Wesley, Reading, MA, January 2000 (ISBN 0-201-61633-5).
Amended by the Unicode Standard Annex #27: Unicode 3.1, May 2001
(http://www.unicode.org/reports/tr27/), and by the Unicode Standard
Annex #28: Unicode 3.2, December 2001
(http://www.unicode.org/reports/tr28/).
[WIPO-NICE] World Intellectual Property Organization, "Nice Agreement
concerning the International Classification of Goods and Services for
Arrouye and Tan [Page 14]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
the Purposes of the Registration of Mark," June 1957.
http://classifications.wipo.int/fulltext/nice/ennnic.htm.
Authors' Addresses
Yves Arrouye
RealNames Corporation
150 Shoreline Drive
Redwood City, CA 94065
Phone: +1 (650) 486-5503
E-mail: yves@realnames.com
Tan Tin Wee
Bioinformatics Centre
National University of Singapore
10 Kent Ridge Crescent
Singapore 119260
E-mail: tinwee@pobox.org.sg
Xiaodong Lee
Chinese Academy of Sciences & China Network Information Center
4 South 4th Street
ZhongGuanCun
Beijing
P.R. China 100080
Phone: +86 10 62619750 3020
E-mail: lee@cnnic.net.cn
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Arrouye and Tan [Page 15]
draft-arrouye-keywords-reqs-01.txt 4 February 2002
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arrouye and Tan [Page 16]
doc/draft/draft-ietf-dnsext-ipv6-addresses-00.txt
-334
View File
@@ -1,334 +0,0 @@
DNSEXT Working Group Randy Bush (ed.)
Alain Durand (ed.)
Bob Fink (ed.)
Olafur Gudmundsson (ed.)
Tony Hain (ed.)
INTERNET-DRAFT September 2001
<draft-ietf-dnsext-ipv6-addresses-00.txt>
Updates: RFC 1886, RFC 2673, RFC 2874
Representing IPv6 addresses in DNS.
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org
This draft expires on March 25, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All rights reserved.
Expires 25/March/2002 DNSEXT [Page 1]
INTERNET-DRAFT Representation of IPv6 addresses in DNS. September 2001
Abstract
This document clarifies and updates the standards status of RFCs that
define direct and reverse map of IPv6 addresses in DNS. This document
moves the A6 and Bit label specifications to experimental status.
1 - Introduction
The IETF had begun the process of standardizing two different address
formats for IPv6 addresses AAAA[RFC1886] and A6[RFC2874] and both are
at proposed standard. This had led to confusion and conflicts on
which one to deploy. It is important for deployment that any
confusion in this area be cleared up, as there is a feeling in the
community that having more than one choice will lead to delays in the
deployment of IPv6. The goal of this document is to clarify the
situation.
This document is based on extensive technical discussion on various
relevant working groups mailing lists and a joint DNSEXT and NGTRANS
meeting at the 51st IETF in August 2001. This document attempts to
capture the sense of the discussions and reflect them in this
document to represent the consensus of the community.
The main arguments and the issues are covered in a separate
document[Tradeoff] that reflects the current understanding of the
issues. This document summarizes the outcome of these discussions.
The issue of the root of reverse IPv6 address map is outside the
scope of this document and is covered in a different
document[RFC3152].
1.1 Standards action taken
This document changes the status of RFCs 2673 and 2874 from Proposed
Standard to Experimental.
Expires 25/March/2002 DNSEXT [Page 2]
INTERNET-DRAFT Representation of IPv6 addresses in DNS. September 2001
2 - IPv6 addresses: AAAA RR vs A6 RR
Working group consensus as perceived by the chairs of the DNSEXT and
NGTRANS working groups is that:
a) AAAA records are preferable at the moment for production
deployment of IPv6, and
b) that A6 records have interesting properties that need to be
better understood before deployment.
c) It is not known if the benefits of A6 outweigh the costs and
risks.
2.1 Rationale
There are several potential issues with A6 RRs that stem directly
from the feature that makes them different from AAAA RRs: the ability
to build up addresses via chaining.
Resolving a chain of A6 RRs involves resolving a series of what are
nearly-independent queries. Each of these sub-queries takes some
non-zero amount of time, unless the answer happens to be in the
resolver's local cache already. Other things being equal, we expect
that the time it takes to resolve an N-link chain of A6 RRs will be
roughly proportional to N. What data we have suggests that users are
already impatient with the length of time it takes to resolve A RRs
in the IPv4 Internet, which suggests that users are not likely to be
patient with significantly longer delays in the IPv6 Internet, but
terminating queries prematurely is both a waste of resources and
another source of user frustration. Thus, we are forced to conclude
that indiscriminate use of long A6 chains is likely to lead to
increased user frustration.
The probability of failure during the process of resolving an N-link
A6 chain also appears to be roughly proportional to N, since each of
the queries involved in resolving an A6 chain has roughly the same
probability of failure as a single AAAA query.
Last, several of the most interesting potential applications for A6
RRs involve situations where the prefix name field in the A6 RR
points to a target that is not only outside the DNS zone containing
the A6 RR, but is administered by a different organization entirely.
While pointers out of zone are not a problem per se, experience both
with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that
pointers to other organizations are often not maintained properly,
perhaps because they're less susceptible to automation than pointers
Expires 25/March/2002 DNSEXT [Page 3]
INTERNET-DRAFT Representation of IPv6 addresses in DNS. September 2001
within a single organization would be.
2.2 Recommended standard action
Based on the perceived consensus, this document recommend that RFC
1886 stay on standards track and be advanced, while moving RFC 2874
to Experimental status.
3 - Bitlabels in the reverse DNS tree
RFC 2673 defines a new DNS label type. This was the first new type
defined since RFC 1035[RFC1035]. Since the development of 2673 it has
been learned that deployment of a new type is difficult since DNS
servers that do not support bitlabels reject queries containing bit
labels as being malformed. The community has also indicated that this
new label type is not needed for mapping reverse addresses.
3.1 Rationale
The hexadecimal text representation of IPv6 addresses appears to be
capable of expressing all of the delegation schemes that we expect to
be used in the DNS reverse tree, since we do not ever expect to see
delegation in the least significant possible hexadecimal label. That
is, we do not ever expect to see an IPv6 address architecture that
advocates address delegation in the least significant four bits of an
IPv6 address.
3.2 Recommended standard action
RFC 2673 standard status is to be changed from Proposed to
Experimental. Future standardization of these documents is to be done
by the DNSEXT working group or its successor.
4 DNAME in IPv6 reverse tree
The issues for DNAME chaining in the reverse tree are substantially
identical to the issues for A6 chaining in the forward tree.
Therefore, in moving RFC 2874 to experimental, the intent of this
document is that use of DNAME RRs in the reverse tree be deprecated.
Expires 25/March/2002 DNSEXT [Page 4]
INTERNET-DRAFT Representation of IPv6 addresses in DNS. September 2001
5 Acknowledgments
This document is based on input from many members of the various IETF
working groups involved in this issues. Special thanks go to the
people that prepared reading material for the joint DNSEXT and
NGTRANS working group meeting at the 51st IETF in London, Rob
Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino,
Christian Huitema. Number of other people have made number of
comments on mailing lists about this issue including Robert Elz ,
Johan Ihren , Bill Manning
6 - Security Considerations:
As this document specifies a course of action, there are no direct
security considerations. There is an indirect security impact of the
choice, in that the relationship between A6 and DNSSEC is not well
understood throughout the community, while the choice of AAAA does
leads to a model for use of DNSSEC in IPv6 networks which parallels
current IPv4 practice.
7 - IANA Considerations:
None.
References:
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification'' STD 13, RFC 1035, November 1987.
[RFC1886] S. Thompson, C. Huitema, ``DNS Extensions to support IP
version 6'', RFC 1886, December 1995.
[RFC2673] M. Crawford ``Binary Labels in the Domain Name System``, RFC
2673, August 1999.
[RFC2874] M. Crawford, C. Huitema, ``DNS Extensions to Support IPv6
Address Aggregation and Renumbering'', RFC 2874, July 2000.
[RFC3152] R. Bush, ``Delegation of IP6.ARPA'', RFC 3152 also BCP0049,
August 2001,
[Tradeoff] R. Austein, ``Tradeoffs in DNS support for IPv6'', Work in
progress, draft-ietf-dnsext-ipv6-dns-tradeoffs-xx.txt, July
2001.
Expires 25/March/2002 DNSEXT [Page 5]
INTERNET-DRAFT Representation of IPv6 addresses in DNS. September 2001
Editors Address
Randy Bush <randy@psg.com>
Alain Durand <alain.durand@sun.com>
Bob Fink <fink@es.net>
Olafur Gudmundsson <ogud@ogud.com>
Tony Hain <hain@tndh.net>
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Expires 25/March/2002 DNSEXT [Page 6]
doc/draft/draft-ietf-dnsop-dontpublish-unreachable-02.txt
-423
View File
@@ -1,423 +0,0 @@
Internet Draft Philip Hazel
draft-ietf-dnsop-dontpublish-unreachable-02.txt University of Cambridge
Valid for six months January 2002
Category: Best Current Practice
IP Addresses that should never appear in the public DNS
Copyright (C) The Internet Society (2002). All Rights Reserved.
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies an Internet Best Current Practice for the
Internet Community. It has two themes. Firstly, it reinforces the
prohibition in [RFC 1918] about the appearance of private IP
addresses in publicly visible DNS records. Secondly, the document
discusses the problems that can be caused by the appearance of public
addresses, or indirect references to them, when the service implied
by the address or reference is inaccessible from the public Internet.
Specifying a blanket prohibition in the second case is difficult
because inaccessibility may arise from many causes, some possibly
legitimate. Instead, the document points out some of the problems
that can arise, and suggests that other means of achieving the
desired effects should be used wherever possible.
1. Introduction
The increasing use of firewalls, NAT boxes, and similar technology
has resulted in the fragmentation of the Internet into regions whose
boundaries do not allow general connectivity. There are two primary
reasons for this:
(1) The perceived shortage of IPv4 addresses has caused increasing
use of private IP network addresses such as 10.0.0.0/8 on LANs. A
number of such private address ranges are designated in [RFC 1918],
and others may be also assigned by IANA.
[Note: For example, there's 169.254/16, which is mentioned in
draft-ietf-zeroconf-ipv4-linklocal-04.txt, but since that's still a
draft, I can't cite it.]
Hosts using private addresses that wish to communicate with the
public Internet must do so via an address translation mechanism such
as a NAT box. This allows a host with a private address to send
packets to public Internet hosts, and to receive replies. However,
unsolicited incoming packets cannot reach these hosts from outside
their own private network.
(2) Increasing security concerns have caused many sites to install
firewalls or to implement restrictions in their boundary routers in
order to lock out certain kinds of connection to their hosts, even
when the hosts are using public Internet addresses, though in many
cases firewalls also provide NAT functionality.
Thus, there are two classes of host which some or all types of
unexpected incoming packet from the public Internet cannot reach.
A number of instances have been observed where IP addresses that are
never accessible from the public Internet have nevertheless been
inserted into resource records in the public DNS. This document seeks
to prohibit such behaviour in the case of truly private addresses,
and to discourage it in the case of public, but unreachable,
addresses.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
The phrase "address record" means an A record or an AAAA record, or
any other kind of name-to-address record that may come into use.
2. Private network addresses
Examples of [RFC 1918] private host addresses are 10.0.0.1 and
172.16.42.53. Packets cannot be routed to such addresses from the
public Internet. [RFC 1918] explains this in section 3, from where
this paragraph is taken:
Because private addresses have no global meaning, routing
information about private networks shall not be propagated on
inter-enterprise links, and packets with private source or
destination addresses should not be forwarded across such links.
Routers in networks not using private address space, especially
those of Internet service providers, are expected to be
configured to reject (filter out) routing information about
private networks.
Because the same private addresses are in use in many different
organizations, they are ambiguous. The appearance of private
addresses in the DNS could therefore lead to unpredictable and
unwanted behaviour. Consider this set of entries:
@ IN MX 10 smtp
smtp IN A 10.1.2.3
smtp IN A 131.111.10.206
The MX record resolves to two IP addresses, one of which is private
and one of which is public. Zones set up in this way have been seen,
and some administrators apparently believe this is useful, because
it allows mail on their local network to be delivered straight to
the internal server (the one with address 10.1.2.3). However, this
approach breaks down when a host on a foreign network that is also
using the address 10.1.2.3 attempts to send mail to the domain.
In section 5 of [RFC 1918] there is a prohibition of the appearance
of private addresses in publicly visible DNS records. It says:
If an enterprise uses the private address space, or a mix of
private and public address spaces, then DNS clients outside of
the enterprise should not see addresses in the private address
space used by the enterprise, since these addresses would be
ambiguous.
The wording "should not" is not a very strong prohibition,
considering the interworking problems that ignoring it can cause.
Therefore, this document makes a stronger statement:
Public DNS zones MUST NOT contain [RFC 1918] addresses, or any other
addresses designated by IANA as private, in any resource records.
3. Public network addresses that are inacessible
The situation with public network addresses is more complicated
because the Internet cannot in general be cleanly divided into
"public" and "private" parts in this case. Examples of situations
where the division is fuzzy are:
(1) A host with a public address that is behind a firewall may be
accessible for SSH sessions, but not for SMTP sessions. That is,
the blocking may apply only to certain ports.
(2) A host with a public address may make certain services available
only to specific client hosts, for example, those in partner
enterprises, or those in a specific geographic area.
(3) A host might respond to incoming packets only if the client host
is using IPsec.
When a host is providing any service at all over the public Internet,
a publicly visible address record is of course required to give
access to that host.
However, for some protocols and services, additional DNS records
are defined that reference hosts' address records. These are the NS
record for name servers, the MX record for SMTP, and the SRV record
for other services. The existence of such indirect records advertises
the availability of the relevant service.
If these services are always inaccessible over the public Internet,
it is bad practice to include the NS, MX or SRV records in public DNS
zones, for the following reason:
A host that tries to connect to an unreachable address (or port)
may not receive an immediate rejection; in many cases the connection
will fail only after a timeout expires. The wasted effort ties up
resources on the calling host and the network, possibly for some
considerable time (SMTP timeouts, for example, are of the order of
minutes). It may also cause a gratuitous slowing down of the
application.
Furthermore, in the case of dial-up connections, ISDN, or other kinds
of usage-based charged network connection, the wasted network
resources may cost real money.
Public DNS zones SHOULD NOT contain NS, MX or SRV records that point
to hosts for which the relevant services are never accessible over the
public Internet. In other words, if there is no host that is able to
make use of the service using the public Internet, the service SHOULD
NOT be publicly advertised.
4. Loopback addresses
The loopback addresses (127.0.0.1 for IPv4 and ::1 for IPv6) are
another form of private address. There has been a practice of including
them in DNS zones for two entirely different reasons.
4.1 The name "localhost"
Some hostmasters include records of this type in their zones:
localhost.some.domain.example. A 127.0.0.1
The reason for doing this is so that other hosts in the domain
that use the DNS for all their name resolution can make use of the
unqualified name "localhost". This works because DNS resolvers
normally add the local enclosing domain to unqualified names.
DNS zones MAY make use of this technique for the name "localhost"
only, if it is required in their environment, but SHOULD avoid it
if possible.
4.2 DNS "black lists"
There is an increasingly popular practice of creating "black
lists" of misbehaving hosts (for example, open mail relays) in
the DNS. The first of these was the "Realtime Blackhole List"
(RBL). Such lists make use of addresses in the 127.0.0.0/8
network in DNS address records to give information about listed
hosts (which are looked up via their inverted IP addresses).
Such records are in specific "black list" domains, and are well
understood not to be invitations to attempt connections to the
addresses they publish.
DNS zones MAY continue to make use of this technique.
4.3 Other uses of loopback networks
Apart from the exceptions mentioned in 4.1 and 4.2 above, the
loopback addresses MUST NOT appear in address records in the public
DNS.
4.4 References to loopback addresses
When address records that contain loopback addresses do exist,
DNS zones MUST NOT contain indirect records (NS, MX or SRV) that
reference them.
5. Alternative techniques
5.1 Splitting DNS zones
A site that is using private addresses may well want to use DNS
lookups for address resolution on its hosts. The lazy way approach is
simply to put the data into the public DNS zone, as in the example
shown in section 2 above. Because this can cause problems for
external hosts, this MUST NOT be done.
One approach that is commonly taken is to run a so-called "split
DNS". Two different authoritative servers are created: one containing
all the zone data is accessible only from within the private network.
External DNS queries are directed to the second server, which
contains a filtered version of the zone, without the private
addresses.
5.2 SMTP servers behind firewalls
The complication of a split DNS is not normally needed if it is only
SMTP traffic that is being blocked to a public address on a host
behind a firewall. Setting up MX records like this:
plc.example. MX 5 mail.plc.example.
MX 10 public.plc.example.
where both hosts have public IP addresses, but the first is blocked
at the firewall, SHOULD NOT be done. Only the publicly accessible
host should be used:
plc.example. MX 10 public.plc.example.
If a split DNS is in use, the host public.plc.example can use the
internal version to route the mail onwards. However, most MTAs have
configuration facilities to allow for explicit routing of mail, without
the need to use a DNS lookup.
5.3 Specification of no SMTP service
MX records that point to host names whose address records specify the
loopback address have been seen in the DNS. This seems to be a
misguided attempt to specify "no SMTP service for this domain" more
positively than just refusing connections to the SMTP port. (A refused
connection is treated as a temporary error, because it might be the
result of a system rebooting, for example.)
If such a facility is required, it SHOULD instead be done by
arranging for the hosts in question to return
554 No SMTP service here
to all SMTP connections.
6. Security Considerations
This document is not known to create new security issues in the DNS,
mail agents, etc. In some sense, it may reduce security exposure by
insisting that a site's inappropriate internal data not be exposed.
7. IANA Considerations
No IANA actions are required by this document.
8. Acknowledgements
Randy Bush read an early draft of this document and suggested several
improvements.
Draft 01 has benefitted from comments made by Daniel Senie, John
Schnizlein, Robert Elz, Bert Hubert, and Stuart Cheshire.
Draft 02 has benefitted from comments made by David Keegel and Simon
Josefsson.
9. Author's Address
Philip Hazel
University of Cambridge Computing Service
New Museums Site, Pembroke Street
Cambridge CB2 3QH, England
Phone: + 44 1223 334714
Email: ph10@cam.ac.uk
10. References
[RFC 1918] Rekhter, Y. et al "Address allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC 2119] Bradner, S."Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11. Changes made during development of this document
This section is provided for the convenients of those tracking the
document. It will be removed from the final draft.
11.1 Changes made to the -00 version to create -01
. While leaving the MUSTs in for truly private addresses, I've tried
to be more "educational" about the case of public addresses that are
inaccessible, and backed down to SHOULD in those cases.
. I've pointed out the lack of a clear-cut public/private boundary,
and tried to make the case for not advertising unavailable services
without being so probititive in the wording. This includes using
"never accessible" instead of "not accessible".
. Changed "hostmaster" to "zone" in a couple of cases.
. Included an example of bad MX practice with an [RFC 1918] address.
. Noted that [RFC 1918] is not the only list of private addresses.
. General tidying of the wording and rearrangement of the material.
. The Post Office changed our postcode!
11.2 Changes made to the -01 version to create -02
. Add NS to MX and SRV as another DNS record that advertises a service
indirectly.
. Changed the address 1.2.3.4 in an example to a genuine real address
to make it quite clear what I mean.
. Added "geographic area" as another example of a service restriction.
. Suggested why people might want something other than "connection
refused" from hosts that don't provide SMTP service.
. Some other very minor rewording.
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
doc/draft/draft-ietf-dnsop-resolver-rollover-01.txt
-19
View File
@@ -1,19 +0,0 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
O. Kolkman: okolkman@ripe.net
doc/draft/draft-ietf-ipngwg-rfc2553bis-08.txt
-2044
View File
File diff suppressed because it is too large Load Diff
doc/draft/draft-ietf-ipv6-prefix-delegation-requirement-00.txt
-360
View File
@@ -1,360 +0,0 @@
Internet Engineering Task Force Shin Miyakawa
INTERNET-DRAFT NTT Communications
<draft-ietf-ipv6-prefix-delegation-requirement-00.txt>
Expires: May 1, 2003
Nov 1, 2002
Requirements for IPv6 prefix delegation
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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 view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
The internet-draft will expire in 6 months. The date of expiration will
be May 1, 2003.
Abstract
This document describes requirements about how an IPv6 address prefix
should be delegated to an IPv6 subscriber's network (or "site").
Motivation
With the deployment of IPv6 [Deering, 1998] ,several commercial ISPs
are ready to offer their services to the public in conjunction with
widely deployed IP subscription method such as ADSL and so on. But,
thinking about following situation of IPv6 commercial service as one
of the most likely examples,
IPv6 ISP router
|
| point-to-point link
|
User's Site router
|
----+----- User's Site Network
though it is needed a standardized way to delegate one or more IPv6
address prefix(es) from the IPv6 ISP to the User's site
automatically, it is not identified clearly yet.
Originally, it seemed that just RA (Router Avertisement) considered
as good enough to be used for P-P link between ISP and User's site,
but according to the NCCs' recommendations, one site should be
delegated /48 usually.
So, ISP which now would like to start its own IPv6 commercial service
TODAY, need to have some method other than RA protocol which only can
handle one signle /64 prefix but something else or enhanced
- to delegate not just one signle /64 prefix to the user - to satisfy
all the other (standard) requirements which is needed to realize
commercial service
Therefore, this documents clarifies requirements for IPv6 address
prefix delegation from the ISP to the site, especially from the
(commercial) ISP point of view to boost IPv6 business quick as
possible.
Requirements for prefix delegation management
Focusing commercial IPv6 ISP service, there are several kinds of
category of requirements for the mechanism / protocol to delegate one
or more IPv6 prefixes from ISP to a site.
- layer 2 consideration
The method should work on any layer 2 technologies. In other words,
it should be layer 2 technology independent. Though, at the same
time, it should be noted that now ISP would like to have a solution
for Point-to-Point link which has own authentication mechanism first.
PPP link with CHAP authentication is a good example. (Simulated)
Ethernet and IEEE802.11 (wireless LAN) should be covered in near
future, but they have low priority (just) for now. It should be
clarified that the method should work with all L2 protocols either
with authentication mechanism or without, but ISP would like to take
advantage of a L2 protocol's authentication mechanism if it exits.
- accounting
It should provide accounting capability such as logging about by
whom, when and what prefix(es) is used for the service with proper
authentication techniques.
- kinds of prefixes
It should be able to delegate both statically and dynamically
assigned prefix assignment by authenticated identification, depended
by resources and/or any reasons.
- negotiation between ISP and site
ISP may deny the service, due to various reasons such as there is no
contract or bad financial credit etc. Also ISP should be able to use
one single technique to pass parameters of the prefix such as scope
(global and/or site), prefix length (/48, /64 or any other length)
and any other appropriate related information to the site. On the
other hand, a site should be able to request multiple prefixes to the
ISP. Also a site should be able to pass parameters of the prefix
such as scope (global and/or site), prefix length (/48, /64 or any
other length), number of prefixes and so on to the ISP to negotiate.
- less impact on ISP equipments
ISP usualy use some kind of equipment to provide subscription service
to the users such as access concentrating router, PPP server and so
on. This may aggregate thousands or more connections toward the
ISP's backbone. Prefix delegation mechanism must be compatible with
this situation.
References Deering, 1998. S. Deering and R. Hinden, "Internet
Protocol, Version 6 (IPv6) Specification", RFC2460 (December 1998).
History
Jun 2002, first draft was presented as personal submission.
At the IETF-54th at Yokohama, it became a working group draft.
Nov 2003, the draft published as -01 draft.
Acknowledgements
People in Internet Association of Japan have gave me a lot of good input.
Team members of NTT Communications IPv6 project, especially Toshi Yamasaki
and Yasuhiro Shirasaki, gave me quite useful suggestions for this
document. Chairs of IETF IPv6 working group especially Bob Hinden
who gave me a good suggestions before I submitted this draft.
Also communications with other folks in the IPv6 community, such
as WIDE/KAME project, IPv6 and DHCP teams in Cisco systems and so on have
been quite helpful. Thanks a lot.
Author's address
Shin Miyakawa, Ph.D
Innovative IP Architecture Center, NTT Communications Corporation
Tokyo, Japan
Tel: +81-3-6800-3262
Fax: +81-3-5265-2990
Email: miyakawa@nttv6.jp
doc/draft/draft-josefsson-siked-framework-00.txt
-672
View File
@@ -1,672 +0,0 @@
Network Working Group S. Josefsson
Internet-Draft RSA Security
Expires: August 23, 2002 W. Griffin
NAI Labs
February 22, 2002
Notes on Application Key Distribution
draft-josefsson-siked-framework-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 23, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The debate over whether to store cryptographic keys used by
applications in the Domain Name System or not has been going on for
some time. There are arguments for and against [6]. This document
tries to take a step further and provides some initial terminology,
problem statement and use cases for storing application keys in DNS,
in order to enable more substantiated input to the discussion. We
mention some proposed solutions so far. We also give some
requirements on a solution (be it DNS based or not) that would
satisfy the use cases.
Josefsson & Griffin Expires August 23, 2002 [Page 1]
Internet-Draft Notes on Application Key Distribution February 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Survey of Proposals . . . . . . . . . . . . . . . . . . . . . 7
7. Requirements on a Solution . . . . . . . . . . . . . . . . . . 9
References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12
Josefsson & Griffin Expires August 23, 2002 [Page 2]
Internet-Draft Notes on Application Key Distribution February 2002
1. Introduction
The intention of this draft is to document some of the discussions
that have taken place on a number of mailing lists, including the
DNSSEC mailing list [8], the DNSEXT mailing list [9], and the KEYDIST
mailing list [10], regarding (primarily) distributing keys for
Internet applications without additional end-user configuration.
The goal of this draft is not to advocate one single solution.
Instead, the goal is to be a first step towards more well-defined
terminology and a framework in which proposed solutions can be
discussed.
A few suggested proposals are discussed in this document.
We acknowledge that all areas discussed in this document need further
work.
Comments and feedback is requested, preferably to the keydist mailing
list [10].
2. Terminology
"Application" or "Internet Application"
Network software that uses Domain names or IP addresses to
communicate with other entities. To operate securely, these
applications usually need cryptographic key material. Examples
of applications under considerations are secure IP-based
communication (IPSEC [12], SSH [13]) and secure email (OpenPGP
[4], S/MIME [14]).
A note on "infrastructure" vs "application" is appropriate as
well, as there has been some confusion about calling IPSEC an
"application". IPSEC is often considered "infrastructure", and
applications are something you build on top of IPSEC. However,
from the point of view of looking up keys for use with IPSEC,
IPSEC behaves like all other clients to the "lookup keys"
system. Hence, we consider the system that provides lookup and
retrieval of application keys the "infrastructure" and all
clients of this infrastructure are "applications". From this
point of view, IPSEC is an application.
"Application Keys"
The piece of information an application needs to establish
secure communication with an entity. This usually includes
cryptographic (public) keys, but may also include other
Josefsson & Griffin Expires August 23, 2002 [Page 3]
Internet-Draft Notes on Application Key Distribution February 2002
information such as an address to the security gateway.
Note that the format of the keys is not fixed, it ranges from
PKIX certificates to raw RSA public keys.
The reason for including "application" in this term is due the
DNS-centered origins of these discussions. Keys in DNS often
refer to DNSSEC [3] keys which are used by DNS itself.
Applications keys, on the other hand, are used by "applications
of DNS", thus "application keys".
"Application Key Infrastructure"
This is the mechanism that provides application key
distribution. The discussions have so far been centered around
using DNS for this purpose. One solution is to simply store
the application keys within DNS, another is to only store a
pointer in DNS, pointing to where the keys can retrieved. The
rationale behind this is that DNS provides name to address
mapping on the Internet, and most applications need to find
keys based on such names. Involving DNS is natural, unless one
aims at replacing or amending the DNS name space.
Note that the infrastructure is in general not assumed to be
secured. That is, e.g., DNSSEC is not assumed to be deployed.
However, some problems and use cases may assume partial or full
deployment of DNSSEC. Also, some problems and use cases may
assume usage of secure peer to peer DNS communication using
TSIG [16].
3. Problem Statement
At least the following two problems has been discussed:
"Opportunistic Encryption" or "Zero configuration security"
Certain applications have a need to find cryptographic keying
material for entities which they have no prior arrangement
with. Examples includes IPSEC and secure email. In both cases
the user only know the address of the remote machine or person,
and need to locate and retrieve the keying material for this
entity.
"Campus-based application key distribution"
Secure remote machine administration requires that keys are
distributed somehow. Mechanisms used by, e.g., SSH include
Josefsson & Griffin Expires August 23, 2002 [Page 4]
Internet-Draft Notes on Application Key Distribution February 2002
retrieving the key from the remote machine and asking the user
if she wants to trust it or not (including a fingerprint of the
key for verification purposes), and later store the keys in a
local file. Other applications have other mechanisms.
The solution to these two problems can be related to DNS. People
ultimately trust names of machines (hostnames) or persons (email
addresses). Making the trust point relate to DNS thus makes sense,
because DNS is used to lookup hostnames and mail servers for email
addresses.
4. Applications
This section discusses how some applications and how they currently
use keys/certificates.
Opportunistic Encryption in IPsec
[17] discusses a protocol for opportunistic encryption in
IPsec. That protocol currently uses a TXT record to store a
Gateway IP address and the public key associated with the
gateway. This TXT record is placed in the reverse map at the
label of the host that is authorizing the gateway to perform
opportunistic IPsec on its behalf.
Opportunistic S/MIME and OpenPGP
S/MIME uses X.509 public key certificates and OpenPGP uses
public key certificates defined by RFC2440. In practice,
S/MIME uses pre-configured CAs in mail readers and OpenPGP
implementations uses web of trust verification possibly aided
by online databases such as pgp.net or keyserver.net. However,
these models are not required by S/MIME or OpenPGP per se, but
this is what is currently deployed.
Secure Shell (SSH)
Secure Shell currently uses a client-side "local database that
associates each host name (as typed by the user) with the
corresponding public host key" [18]. [18] also describes a
heirarchy model of trust, where the clients are configured with
a trusted CA root key, and the "host name-to-key association is
certified by some trusted certification authority."
STIME
[19] defines how NTP uses Public Key Cryptography to
authenticate servers. The protocol assumes, "public encryption
Josefsson & Griffin Expires August 23, 2002 [Page 5]
Internet-Draft Notes on Application Key Distribution February 2002
keys and certificates must be retrievable directly from servers
without requiring secured channels; however, the fundamental
security of identification credentials and public values bound
to those credentials must be a function of external certificate
authorities and/or webs of trust."
5. Use cases
Opportunistic IPSEC
See [17].
Binding Updates for Mobile IP
Assuming DNSSEC is deployed, attaching KEY records for Internet
hosts to achieve secure Binding Updates in Mobile IP is
compelling. It would make it possible for a Mobile Node to
prove that it owns the IP address it claims to do, by providing
a signed statement to a Correspondent Node. The Correspondent
Node would use DNS and DNSSEC to retrieve the hosts' public key
and verify the signed statement. This needs to be combined
with DNS Dynamic Update (authorized by, e.g., a DHCP server) to
allow the Mobile Node to insert its own KEY record into the DNS
space in the visiting network.
Binding Updates for Mobile IP achieved in this manner can be
seen as a special case of Opportunistic IPSEC.
Opportunistic S/MIME and OpenPGP
Storing PGP keys in DNS would be possible using the CERT RR
[5]. The naming standard used could be the suggested one (SOA
translation of email address), or based on the PGP KeyId, e.g.,
0x47114711.dnskeys.net.
SSH with improved DNS public key verification using [20]:
A campus runs SSH and either DNSSEC or TSIG (clients configured
with DNSSEC key or TSIG key) to protect from people that plug
in their laptops and tries to gain unauthorized access using
spoofing techniques. When contacting SSH hosts the first time,
instead of receiving:
The authenticity of host 'cc (195.42.214.244)' can't be established.
RSA key fingerprint is 6b:9a:84:7b:1c:8f:a2:7c:51:e9:2a:a4:04:86:6d:b2.
Are you sure you want to continue connecting (yes/no)?
Josefsson & Griffin Expires August 23, 2002 [Page 6]
Internet-Draft Notes on Application Key Distribution February 2002
which most users is not able to answer correctly, the SSH host
key is retrieved from DNS, verified using the DNSSEC or TSIG,
and the following question might be presented:
The host key of 'cc (195.42.214.244)' authenticated by DNSSEC root 'kth.se'.
RSA key fingerprint is 6b:9a:84:7b:1c:8f:a2:7c:51:e9:2a:a4:04:86:6d:b2.
Are you sure you want to continue connecting (yes/no)?
This enables the user to relate the question to something she
might already trust (the "kth.se" DNS zone). In practice,
administrators will probably configure the SSH client to always
trust certain SSH zone keys and thereby removing the user
interaction completely.
6. Survey of Proposals
"Store application keys in the CERT RR, subtyping for every
applications"
This proposal re-uses the already defined CERT RR, but
clarifies it to be used for non-certificate lookups as well.
Given that the CERT RR allows for PKIX CRLs (which isn't a
certificate), and that from the DNS software's point of view
there is no difference between a certificate and a raw key,
this interpretation have some bearing in the specification.
This would not require any changes to DNS software. It would
make it easy for applications that support more than one format
of applications keys, e.g. both raw key and X.509 certificate.
This proposal may be amended with owner name guidelines, such
as [7] for email applications.
For certificates, no additional security infrastructure is
required. For raw keys DNSSEC, TSIG or similar is required.
"Use APPKEY for raw keys and CERT for certificates, subtyping for
every application"
This is similar to the previous, but that it separates raw keys
from certificate like formats.
This has the same advantages and disadvantages than the
previous proposal, but it does add complexity in case software
supports both raw keys and certificates. It also requires that
DNS administrators and DNS software knows if a certain blob is
a key or certificate when storing it in DNS.
Josefsson & Griffin Expires August 23, 2002 [Page 7]
Internet-Draft Notes on Application Key Distribution February 2002
All APPKEYs must be protected with DNSSEC, TSIG or similar.
All CERT RR do not in principle require DNSSEC, TSIG or similar
but may benefit from it.
"Store referral in DNS, retrieve keys via other protocols"
This is possible now using, e.g., SRV and LDAP.
If raw keys are used, DNSSEC and LDAP over TLS or something
similar is required. If certs are used, plain DNS and LDAP
would work.
However, since there isn't one global PKI, the security offered
by this is not sufficient in general. Consider Alice asking
for Bob's certificate using SRV and LDAP, and receiving a
certificate signed by a CA which Alice does not know or trust.
This model does work well in situations where Alice and Bob
share the same CA or uses cross certified CAs.
"Store referral with fingerprint in DNS, retrieve keys via other
protocols"
This is similar to the previous proposal, but it makes it
possible to chose the security infrastructure that should be
used. Either leverage on DNSSEC, TSIG or similar, or protect
the other protocol with, e.g., TLS, or use certificates (this
assumes that involved entities has a trust relationship with a
common CA).
"Define RR for each application"
This pushes everything onto application designers, forcing them
to write the specification. Then this effort would change into
simply giving recommendations on how to write such
specifications.
Security-wise it gives total flexibility, however each
application need to write a document similar to this discussing
if they need raw keys, certificates etc, and if they will store
the key or certificate in DNS or use a separate protocol. It
also requires that DNS software handles unknown RRs correctly
(or that all new RRs are supported by DNS software directly,
which is unlikely to happen).
Josefsson & Griffin Expires August 23, 2002 [Page 8]
Internet-Draft Notes on Application Key Distribution February 2002
7. Requirements on a Solution
"MUST be possible to locate application keys given only IP address or
hostname, and access to standard Internet infrastructure"
Interpretation: This acknowledge that IP addresses and hostnames are
used to find application keys, not X.400 DN or OpenPGP key IDs. It
also acknowledge that user configuration (of e.g. LDAP servers)
should not be necessary. The mechanism should require "zero
configuration" by the end user.
"MUST be possible to secure locating and retrival of the key"
Interpretation: This could be achieved with DNSSEC, DNS TSIG, or
referral from DNS with a key fingerprint in DNS similar to WPKI [14],
or using CMS [14] or TLS [15] with PKIX certificates [11].
"SHOULD be efficient"
Interpretation: UDP would be an advantage, but this is subject to the
size of keying material. Raw keys might fit into UDP, but
certificates will not in general.
"MUST not create operational problems"
Interpretation: E.g., the DNS system should not have operational
problems resulting from this use.
Acknowledgement
Thanks to members of the Namedroppers, DNSSEC and KEYDIST mailing
list.
References
[1] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
1034, November 1987.
[2] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987.
[3] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
Message Format", RFC 2440, November 1998.
[5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
Josefsson & Griffin Expires August 23, 2002 [Page 9]
Internet-Draft Notes on Application Key Distribution February 2002
Domain Name System (DNS)", RFC 2538, March 1999.
[6] Lewis, E., "Discussing Application Public Keys in the DNS", I-D
draft-lewis-siked-dnsargs, February 2002.
[7] Schlyter, J., Josefsson, S. and R. Arends, "Storing
certificates in DNS for email applications", I-D draft-
schlyter-mailcert-dns-00.txt, November 2001.
[8] "DNSSEC Mailing List", Email dnssec@cafax.se.
[9] "DNSEXT Mailing List", Email namedroppers@ops.ietf.org.
[10] "KEYDIST Mailing List", Email keydist@cafax.se.
[11] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Profile", RFC
2459, January 1999.
[12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[13] "Secure Shell Working Group", WWW
http://www.ietf.org/html.charters/secsh-charter.html.
[14] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
1999.
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[16] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[17] Richardsson, M., Redelmeier, D. and H. Spencer, "A method for
doing opportunistic encryption with IKE", I-D draft-richardson-
ipsec-opportunistic-02.txt, September 2001.
[18] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Protocol Architecture", I-D draft-ietf-secsh-
architecture-12.txt, January 2002.
[19] Mills, D., "Public key Cryptography for the Network Time
Protocol Version 2", I-D draft-ietf-stime-ntpauth-03.txt,
February 2002.
[20] Griffin, W., "Storing SSH Host Keys in DNS", I-D draft-ietf-
Josefsson & Griffin Expires August 23, 2002 [Page 10]
Internet-Draft Notes on Application Key Distribution February 2002
secsh-dns-key-format-00.txt, May 2001.
[21] WAP Forum, "WAP Public Key Infrastructure Definition", WAP 217-
WPKI, April 2001.
Authors' Addresses
Simon Josefsson
RSA Security
Arenav„gen 29
Stockholm 121 29
Sweden
Phone: +46 8 7250914
EMail: sjosefsson@rsasecurity.com
Wesley Griffin
NAI Labs
EMail: wgriffin@tislabs.com
Josefsson & Griffin Expires August 23, 2002 [Page 11]
Internet-Draft Notes on Application Key Distribution February 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Josefsson & Griffin Expires August 23, 2002 [Page 12]
doc/draft/draft-zeilenga-ldap-dnsref-02.txt
-283
View File
@@ -1,283 +0,0 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Experimental OpenLDAP Foundation
Expires: 20 May 2002 20 November 2001
Use of DNS SRV in LDAP Named Subordinate References
<draft-zeilenga-ldap-dnsref-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Experimental document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extension Working Group
mailing list <ietf-ldapext@netscape.com>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
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.''
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2001, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Abstract
This document describes how LDAP service location information stored
on DNS SRV resource records may be used to in conjunction with named
subordinate referral objects. This document defines the dNSReferral
object class.
Zeilenga LDAP DNSreferral [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-dnsref-02 20 November 2001
Conventions
Schema definitions are provided using LDAPv3 description formats
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in
this document are to be interpreted as described in BCP 14 [RFC2119].
1. Background and Intended Use
Named subordinate referral [NAMEDREF] defines a specific method for
representing subordinate references in LDAP [RFC2251] directories.
This document describes a mechanism for using LDAP service location
information [LOCATE] available in DNS SRV resource records [RFC2782]
to rewrite select LDAP URLs [RFC2255] returned to clients as referrals
and search continuations.
2. Schema
A dNSReferral object is a directory entry whose structural object
class is the dNSreferral object class.
( 1.3.6.1.4.1.4203.1.4.8 NAME 'dNSReferral'
DESC 'DNS SRV aware named subordinate referral object'
SUP referral STRUCTURAL )
dNSReferral objects SHOULD have distinguished names comprising of RDNs
consisting of only dc (domainComponent) attributes (e.g.,
dc=example,dc=net) as detailed in [RFC2247].
dNSReferral objects SHALL behave like referral objects [NAMEDREF]
except as detailed in the following section.
3. Construction of Referrals and Search References
In the referral processing described by [NAMEDREF], if a LDAP URL with
no hostpart is to be returned to the client as part of a referral or
search continuation, it is replaced with one or more LDAP URLs based
upon service location information.
The server SHOULD obtain service location information [LOCATE] for the
DN [RFC2253] present in (or implied by) the LDAP URL [RFC2255]. If no
service location information is available, the server MUST return the
Zeilenga LDAP DNSreferral [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-dnsref-02 20 November 2001
LDAP URL as described in [NAMEDREF].
Otherwise, the server SHALL replace the LDAP URL with a set of
constructed LDAP URLs. For each service host port pair provided, the
server constructs an LDAP URL by replacing the empty hostport with
concatenation of the service host, ":", and the port.
4. Example
Suppose a directory server contains:
dn: dc=sub,dc=example,dc=net
dc: sub
objectClass: dNSReferral
objectClass: extensibleObject
ref: ldap:///dc=sub,dc=example,dc=net
and DNS holds the following SRV records:
_ldap._tcp.sub.example.net. IN SRV 0 0 389 l1.sub.example.net.
_ldap._tcp.sub.example.net. IN SRV 0 0 389 l2.sub.example.net.
and a client requests a compareRequest with a target DN of
"dc=sub,dc=example,dc=net". In response to this request, the server
would return:
compareResponse "referral" {
ldap://l1.sub.example.net:389/dc=sub,dc=example,dc=net
ldap://l2.sub.example.net:389/dc=sub,dc=example,dc=net
}
5. Security Considerations
This mechanism extends [NAMEDREF] based upon [LOCATE]. The security
considerations discussed in these documents generally apply to the
specification described in this document.
In addition, this mechanism requires the server to make DNS queries.
DNS responses are subject to spoofing. Use of DNSSEC is RECOMMENDED
where appropriate. Also, DNS queries may require significant time and
resources.
6. Acknowledgments
This document is borrows heavily from previous work by IETF LDAPext
Zeilenga LDAP DNSreferral [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-dnsref-02 20 November 2001
Working Group including [NAMEDREF] and [LOCATE].
7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
8. Normative References
[RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14 (Also RFC 2119), March 1997.
[RFC2247] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri,
"Using Domains in LDAP/X.500 Distinguished Names", RFC
2247, January 1998.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2253] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished
Names", RFC 2253, December 1997.
[RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255,
December, 1997.
[RFC2782] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[LOCATE] M. Armijo, P. Leach, L Esibov, RL Morgan. "Discovering LDAP
Services with DNS", draft-ietf-ldapext-locate-xx.txt (work
in progress).
[NAMEDREF] K. Zeilenga (editor), "Named Subordinate References in LDAP
Directories" draft-zeilenga-ldap-namedref-xx.txt (work in
progress)
Full Copyright Statement
Copyright 2001, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
Zeilenga LDAP DNSreferral [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-dnsref-02 20 November 2001
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zeilenga LDAP DNSreferral [Page 5]