home *** CD-ROM | disk | FTP | other *** search
Text File | 1995-11-03 | 61.0 KB | 1,516 lines |
-
-
-
-
-
-
- Network Working Group M. McCahill
- Request For Comments: 1862 University of Minnesota
- Category: Informational J. Romkey, Editor
- M. Schwartz
- University of Colorado
- K. Sollins
- MIT
- T. Verschuren
- SURFnet
- C. Weider
- Bunyip Information Systems, Inc.
- November 1995
-
-
- Report of the IAB Workshop on Internet Information Infrastructure,
- October 12-14, 1994
-
- Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
- Abstract
-
- This document is a report on an Internet architecture workshop,
- initiated by the IAB and held at MCI on October 12-14, 1994. This
- workshop generally focused on aspects of the information
- infrastructure on the Internet.
-
- 1. Introduction
-
- The Internet Architecture Board (IAB) holds occasional workshops
- designed to consider long-term issues and strategies for the
- Internet, and to suggest future directions for the Internet
- architecture. This long-term planning function of the IAB is
- complementary to the ongoing engineering efforts performed by working
- groups of the Internet Engineering Task Force (IETF), under the
- leadership of the Internet Engineering Steering Group (IESG) and area
- directorates.
-
- An IAB-initiated workshop on the architecture of the "information
- infrastructure" of the Internet was held on October 12-14, 1994 at
- MCI in Tysons Corner, Virginia.
-
- In addition to the IAB members, attendees at this meeting included
- the IESG Area Directors for the relevant areas (Applications, User
- Services) and a group of other experts in the following areas:
-
-
-
- McCahill, et al Informational [Page 1]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- gopher, the World Wide Web, naming, WAIS, searching, indexing, and
- library services. The IAB explicitly tried to balance the number of
- attendees from each area of expertise. Logistics limited the
- attendance to about 35, which unfortunately meant that many highly
- qualified experts were omitted from the invitation list.
-
- The objectives of the workshop were to explore the architecture of
- "information" applications on the Internet, to provide the IESG with
- a solid set of recommendations for further work, and to provide a
- place for communication between the communities of people associated
- with the lower and upper layers of the Internet protocol suite, as
- well as allow experience to be exchanged between the communities.
-
- The 34 attendees divided into three "breakout groups" which met for
- the second half of the first day and the entire second day. Each
- group wrote a report of its activities. The reports are contained in
- this document, in addition to a set of specific recommendations to
- the IESG and IETF community.
-
- 2. Summary
-
- Although there were some disagreements between the groups on specific
- functionalities for architectural components, there was broad
- agreement on the general shape of an information architecture and on
- general principles for constructing the architecture. The discussions
- of the architecture generalized a number of concepts that are
- currently used in deployed systems such as the World Wide Web, but
- the main thrust was to define general architectural components rather
- than focus on current technologies.
-
- Research recommendations include:
-
- - increased focus on a general caching and replication architecture
-
- - a rapid deployment of name resolution services, and
-
- - the articulation of a common security architecture for information
- applications.
-
- Procedural recommendations for forwarding this work in the IETF
- include:
-
- - making common identifiers such as the IANA assigned numbers
- available in an on-line database
-
- - tightening the requirements on Proposed Standards to insure that
- they adequately address security
-
-
-
-
- McCahill, et al Informational [Page 2]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- - articulating the procedures necessary to facilitate joining IETF
- working group meetings, and
-
- - reviewing the key distribution infrastructure for use in
- information applications
-
- 3. Group 1 report: The Distributed Database Problem
-
- Elise Gerich, Tim Berners-Lee, Mark McCahill, Dave Sincoskie, Mike
- Schwartz, Mitra, Yakov Rekhter, John Klensin, Steve Crocker, Ton
- Verschuren
-
- Editors: Mark McCahill, Mike Schwartz, Ton Verschuren
-
- 3.1 Problem and Needs
-
- Because of the increasing popularity of accessing networked
- information, current Internet information services are experiencing
- performance, reliability, and scaling problems. These are general
- problems, given the distributed nature of the Internet. Current and
- future applications would benefit from much more widespread use of
- caching and replication.
-
- For instance, popular WWW and Gopher servers experience serious
- overloading, as many thousands of users per day attempt to access
- them simultaneously. Neither of these systems was designed with
- explicit caching or replication support in the core protocol.
- Moreover, because the DNS is currently the only widely deployed
- distributed and replicated data storage system in the Internet, it is
- often used to help support more scalable operation in this
- environment -- for example, storing service-specific pointer
- information, or providing a means of rotating service accesses among
- replicated copies of NCSA's extremely popular WWW server. In most
- cases, such uses of the DNS semantically overload the system. The
- DNS may not be able to stand such "semantic extensions" and continue
- to perform well. It was not designed to be a general-purpose
- replicated distributed database system.
-
- There are many examples of systems that need or would benefit from
- caching or replication. Examples include key distribution for
- authentication services, DHCP, multicast SD, and Internet white
- pages.
-
- To date there have been a number of independent attempts to provide
- caching and replication facilities. The question we address here is
- whether it might be possible to define a general service interface or
- protocol, so that caches and replica servers (implemented in a
- variety of ways to support a range of different situations) might
-
-
-
- McCahill, et al Informational [Page 3]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- interoperate, and so that we might reduce the amount of wasted re-
- implementation effort currently being expended. Replication and
- caching schemes could form a sort of network "middleware" to fulfill
- a common need of distributed services.
-
- It should be noted that it is an open question whether it would be
- feasible to define a unified interface to all caching and replication
- problems. For example, very different considerations must go into
- providing a system to support a nationwide video service for
- 1,000,000 concurrent users than would be needed for supporting
- worldwide accesses to popular WWW pages. We recommend research and
- experimentation to address this more general issue.
-
- 3.2 Characteristics of Solutions
-
- While on the surface caching and replication may appear to occupy two
- ends of a spectrum, further analysis shows that these are two
- different approaches with different characteristics. There are cases
- where a combination of the two techniques is the optimal solution,
- which further complicates the situation.
-
- We can roughly characterize the two approaches as follows:
-
- Caching:
-
- - a cache contains a partial set of data
-
- - a cache is built on demand
-
- - a cache is audience-specific, since the cache is built in
- response to demands of a community
-
- Replication:
-
- - replicated databases contain the entire data set or a
- server-defined subset of a given database
-
- - a replicated database can return an authoritative answer about
- existence of an item
-
- - data is pushed onto the replicating server rather than pulled on
- demand
-
- While there are important differences between caches and replicated
- databases, there are some issues common to both, especially when
- considering how updates and data consistency can be handled.
-
-
-
-
-
- McCahill, et al Informational [Page 4]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- A variety of methods can be used to update caches and replicas:
-
- - master-slave
-
- - peer-to-peer
-
- - flooding techniques (such as that used by NNTP).
-
- Which strategy one chooses influences important characteristics of
- the cache or replicated database, such as:
-
- - consistency of data
-
- - is locking used to achieve consistency? this influences
- performance...
-
- - are there a priori guarantees of existence of an item in the
- database (is the answer authoritative, do you detect conflicts
- after the fact, or is there no guarantee on authoritativeness of
- the answer?)
-
- Consistency guarantees depend on the granularity of synchronization
- (ms, sec, hr, day), and there are cases where it is acceptable to
- trade consistency for better performance or availability. Since there
- is a range of qualities of service with respect to consistency and
- performance, we would like to be able to tune these parameters for a
- given application. However, we recognize that this may not be
- possible in all cases since it is unlikely one can implement a high
- performance solution to all of these problems in a single system.
-
- Beyond simply performing replication or caching, there is a need for
- managing cache and replication servers. There are several models for
- organizing groups of caches/replication servers that range from
- totally adaptive to a rigidly administered, centrally controlled
- model:
-
- - a club model. Minimal administrative overhead to join the club.
- Participation is a function of disk space, CPU, available
- network bandwidth.
-
- - centrally coordinated service. Here administrators can take
- advantage of their knowledge of the system's topology and the
- community they intend to serve. There may be scaling problems
- with this model.
-
- - hybrid combinations of the club and centrally coordinated models
-
-
-
-
-
- McCahill, et al Informational [Page 5]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- There are a couple of models for how to organize the management of a
- group of cooperating servers, but this does not address the question
- of what sorts of commands the manager (be it a person or a program)
- issues to a cache or replicated server. A manager needs to be able to
- address issues on a server such as:
-
- - control of caching algorithms, defining how information is aged
- out of the cache based on disk space, usage demands, etc. This is
- where you would control time-to-live and expiry settings.
-
- - flushing the cache. There are circumstances where the
- information source has become inaccessible and the normal cache
- aging strategy is inappropriate since you will not be able to
- get the information again for an indeterminate amount of time.
-
- - management control might also be a way for information providers
- to control how information is pushed on servers for maintaining
- data consistency, but this raises tricky problems with trust and
- authentication.
-
- Given a common set of management controls needed, a common protocol
- would allow for simplified management of a collection of caching and
- replicating servers since you would be able to both control them with
- a single set of commands and query them about their capabilities. A
- common language/protocol would also allow different implementations
- to interoperate.
-
- Replicating or caching information immediately raises issues of
- billing, access control and authentication. Ignoring authentication
- and access control issues simplifies the replication and caching
- problem a great deal. Exactly who is running the replication or
- caching server makes a big difference in how you approach this issue.
- If the information publisher runs a set of servers, they can easily
- handle billing and authentication. On the other hand, if an
- organization is running a cache on its firewall (a boundary cache),
- and purchasing information from a vendor, there are sticky issues
- regarding intellectual property in this scenario.
-
- Selecting an appropriate cache or replica of a database is simple in
- the case of a captive user group (for instance a company behind a
- firewall). In this case, configuring the user's software to go
- through one or more boundary caches/replication servers directs the
- users to the closest server. In the more general case, there are
- several replicated/cached copies of an object, so you may receive
- several URLs when you resolve a URN. How do you select the best URL?
-
- Either client developers create ad hoc performance metrics or (in an
- ideal world) the lower level protocols would give the client
-
-
-
- McCahill, et al Informational [Page 6]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- application some guidance about the "closest" copy of the object. In
- other words, if better information about network performance was
- available from lower levels of the protocol stack, applications would
- not have to build ad hoc models of network topology
-
- We did not model the functions of a cache/replication server in
- detail, but we did an (incomplete) model of some of the functions
- (see Figure 1). The idea here was to start work on a general form
- which might include features such as a push function for use in both
- maintaining consistency and in preloading information that the
- information publisher believes will be requested in the near future.
-
- Preloading information via a push command might be a function of
- observed behavior patterns (when you ask for A you'll probably want B
- and C). The decision about what to preload can be made either by the
- information publisher or by the cache server. The cache server has
- the advantage that it has better knowledge of the use patterns of its
- community. The distributed nature of links to other servers also
- limit the knowledge of a single information publisher. In any case,
- being able to accurately predict usage patterns can result in
- significant performance enhancements for caches.
-
- Figure 1: a rough cut at functions
-
- requests from client (in)
- |
- |
- |
- \|/
- +---------------------+
- | | (management)
- | cache/replicated db |<--- commands from admins,
- | | publishers, caches
- +---------------------+
- |
- |
- |
- \|/
- requests sent to information providers (out)
-
- in: (requests from a client)
-
- - give me meta-info about cached object (how up-to-date,
- ttl, expiry, signatures/checksum, billing information )
-
- - give me the object
-
- - go get the object from the net
-
-
-
- McCahill, et al Informational [Page 7]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- - cache, what objects should I pre-fetch?
- (this assumes that the client software believes that the
- cache/replica has some knowledge of use patterns and can
- predict what the user will do next)
-
- out: (requests sent to an information publisher or a
- cache further up the food chain)
-
-
-
- - server, do I have latest copy of this object?
-
- - give me object x and the meta data for object x
-
- - I have a copy of object x (announcing you have a copy
- of object x to other caches or URN to URL server)
-
- - info publisher, what objects should I pre-fetch?
- (this assumes that the information publisher has some
- knowledge of use patterns and can predict what the user
- will do next)
-
- management: (commands from administrators, other
- cooperating caches, and object publishers)
-
-
- - turn parameters (e.g. consistency) on/off
-
- - flush the cache
-
- - there's a new version of object x, take it
-
- 3.3 Recommendations
-
- Caching and replication are important pieces of Internet middleware,
- and solutions need to be found soon. Caches and replicas have
- different performance characteristics, and there are cases where a
- combination of the two provides the best solution. There are also
- many strategies for updating and maintaining consistency of caches
- and replicated databases, and we do not believe any single
- implementation can suffice for the broad range of needs in the
- Internet. One possible solution would be to define a general
- protocol for a replicated distributed database and for caching so
- that different information application implementations can
- interoperate and be managed via a common management interface. A
- common protocol would provide a framework for future protocols (e.g.,
- URN2URL, DHCP) or existing protocols (e.g., Gopher or WWW) that
- presently lack a consistent solution.
-
-
-
- McCahill, et al Informational [Page 8]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- 4. Group 2A report: Building an Information Architecture
-
- Karen Sollins, Abel Weinrib, Barry Leiner, Clifford Neuman, Dan
- LaLiberte, Erik Huizer, John Curran, John Klensin, Lixia Zhang,
- Michael Mealling, Mitchell Charity, Mike St. Johns, Paul Mockapetris
-
- This group took as its central agenda exploring an information
- architecture, the services that would instantiate such an
- architecture, and the functional interfaces between a realization of
- such an architecture and both layers on which it would sit and the
- layers that would sit on it. In order to describe an architecture,
- one must describe not only what it includes, but also what it
- excludes.
-
- 4.1. The core model and service structure
-
- The general architecture has as its centerpiece objects, or as they
- are known in the Uniform Resource Identifier Working Group,
- resources. An object in this architecture has several
- characteristics. First, it has an identifier, assigned within the
- context of some namespace. Such an identifier is globally unique and
- will not be reassigned to another object. Thus, it can be said to be
- globally unique for a long time. Because such an identifier must
- remain unique for all time, it cannot contain location-relevant
- information ... locations can and will be reused. Also, since
- resources may appear in zero, one, or many locations simultaneously,
- location-dependent information can lead to a vast number of
- identifiers for an object, which will make it difficult to identify
- separately retrieved copies of an object as being the same object.
- These locations are defined by the supporting layers that provide
- transport and access. Therefore the definition of locations is not
- within the architecture, although their existence is accepted.
- Second, an object will support one or more abstract types. Further
- determination beyond this statement was not made. One can conclude
- from these two points that an object cannot be part of such an
- architected universe without having at least one such identifier and
- without supporting at least one type if it has at least one location.
-
- In addition, the architecture contains several other components.
- First, there will be a prescribed class of objects called links that
- express a relationship among other objects including the nature of
- that relationship. It is through links that composite objects
- composed of related objects can be created and managed. Finally,
- there is a need for several sorts of meta-information, both in order
- to discover identifiers (e.g. for indices and in support of
- searching) and to aid in the process of mapping an identifier to one
- or more potential locations. Both of these sorts of meta-information
- are associated with objects, although they will be used and therefore
-
-
-
- McCahill, et al Informational [Page 9]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- most likely managed differently, to support their distinctive access
- and update requirements.
-
- Given this architecture of information objects, one can identify
- several boundary points. First, something that does not have an
- identifier or type is outside the architecture. Second, the
- architecture does not, at this point, include any statement about
- computations, or communications paradigms other than second-handedly
- by assuming that traversal of links will occur. Third, although
- pre-fetching, caching, and replication are important, such details
- may be hidden from higher level software components, and thus are not
- part of the data model exposed to the application in the normal case
- (though some applications may want to specify such characteristics).
-
- Now one can ask how such a model fits into a layered network model,
- how it might be modularized and realized. We envisioned this
- information layer as an information "wholesale" layer. It provides
- the general, broad model and provision of shared, network-based
- information. Above this sit the "retailers," the marketers or
- providers of information to the marketplace of applications users.
- Below the "wholesalers" lie the providers of "raw materials." Here
- will be the provision of supporting mechanisms and architecture from
- which information objects can come.
-
- The remainder of this group's report describes the modular
- decomposition of the wholesale layer, including the interactions
- among those modules, separate discussions of the interactions first
- between the retail and wholesale layers and then between the
- wholesale and raw material layers. The report concludes with
- recommendations for where the most effective immediate efforts could
- be made to provide for the wholesale layer and make it useful.
-
- 4.2. The Wholesale Layer
-
- In order to realize the information architecture in the network a
- variety of classes of services or functionality must be provided. In
- each case, there will be many instances of a sort of service,
- coordinating to a lesser or greater degree, but all within the
- general Internet model of autonomy and loose federation. There also
- may be variants of any sort of service, to provide more specialized
- or constrained service. In addition, services may exist that will
- provide more than one of these services, where that is deemed useful.
- Each such service will reside in one or more administrative domains
- and may be restricted or managed based on policies of those domains.
- The list of core services is described below. Because there are many
- interdependencies, there may often be forward references in
- describing a service and its relationships to other services.
-
-
-
-
- McCahill, et al Informational [Page 10]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- * RESOURCE DISCOVERY: Much of the activity of resource discovery,
- indexing and searching, will be in the domain of the retailers,
- although there are supporting hooks that can be provided by the
- wholesaler layer as well. A resource discovery service will hold
- mappings from descriptions to identifiers of objects. They will need
- to be queried. Thus there is a general functionality for a wholesale
- layer service that answers queries formulated in certain ways and
- responds with identifiers. The business of on what basis indices are
- computed or how they are managed will be domain specific.
-
- * NAMING or IDENTIFICATION: There are two aspects to assigning an
- identifier to an object, one in the wholesale layer, and one,
- arguably, in the retail layer. In the wholesale layer, one can
- generate identifiers that are guaranteed to be unique. In the retail
- layer one might ask the question about whether two objects are the
- same or different by the rules of an identification authority that
- therefore would determine whether they should bear the same or
- different identification from that authority. It should be noted
- that the URI Working Group has included these two functions in the
- requirements document for URNs.
-
- An identification service will obviously provide functionality to the
- uniqueness authority. It will also provide identification in the
- process of publication of objects, as will be discussed below, in the
- management of resource discovery information, object location and
- storage services, as well as cache and replication management.
-
- * NAME or IDENTIFICATION RESOLUTION: Since identifiers are presumed
- to be location independent, there is a need for a resolution service.
- Such a service may sometimes return other identifiers at this same
- level of abstraction (the equivalent of aliases) or location
- information, the information delivered to a transport service to
- access or retrieve an object.
-
- * OBJECT RETRIEVAL: Object retrieval is tightly coupled to
- resolution, because without resolution it cannot proceed. Object
- retrieval provides the functionality of causing a representation of
- an object to be provided locally to the requester of an object
- retrieval. This may involve the functionality of object publication
- (see below) and object storage, caching and replication services as
- well as the supporting transport facilities.
-
- * OBJECT PUBLICATION: When an object comes into existence in the
- universe of the information infrastructure, it is said to be
- "published." There will be two common scenarios in publication. One
- will be the use of tools to directly enter and create the information
- that comprises an object in the information infrastructure. Thus
- there may be object creation tools visible to users in applications.
-
-
-
- McCahill, et al Informational [Page 11]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- In contrast there may also be tools outside the information
- infrastructure (for example word processing or text editing tools)
- that provide for the entry of data separately from the operation of
- assigning an object an identifier and causing it to support
- information infrastructure definitions of objects. Thus, there will
- also be visible at the interface between the wholesale and retail
- layers the ability to cause some pre-existing data to become one or
- more objects. In addition to interacting with the identification
- service, publication is likely to cause interaction with object
- storage, and possibly caching and replication.
-
- * DEFINITIONS: If the information infrastructure is to both survive
- and evolve over a long time period, we must be prepared for a wide
- variety and growing number of different sorts of information with
- different functionalities that each supports. For objects available
- on the net, the functionality that each provides must be exposed or
- able to be learned. To do this objects must be able to indicate by
- name or identifier the types of functionality they are supporting.
- Given such an identifier, an object is only useful to a client, if
- the client can discover the definition and perhaps a useful
- implementation of the type in question. This will be acquired from a
- definitions service, which will be used in conjunction with
- applications themselves directly, object publication, and object
- retrieval.
-
- * ATTRIBUTE MANAGEMENT: The attributes considered here relate to
- policy, although any understanding of that policy will be above the
- wholesale level. There are, for example, access management and
- copyright attributes. There is a question here about whether there
- is or should be any access time enforcement or only after the fact
- enforcement. The information is likely to be in the form of
- attribute-value pairs and must be able to capture copyright knowledge
- effectively.
-
- * ACCOUNTING: An accounting service provides metering of the use of
- resources. The resources wholly contained in the wholesale layer are
- the services discussed here. It will also be important to provide
- metering tools in the wholesale layer to be used by the retail layer
- to meter usage or content access in that layer. Metering may be used
- for a variety of purposes ranging from providing better utilization
- or service from the resources to pricing and billing. Hence
- accounting services will be used by object storage, caching and
- replication, lower layer networking services, as well as pricing and
- billing services. In the form of content metering it will also
- interact with attribute management.
-
-
-
-
-
-
- McCahill, et al Informational [Page 12]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- * PRICING, BILLING and PAYMENT: Pricing and payment services straddle
- two layers in the information infrastructure. Servers that maintain
- account balances and with which users interact to retrieve and edit
- account information are applications that will be built on top of
- wholesale layer services. Pricing will be determined in the
- applications environment for application level activities. However,
- it must be possible for middle layer services to process payment
- instruments analogous to cash, credit card slips, and checks, without
- an understanding of the specific implementation of the payment
- mechanism. Application programming interfaces supporting payment
- should be provided, and a common tagged representation of payment
- instruments should allow instruments from a variety of payment
- systems to be presented within middle layer protocols.
-
- * OBJECT STORAGE, CACHING and REPLICATION: There is a recognition
- that caching and replication are important, but the discussion of
- that was left to another group that had taken that as the focus of
- their agenda. Object storage will take an object and put it
- somewhere, while maintaining both the identity and nature of the
- object. It is tightly coupled to caching and replication, as well as
- accounting, often in order to determine patterns of caching and
- replication. It is also tightly coupled to object publication,
- translation, and provides interfaces to both supporting storage
- facilities such as local file systems, as well as direct access from
- applications, needing access to objects.
-
- * TRANSLATION: A translation service allows an object to behave with
- a nature different than that it would otherwise support. Thus, for
- example, it might provide a WYSIWYG interface to an object whose
- functionality might not otherwise support that, or it might generate
- text on the fly from an audio stream. Translation services will be
- used by object publication (allowing for identification of an object
- including a translation of it) and with object storage, providing an
- interface only within the wholesale or to the retail layers.
-
- * SERVER AND SERVICE LOCATION: It will be necessary as part of the
- infrastructure to be able to find services of the kinds described
- here and the servers supporting them. This service has direct
- contact with the lower layer of raw materials, in that it will
- provide, in the final analysis, the addresses needed to actually
- locate objects and services using lower level protocols, such as the
- existing access protocols in use today, for example FTP, SMTP, HTTP,
- or TCP. This service will provide functionality directly to resource
- discovery as well as remote object storage services.
-
-
-
-
-
-
-
- McCahill, et al Informational [Page 13]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- * ADAPTIVE GLUE: This is not a single service as much as a
- recognition that there must be a path for a flow of information
- between the network layers and the applications. The application may
- have constraints, based both on its own needs as well as needs of the
- objects in the wholesale layer. Only the application can really know
- what compromises in services provided below are acceptable to it. At
- the same time, the supporting network layers understand what
- qualities of service are available at what price. Hence there is the
- potential for flow of information both up and down through the
- wholesale layer, perhaps mediated by the wholesale layer. Hence the
- adaptive glue has hooks into all three levels.
-
- * SECURITY: Security services will be a critical piece of the
- infrastructure architecture. For any real business to be conducted,
- organizations must make their information available over the network,
- yet they require the ability to control access to that information on
- a per user and per object basis. To account properly for the use of
- higher level services, organization must be able to identify and
- authenticate their users accurately. Finally, payment services must
- be based on security to prevent fraudulent charges, or disclosure of
- compromising information.
-
- The two biggest problems in providing security services at the
- wholesale layer are poor infrastructure and multiple security
- mechanisms that need to be individually integrated with applications.
- The poor state of the infrastructure is the result of a lack of an
- accepted certification hierarchy for authentication. A commonly held
- position is that there will not be a single hierarchy, but there must
- be established authorities whose assertions are widely accepted, who
- indirectly certify the identities of individuals with which one has
- not had prior contact.
-
- Integration with applications is made difficult because, though
- security services are themselves layered upon one another, such
- services do not fit into the information architecture at a single
- layer. By integrating security services with lower layers of the
- information infrastructure, security can be provided to higher
- layers, but some security information, such as client's identity, may
- be needed at higher layers, so such support will not be completely
- transparent. Further, the security requirements for each middle
- layer information service, and of the application itself, must be
- considered and appropriate use must be made of the middle-layer
- security services applied.
-
- Integration with applications will require user demand for security,
- together with common interfaces such as the GSS-API, so that
- applications and middle layer information services can utilize the
- security services that are available, without understanding the
-
-
-
- McCahill, et al Informational [Page 14]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- details of the specific security mechanism that is employed.
-
- * BOOTSTRAPPING: In order for a newly participating machine to join
- the infrastructure, it must have some way of finding out about at
- least one instance of many of the services described here. This can
- be done either by providing it with some form of configuration
- provided by the human bringing it up or by a bootstrapping service.
- The bootstrapping service is more flexible and manageable; it is
- included here in recognition that this information must be provided
- in some form or other. The bootstrapping service will sit directly
- on the raw materials layer and will have contact with all the
- services described here.
-
- This completes the description of the services as identified by this
- group in the wholesale layer. Although this section suggests which
- services have interfaces to the retail and raw materials layers, each
- of these topics will need to be described separately as well, to
- clarify the functionality expected by each layer of the layer below.
-
- 3. Interface to retail layer
-
- The interface to the retail layer is the embodiment of the object
- model and attendant services. Thus the interface provides the
- application environment with a collection of objects having
- identifiers for distinguishing them within the wholesale layer and
- support for a typing or abstract functionality model. It provides
- for the ability to create or import objects into this object world by
- the publication paradigm, and allows objects to evolve to support new
- or evolving functionality through the translation paradigm. Access
- to the objects is provided by object storage, enhanced with caching
- and replication services and mediated by the attributes managed by
- attribute management and accounting or content metering. Discovery
- of resources (figuring out which identifier to be chasing) is
- provided by resource discovery services. Types are registered and
- hence available both as definitions and perhaps in the form of
- implementations from a definition service. Lastly, there is a
- vertical model of providing the two-way services of adaptive glue for
- quality of service negotiation and for security constraints and
- requirements, with access and services at all three layers.
-
- 4. Interface to the raw materials layer
-
- The raw materials layer falls into networking and operating systems.
- Hence it provides all those services currently available from current
- networking and operating systems. Wholesale services such as object
- management will be dependent on local operating system support such
- as a file system, as well as perhaps transport protocols. In fact,
- all instances of any of the above services will be dependent on local
-
-
-
- McCahill, et al Informational [Page 15]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- storage, process management, local access control and other security
- mechanisms, as well as general transport protocols for communications
- both often among services of the same sort and among services
- dependent on each other that may not be collocated. In addition the
- group identified a set of issues that appear important for the
- networking components of the raw materials layer to provide to the
- wholesale layer in addition to the basic best effort transmission
- services that are commonly available. These take the form of a wish
- list with the recognition that they are not all equally easy or
- possible.
-
- * Connectivity: It is useful and important for the operation of
- applications and the wholesale services to understand what
- connectivity is currently available. The group identified four
- categories of connectivity that it would be useful to know about
- represented by four questions:
-
- 1) Is there a wire out of the back of my machine?
-
- 2) Am I connected to a router?
-
- 3) Am I connected to the global internet? (Can I get beyond
- my own domain?)
-
- 4) Am I connected to a specific host?
-
- These are probably in increasing difficulty of knowing.
-
- * Connectivity forecast: Although this is recognized as either
- extremely difficult or impossible to do, some form of connectivity
- forecast would be very useful to the upper layers
-
- * Bandwidth availability and reservation: It is useful for the
- application to know both what bandwidth might be available to it and,
- better yet, for it to be able to make some form of reservation.
-
- * Latency availability and reservation: It is useful for the
- application to know both what latency the network is experiencing
- and, better yet, be able to set limits on it by means of a
- reservation.
-
- * Reliability availability and reservation: Again, reliability
- constraints are important for many applications, although they may
- have differing reliability constraints and may be able to adapt
- differently to different circumstances. But, if the application
- could make a statement (reservation) about what level of
- unreliability it can tolerate, it might be able to make tradeoffs.
-
-
-
-
- McCahill, et al Informational [Page 16]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- * Burstiness support: Although it is unlikely that the network can
- make predictions about the burstiness of its services, if the
- application can predict to the network its burstiness behavior, the
- network might be able to take advantage of that knowledge.
-
- * Service envelope: It is possible that, as an alternative to the
- above four issues, the raw materials layer could negotiate a whole
- service envelope with the layers it is supporting.
-
- * Security availability: In many cases, it will be important for the
- upper layers to be able to know what sorts and levels of security are
- available from the raw materials layer. This is true of both any
- operating system support as well as transmission.
-
- * Cost: If there is to be usage charging at other than fixed flat
- rates, it will be important for applications and users to understand
- what those costs or at least estimates of them will be.
-
- * Policy routing: If it will be important for transport services to
- support policy routing, it will be important for users of the
- transport services to identify into which policy classes they might
- fall.
-
- 4.5. Recommendations
-
- This group has two categories of recommendations. One is those
- services in the wholesale layer that will both be especially useful
- and readily achieved because work is soon to be or already underway.
- The other set of recommendations was a three item rank ordering of
- services that are most important for the lower layer to provide to
- the wholesale layer.
-
- Within the wholesale layer, the first services that should be
- provided are:
-
- * Object retrieval,
-
- * Name resolution,
-
- * Caching and replication.
-
- In addition, the group rank ordered three areas in which there would
- be quick payoff if the raw materials layer could provide them. They
- are:
-
- 1. Connectivity
-
- 2. Bandwidth, latency, and reliability or service envelope
-
-
-
- McCahill, et al Informational [Page 17]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- 3. Security constraints on communication and transactions
-
- 5. Group 2B Report: Components of an Internet Information Architecture
-
- Cecilia Preston, Chris Weider, Christian Huitema, Cliff Lynch, John
- Romkey, Joyce Reynolds, Larry Masinter, Mitra, Jill Foster
-
- Group 2B discussed various aspects of problems in the Internet
- Information Infrastructure, thinking about recommendations to the
- IESG to focus on particular areas, and also paying attention to some
- of the philosophical and economic backgrounds to some of the
- problems. Economics can dictate some points of architecture: one can
- see economically why a publisher might bear the burden of the costs
- of publishing, or a consumer might bear the burden of costs
- associated with consumption, but not how some free-floating third
- party would necessarily bear the costs of providing services (such as
- third-party translators).
-
- The group discussed the following topics:
-
- access(URL)
-
- gateways
-
- URN resolution
-
- definitions
-
- updates
-
- service location
-
- cache & replication
-
- security & authentication
-
- payments, charging
-
- presentation
-
- search & index
-
- metainformation
-
- boot service
-
- general computation
-
-
-
-
- McCahill, et al Informational [Page 18]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- 5.1 URNs
-
- There are several issues in the use of Uniform Resource Names and
- Uniform Resource Locators. URN resolution is a database lookup that
- returns the URLs associated with a URN. The architecture must take
- into account not only how the lookup is performed, but how the
- database is maintained. Both the lookup problem and the update
- problem must be solved at the same time to allow deployment of URNs.
-
- There are at least two problems in human interaction with unique
- names. First, the notion of a unique name is a fallacy. Unique naming
- cannot be enforced. Names may be forged or may simply be duplicated
- due to human error. The architecture must accept this observation and
- still operate in the face of it. Designing for global uniqueness, but
- not requiring it, was adequate. Errors based on names not being
- unique are likely to be insignificant compared to other errors.
-
- Also, people frequently make assertions and assumptions about names
- rather than the documents that are being named. Making assertions
- about names is working at the wrong level of indirection. Making
- assumptions about names, such as determining the contents of the
- named object from the syntax of the name, can lead to nasty
- surprises.
-
- Having a single, unified naming system is vital. While it is healthy
- to have multiple competing forms of other aspects of the information
- architecture, the naming system is what ties it all together. There
- must be only one naming system. If there is more than one, it may not
- be possible to compare names or to lookup locations based on names,
- and we will continue (to our detriment) to use locators rather than
- names.
-
- 5.2 Global Service Location
-
- The IANA has become the central switch point for service
- identification. and recommended that numbers that are formally
- defined and kept in documents for use in distributed information
- systems (for instance, Assigned Numbers) should also be distributed
- online in some kind of database for use by applications. This
- distribution requires both an access method (perhaps multiple access
- methods) and an update method.
-
- 5.3 Security
-
- Issues involving security arose over and over again. Security
- includes things like validation of authority, confidentiality,
- integrity of data, integrity of services, access control. The group
- agreed that, although often overlooked, confidentiality is important,
-
-
-
- McCahill, et al Informational [Page 19]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- and, more strongly: anonymity is important. It should be possible to
- access documents or objects without the architecture requiring you to
- leave digital fingerprints all over the place.
-
- Security must occur on an end-to-end basis. Documents or objects used
- on the Internet may not only traverse the Internet. Relying on
- security mechanisms in the underlying protocol suite does not
- necessarily provide end-to-end authentication or confidentiality.
-
- Currently lower layer security is ill-defined and widely
- unimplemented. Designers building information applications atop the
- Internet currently receive little guidance in how to design security
- features into their applications, leading to weak ad hoc or
- nonexistent security in new applications. Designers are also unclear
- as to how to deal with the "security considerations" section that is
- mandatory in RFCs, and often fill them with boilerplate text.
-
- Furthermore, retrofitting security into existing architectures does
- not work well. The best systems are built considering security from
- the very beginning. Some systems are being designed that, for
- instance, have no place for a digital signature to authenticate the
- data they pass. These issues apply to data management as well.
-
- The group makes the following recommendations to the IESG regarding
- security:
-
- A. Develop and communicate a security model usable by designers of
- information applications - current models are not considered usable.
-
- B. RFC authors should be given advice on what security considerations
- need to be outlined and how to write them. The IESG security area
- should prepare guidelines for writing security considerations.
-
- C. Proposed Standards should not be accepted by the IESG unless they
- really consider security. This will require that recommendations A
- and B have been implemented and that the guidelines have received
- enough visibility to reasonably expect authors to know of their
- existence.
-
- D. Develop security modules usable by the implementors of information
- clients and servers - reusable across many different, heterogeneous
- applications and platforms.
-
- E. Make clear what security services you can expect from the lower
- layers.
-
- F. Make sure that the key distribution infrastructure is reviewed for
- usability by information applications.
-
-
-
- McCahill, et al Informational [Page 20]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- 5.4 Search and Index
-
- Searching is looking through directories that point to information.
- Indexing is scanning information to create directories. A "unified
- directory" is the result of combining several indices.
-
- Indexing is currently done on the Internet via many mechanisms. Given
- the current ad hoc nature of the indexing, information is frequently
- indexed multiple times. This is wasteful, but due to the current
- economics of the Internet, it tends not to cost more money. If the
- Internet (or parts of thereof) transitions to usage based charging,
- it may cost the information provider too much to allow the
- information to be indexed. In general, the provider should have
- control over how the information they control is indexed.
-
- Above all, the architecture should not encourage a situation where
- information is normally not indexed. It should encourage the
- collection of indexing data only a single time. Having a local
- computation of a summary which is sent to a search/index server is
- vastly preferable to having that server "walk the net" to discover
- information to index.
-
- Indexing and search techniques are quite varied. It is quite likely
- that index and search are too close to general computation to try to
- standardize on a single protocol for either. Instead, it is important
- that the architecture allow multiple search techniques. There are
- currently certain types of indices that can only be generated by
- humans because of their level of semantic content. There are large
- differences in the quality and usability of indices that are
- machine-generated vs. human generated.
-
- Unified directories tend to combine indexing results from quite
- different techniques. The architecture should constrain indexing so
- that it remains possible to merge the results of two searches done by
- different protocols or indexing systems. Returning information in
- standard formats such as URNs can help this problem.
-
- Vocabulary issues in search and index are very difficult. The library
- and information services communities do not necessarily use
- vocabulary that is consistent with the IETF community, which can lead
- to difficult misunderstandings.
-
- "Searching the Internet" is an inappropriate attempt to categorize
- the information you're attempting to search. Instead, we search
- certain public spaces on the Internet. The concept of public space
- vs. private space on the Internet deserves further investigation.
-
-
-
-
-
- McCahill, et al Informational [Page 21]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- Indexing can run afoul of access control considerations. Access
- control must be done at the object, but access control information
- should be propagated through indices as well. The index should be
- able to say "you're not allowed to ask that" rather than the user
- attempting to retrieve the object and being denied.
-
- An architectural point was raised that an index query should return
- the same result independent of who is asking. This is an important
- notion in the Domain Name System. This is inconsistent with some
- real-world indexing (for instance, corporate record management
- systems) which doesn't want to admit that some documents exist if
- you're not allowed to read them.
-
- 5.5 Miscellaneous
-
- Electronic mail, netnews, FTP and the web are frequently used to
- access information on the net today. Each protocol seems to provide a
- consistent view of the information on the Internet. In addition, the
- recent popularity of multi-protocol clients such as Mosaic seem to
- imply that the information content of the Internet is uniformly
- retrievable and manageable. This perception is misleading because
- most protocols are used for other applications than they were
- originally designed for. In addition, Telnet, which has no concept of
- information retrieval and management, is often used to access
- information as well, for example in DIALOG and card file accesses.
- Since each protocol has different access and management capabilities,
- the inconsistencies show up in erratic search and retrieval results,
- puzzling error messages, and a basic lack of standard techniques for
- dealing with information. A consistent underlying information
- architecture will go a long way towards alleviating these problems.
-
- As the information architecture develops we should reconsider the
- electronic mail and netnews architecture in terms of the new
- architecture.
-
- The group noted that there have been difficulties in scheduling joint
- working group meetings and recommends that there be a clearly defined
- process inside the IETF to facilitate scheduling such meetings.
-
- 6. Conclusions and Recommendations
-
- The workshop provided an opportunity for ongoing conversations about
- the architecture to continue and also provided space for focused
- examination of some issues and for some new voices and experience
- from other areas of Internet growth to participate in the
- architectural process.
-
-
-
-
-
- McCahill, et al Informational [Page 22]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- Part of the conclusion of the workshop is a set of recommendations to
- the IESG and IETF community.
-
- Recommendations on research/implementation directions:
-
- 1. Caching and replication are important and overlooked pieces of
- Internet middleware. We should do something about it as soon as
- possible, perhaps by defining an architecture and service model for
- common implementation.
-
- 2. Within the 'wholesale' layer, i.e. within the layer which provides
- a consistent view of the information resources available on the
- Internet, the first services that should be provided are:
-
- * Object retrieval,
-
- * Name resolution,
-
- * Caching and replication.
-
- 3. There would be quick payoff if the raw materials layer, i.e. the
- layer in which information resources are physically transmitted to
- computers, could provide the following services:
-
- * Connectivity
-
- * Bandwidth, latency, and reliability or a service envelope
-
- * Security constraints on communication and transactions
-
- 4. Develop security modules usable by the implementors of information
- clients and servers - reusable across many different, heterogeneous
- applications and platforms
-
- Recommendations to the IESG, IETF, and IANA
-
- 1. Numbers that are formally defined and kept in documents in
- distributed information systems (for instance, Assigned Numbers)
- should be available in some kind of database for use by applications.
-
- 2. Develop and communicate a security model usable by designers of
- information applications - current models are not considered usable
- or are not widely accepted on the Internet.
-
- 3. RFC authors should be given advice on how security considerations
- need to be written. The IESG security area should prepare guidelines
- for writing security considerations.
-
-
-
-
- McCahill, et al Informational [Page 23]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- 4. Proposed Standards should not be accepted by the IESG unless they
- really consider security. This will require recommendations 2 and 3
- to be implemented first.
-
- 5. Make clear what security services you can expect from the lower
- layers.
-
- 6. Make sure that the key distribution infrastructure is reviewed for
- usability by information applications.
-
- 7. There needs to be a process inside the IETF for scheduling a joint
- meeting between two working groups - for example, so that the key
- distribution WG can meet jointly with IIIR.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- McCahill, et al Informational [Page 24]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- APPENDIX A - Workshop Organization
-
- The workshop was held at MCI's facility in Tyson Corners, Virginia.
- The workshop organizers and attendees wish to thank MCI for the use
- of their facilities to host the workshop.
-
- All attendees met in joint session for the first half of October 12.
- They then split into three groups. The first group considered the
- "distributed database" problem which has arisen over and over again
- in the design of parts of the Internet. The two other groups met to
- consider a list of issues pertaining to the information
- infrastructure. The groups ran independently until the morning of
- October 14, when they met again in joint session.
-
- The following people attended the workshop:
-
- Abel Weinrib abel@bellcore.com
-
- Barry Leiner BLeiner@ARPA.MIL
-
- Cecilia Preston cpreston@info.berkeley.edu
-
- Chris Weider clw@bunyip.com
-
- Christian Huitema Christian.Huitema@SOPHIA.INRIA.FR
-
- Cliff Lynch calur@uccmvsa.ucop.edu
-
- Clifford Neuman bcn@isi.edu
-
- Dan LaLiberte liberte@ncsa.uiuc.edu
-
- Dave Sincoskie sincos@THUMPER.BELLCORE.COM
-
- Elise Gerich epg@MERIT.EDU
-
- Erik Huizer Erik.Huizer@SURFnet.nl
-
- Jill Foster Jill.Foster@newcastle.ac.uk
-
- John Curran jcurran@near.net
-
- John Klensin klensin@infoods.mit.edu
-
- John Romkey romkey@asylum.sf.ca.us
-
- Joyce Reynolds jkrey@isi.edu
-
-
-
-
- McCahill, et al Informational [Page 25]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- Karen Sollins sollins@lcs.mit.edu
-
- Larry Masinter masinter@parc.xerox.com
-
- Lixia Zhang LIXIA@PARC.XEROX.COM
-
- Mark McCahill mpm@boombox.micro.umn.edu
-
- Michael Mealling Michael.Mealling@oit.gatech.edu
-
- Mitchell Charity mcharity@lcs.mit.edu
-
- Mike Schwartz schwartz@cs.colorado.edu
-
- Mike St. Johns stjohns@DARPA.MIL
-
- Mitra mitra@pandora.sf.ca.us
-
- Paul Mockapetris pvm@zephyr.isi.edu
-
- Steve Crocker Crocker@TIS.COM
-
- Tim Berners-Lee tbl@info.cern.ch
-
- Ton Verschuren Ton.Verschuren@surfnet.nl
-
- Yakov Rekhter yakov@WATSON.IBM.COM
-
- Security Considerations
-
- This memo discusses certain aspects of security and the information
- infrastructure. It contains general recommendations about security
- enhancements required by information applications on the Internet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- McCahill, et al Informational [Page 26]
-
- RFC 1862 IAB Workshop Report November 1995
-
-
- Authors' Addresses
-
- Mark McCahill
- University of Minnesota
- room 190 Shepherd Labs
- 100 Union Street SE
- Minneapolis, MN 55455
- EMail: mpm@boombox.micro.umn.edu
-
-
- John Romkey [Editor]
- 1770 Massachusetts Ave. #331
- Cambridge, MA 02140
- EMail: romkey@apocalypse.org
-
-
- Michael F. Schwartz
- Department of Computer Science
- University of Colorado
- Boulder, CO 80309-0430
- EMail: schwartz@cs.colorado.edu
-
-
- Karen Sollins
- MIT Laboratory for Computer Science
- 545 Technology Square
- Cambridge, MA 02139-1986
- EMail: sollins@lcs.mit.edu
-
-
- Ton Verschuren
- SURFNet
- P.O. Box 19035
- 3501 DA Utrecht
- The Netherlands
- EMail: Ton.Verschuren@surfnet.nl
-
-
- Chris Weider
- Bunyip Information Systems
- 310 St. Catherine St. West
- Suite 300
- Montreal, PQ H2A 2X1
- CANADA
- EMail: clw@bunyip.com
-
-
-
-
-
-
- McCahill, et al Informational [Page 27]
-
-