doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc1125.txt b/doc/rfc/rfc1125.txt
new file mode 100644
index 0000000..5d10c25
--- /dev/null
+++ b/doc/rfc/rfc1125.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                          D. Estrin
+Request for Comments:  1125              USC Computer Science Department
+                                                           November 1989
+
+
+      POLICY REQUIREMENTS FOR INTER ADMINISTRATIVE DOMAIN ROUTING
+
+1  STATUS OF THIS MEMO
+
+   The purpose of this memo is to focus discussion on particular
+   problems in the Internet and possible methods of solution.  No
+   proposed solutions in this document are intended as standards for the
+   Internet.  Rather, it is hoped that a general consensus will emerge
+   as to the appropriate solution to such problems, leading eventually
+   to the development and adoption of standards.  Distribution of this
+   memo is unlimited.
+
+2  ABSTRACT
+
+   Efforts are now underway to develop a new generation of routing
+   protocol that will allow each Administrative Domain (AD) in the
+   growing Internet (and internets in general) to independently express
+   and enforce policies regarding the flow of packets to, from, and
+   through its resources. (FOOTNOTE 1: The material presented here
+   incorporates discussions held with members of the IAB Autonomous
+   Networks Research Group and the Open Routing Working Group.)  This
+   document articulates the requirements for policy based routing and
+   should be used as input to the functional specification and
+   evaluation of proposed protocols.
+
+   Two critical assumptions will shape the type of routing mechanism
+   that is devised: (1) the topological organization of ADs, and (2) the
+   type and variability of policies expressed by ADs.  After justifying
+   our assumptions regarding AD topology we present a taxonomy, and
+   specific examples, of policies that must be supported by a PR
+   protocol.  We conclude with a brief discussion of policy routing
+   mechanisms proposed in previous RFCs (827, 1102, 1104, 1105).  Future
+   RFCs will elaborate on the architecture and protocols needed to
+   support the requirements presented here.
+
+3  BACKGROUND
+
+   The Research Internet has evolved from a single backbone wide area
+   network with many connected campus networks, to an internet with
+   multiple cross-country backbones, regional access networks, and a
+   profusion of campus networks. (FOOTNOTE 2: The term Research Internet
+   refers to a collection of government, university, and some private
+   company, networks that are used by researchers to access shared
+
+
+
+Estrin                                                          [Page 1]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   computing resources (e.g., supercomputers), and for research related
+   information exchange (e.g., distribution of software, technical
+   documents, and email). The networks that make up the Research
+   Internet run the DOD Internet Protocol [1].)  At times during its
+   development the Research Internet topology appeared somewhat chaotic.
+   Overlapping facilities and lateral (as opposed to hierarchical)
+   connections seemed to be the rule rather than the exception.  Today
+   the Research Internet topology is becoming more regular through
+   coordination of agency investment and adoption of a hierarchy similar
+   to that of the telephone networks'.  The result is several
+   overlapping wide area backbones connected to regional networks, which
+   in turn connect to campus networks at universities, research
+   laboratories, and private companies. However, the telephone network
+   has lateral connections only at the highest level, i.e., between long
+   haul carriers.  In the Research Internet there exist lateral
+   connections at each level of the hierarchy, i.e., between campus (and
+   regional) networks as well.
+
+   Additional complexity is introduced in the Research Internet by
+   virtue of connections to private networks. Many private companies are
+   connected to the Research Internet for purposes of research or
+   support activities. These private companies connect in the same
+   manner as campuses, via a regional network or via lateral links to
+   other campuses. However, many companies have their own private wide
+   area networks which physically overlap with backbone and/or regional
+   networks in the research internet, i.e., private vertical bypass
+   links.
+
+   Implicit in this complex topology are organizational boundaries.
+   These boundaries define Administrative Domains (ADs) which preclude
+   the imposition of a single, centralized set of policies on all
+   resources.  The subject of this paper is the policy requirements for
+   resource usage control in the Research Internet.
+
+   In the remainder of this section we describe the policy routing
+   problem in very general terms. Section 4 examines the constraints and
+   requirements that makes the problem challenging, and leads us to
+   conclude that a new generation of routing and resource control
+   protocols are needed. Section 5 provides more detail on our
+   assumptions as to the future topology and configuration of
+   interconnected ADs. We return to the subject of policy requirements
+   in Section 7 and categorize the different types of policies that ADs
+   in the research internet may want to enforce.  Included in this
+   section are examples of FRICC policy statements.  (FOOTNOTE 3: The
+   Federal Research Internet Coordinating Committee (FRICC) is made up
+   of representatives of each of the major agencies that are involved in
+   networking. They have been very effective in coordinating their
+   efforts to eliminate inefficient redundancy and have proposed a plan
+
+
+
+Estrin                                                          [Page 2]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   for the next 10 years of internetworking for the government,
+   scientific, and education community [2].)  Section 7 identifies types
+   of policy statements that are problematic to enforce due to their
+   dynamics, granularity, or performance implications. Several proposed
+   mechanisms for supporting PR (including RFCs 827, 1102, 1104, 1105)
+   are discussed briefly in Section 8. Future RFCs will elaborate on the
+   architecture and protocols needed to support the requirements
+   presented here.
+
+3.1  POLICY ROUTING
+
+   Previous protocols such as the Exterior Gateway Protocol (EGP)[3]
+   embodied a limited notion of policy and ADs. In particular,
+   autonomous system boundaries constrained the flow of routing database
+   information, and only indirectly affected the flow of packets
+   themselves.  We consider an Administrative Domain (AD) to be a set of
+   hosts and network resources (gateways, links, etc.) that is governed
+   by common policies.  In large internets that cross organization
+   boundaries, e.g., the Research Internet, inter-AD routes must be
+   selected according to policy-related parameters such as cost and
+   access rights, in addition to the traditional parameters of
+   connectivity and congestion. In other words, Policy Routing (PR) is
+   needed to navigate through the complex web of policy boundaries
+   created by numerous interconnected ADs. Moreover, each AD has its own
+   privileges and perspective and therefore must make its own evaluation
+   of legal and preferred routes.  Efforts are now underway to develop a
+   new generation of routing protocol that will allow each AD to
+   independently express and enforce policies regarding the flow of
+   packets to, from, and through its resources [4].  (FOOTNOTE 4:  These
+   issues are under investigation by the IAB Autonomous Networks
+   Research Group and the IAB Open Routing Working Group. For further
+   information contact the author.)
+
+   The purpose of this paper is to articulate the requirements for such
+   policy based routing. Two critical assumptions will shape the type of
+   routing mechanism that is devised:
+
+   * The topological organization of ADs, and
+   * The type and variability of policies expressed by ADs.
+
+   We make use of the policies expressed by owners of current Research
+   Internet resources and private networks connected to the Research
+   Internet to generalize types of policies that must be supported. This
+   top down effort must be done with attention to the technical
+   implications of the policy statements if the result is to be useful
+   in guiding technical development. For example, some ADs express the
+   desire to enforce local constraints over how packets travel to their
+   destination. Other ADs are only concerned with preventing use of
+
+
+
+Estrin                                                          [Page 3]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   their own network resources by restricting transit.  Still other ADs
+   are concerned primarily with recovering the expense of carrying
+   traffic and providing feedback to users so that users will limit
+   their own data flows; in other words they are concerned with
+   charging.  We refer to ADs whose primary concern is communication to
+   and from hosts within their AD as stub and to ADs whose primary
+   concern is carrying packets to and from other ADs as transit}.  If we
+   address control of transit alone, for example, the resulting
+   mechanisms will not necessarily allow an AD to control the flow of
+   its packets from source to destination, or to implement flexible
+   charging schemes.  (FOOTNOTE 5: Gene Tsudik uses the analogy of
+   international travel to express the need for source and transit
+   controls. Each country expresses its own policies about travel to and
+   through its land.  Travel through one country enroute to another is
+   analogous to transit traffic in the network world. A traveler
+   collects policy information from each of the countries of interest
+   and plans an itinerary that conforms to those policies as well as the
+   preferences of the traveler and his/her home nation.  Thus there is
+   both source and transit region control of routing.)  Our purpose is
+   to articulate a comprehensive set of requirements for PR as input to
+   the functional specification, and evaluation, of proposed protocols.
+
+4  WHY THE PROBLEM IS DIFFICULT
+
+   Before proceeding with our description of topology and policy
+   requirements this section outlines several assumptions and
+   constraints, namely: the lack of global authority, the need to
+   support network resource sharing as well as network interconnection,
+   the complex and dynamic mapping of users to ADs and privileges, and
+   the need for accountability across ADs.  These assumptions limit the
+   solution space and raise challenging technical issues.
+
+   The purpose of policy based routing is to allow ADs to interconnect
+   and share computer and network resources in a controlled manner.
+   Unlike many other problems of resource control, there is no global
+   authority. Each AD defines its own policies with respect to its own
+   traffic and resources. However, while we assume no global authority,
+   and no global policies, we recognize that complete autonomy implies
+   no dependence and therefore no communication.  The multi-organization
+   internets addressed here have inherent regions of autonomy, as well
+   as requirements for interdependence. Our mechanisms should allow ADs
+   to design their boundaries, instead of requiring that the boundaries
+   be either impenetrable or eliminated.
+
+   One of the most problematic aspects of the policy routing
+   requirements identified here is the need to support both network
+   resource sharing and interconnection across ADs. An example of
+   resource sharing is two ADs (e.g., agencies, divisions, companies)
+
+
+
+Estrin                                                          [Page 4]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   sharing network resources (e.g., links, or gateways and links) to
+   take advantage of economies of scale.  Providing transit services to
+   external ADs is another example of network resource sharing.
+   Interconnection is the more common example of ADs interconnecting
+   their independently used network resources to achieve connectivity
+   across the ADs, i.e., to allow a user in one AD to communicate with
+   users in another AD. In some respects, network resource control is
+   simpler than network interconnection control since the potential
+   dangers are fewer (i.e., denial of service and loss of revenue as
+   compared with a wide range of attacks on end systems through network
+   interconnection). However, controlled network resource sharing is
+   more difficult to support.  In an internet a packet may travel
+   through a number of transit ADs on its way to the destination.
+   Consequently, policies from all transit ADs must be considered when a
+   packet is being sent, whereas for stub-AD control only the policies
+   of the two end point ADs have to be considered. In other words,
+   controlled network resource sharing and transit require that policy
+   enforcement be integrated into the routing protocols themselves and
+   can not be left to network control mechanisms at the end points.
+   (FOOTNOTE 6&7: Another difference is that in the interconnect case,
+   traffic traveling over AD A's network resources always has a member
+   of AD A as its source or destination (or both).  Under resource
+   sharing arrangements members of both AD A and B are connected to the
+   same resources and consequently intra-AD traffic (i.e., packets
+   sourced and destined for members of the same AD) travels over the
+   resources. This distinction is relevant to the writing of policies in
+   terms of principal affiliation.  Economies of scale is one motivation
+   for resource sharing. For example, instead of interconnecting
+   separately to several independent agency networks, a campus network
+   may interconnect to a shared backbone facility.  Today,
+   interconnection is achieved through a combination of AD specific and
+   shared arrangements. We expect this mixed situation to persist for
+   "well-connected" campuses for reasons of politics, economics, and
+   functionality (e.g., different characteristics of the different
+   agency-networks). See Section 5 for more discussion.)
+
+   Complications also result from the fact that legitimate users of an
+   AD's resources are not all located in that AD. Many users (and their
+   computers) who are funded by, or are affiliated with, a particular
+   agency's program reside within the AD of the user's university or
+   research laboratory.  They reside in a campus AD along with users who
+   are legitimate users of other AD resources.  Moreover, any one person
+   may be a legitimate user of multiple AR resources under varying
+   conditions and constraints (see examples in Section 6). In addition,
+   users can move from one AD to another. In other words, a user's
+   rights can not be determined solely based on the AD from which the
+   user's communications originate.  Consequently, PR must not only
+   identify resources, it must identify principals and associate
+
+
+
+Estrin                                                          [Page 5]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   different capabilities and rights with different principals.  (The
+   term principal is taken from the computer security community[7].)
+
+   One way of reducing the compromise of autonomy associated with
+   interconnection is to implement mechanisms that assure
+   accountability} for resources used. Accountability may be enforced a
+   priori, e.g., access control mechanisms applied before resource usage
+   is permitted.  Alternatively, accountability may be enforced after
+   the fact, e.g., record keeping or metering that supports detection
+   and provides evidence to third parties (i.e., non-repudiation).
+   Accountability mechanisms can also be used to provide feedback to
+   users as to consumption of resources. Internally an AD often decides
+   to do away with such feedback under the premise that communication is
+   a global good and should not be inhibited. There is not necessarily a
+   "global good" across AD boundaries. Therefore, it becomes more
+   appropriate to have resource usage visible to users, whether or not
+   actual charging for usage takes place.  Another motivation that
+   drives the need for accountability across AD boundaries is the
+   greater variability in implementations. Different implementations of
+   a single network protocol can vary greatly as to their efficiency
+   [8].  We can not assume control over implementation across AD
+   boundaries.  Feedback mechanisms such as metering (and charging in
+   some cases) would introduce a concrete incentive for ADs to employ
+   efficient and correct implementations.  PR should allow an AD to
+   advertise and apply such accounting measures to inter-AD traffic.
+
+   In summary, the lack of global authority, the need to support network
+   resource sharing as well as network interconnection, the complex and
+   dynamic mapping of users to ADs and rights, and the need for
+   accountability across ADs, are characteristics of inter-AD
+   communications which must be taken into account in the design of both
+   policies and supporting technical mechanisms.
+
+5  TOPOLOGY MODEL OF INTERNET
+
+   Before discussing policies per se, we outline our model of inter-AD
+   topology and how it influences the type of policy support required.
+   Most members of the Internet community agree that the future Internet
+   will connect on the order of 150,000,000 termination points and
+   100,000 ADs. However, there are conflicting opinions as to the AD
+   topology for which we must design PR mechanisms.  The informal
+   argument is described here.
+
+   SIMPLE AD TOPOLOGY AND POLICY MODEL Some members of the Internet
+   community believe that the current complex topology of interconnected
+   ADs is a transient artifact resulting from the evolutionary nature of
+   the Research Internet's history.  (FOOTNOTE 9: David Cheriton of
+   Stanford University articulated this side of the argument at an
+
+
+
+Estrin                                                          [Page 6]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   Internet workshop in Santa Clara, January, 1989). The critical points
+   of this argument relate to topology and policy. They contend that in
+   the long term the following three conditions will prevail:
+
+   * The public carriers will provide pervasive, competitively
+     priced, high speed data services.
+
+   * The resulting topology of ADs will  be
+     stub (not transit) ADs connected to regional
+     backbones, which in turn interconnect via multiple,
+     overlapping long haul backbones, i.e., a  hierarchy with
+     no lateral connections between stub-ADs or regionals,
+     and no vertical bypass links.
+
+   * The policy requirements of the backbone and stub-ADs
+     will be based only on charging for resource usage at the
+     stub-AD to backbone-AD boundary, and to settling accounts
+     between neighboring backbone providers (regional to long haul,
+     and long haul to long haul).
+
+   Under these assumptions, the primary requirement for general AD
+   interconnect is a metering and charging protocol. The routing
+   decision can be modeled as a simple least cost path with the metric
+   in dollars and cents. In other words, restrictions on access to
+   transit services will be minimal and the functionality provided by
+   the routing protocol need not be changed significantly from current
+   day approaches.
+
+   COMPLEX AD TOPOLOGY AND POLICY MODEL The counter argument is that a
+   more complex AD topology will persist. (FOOTNOTE 10:  Much of the
+   remainder of this paper attempts to justify and provide evidence for
+   this statement.) The different assumptions about AD topology lead to
+   the significantly different assumptions about AD policies.
+
+   This model assumes that the topology of ADs will in many respects
+   agree with the previous model of increased commercial carrier
+   participation and resulting hierarchical structure. However, we
+   anticipate unavoidable and persistent exceptions to the hierarchy.
+   We assume that there will be a relatively small number of long haul
+   transit ADs (on the order of 100), but that there may be tens of
+   thousands of regional ADs and hundreds of thousands of stub ADs
+   (e.g., campuses, laboratories, and private companies).  The competing
+   long haul offerings will differ, both in the services provided and in
+   their packaging and pricing.  Regional networks will overlap less and
+   will connect campus and private company networks. However, many
+   stub-ADs will retain some private lateral links for political,
+   technical, and reliability reasons.  For example, political
+   incentives cause organizations to invest in bypass links that are not
+
+
+
+Estrin                                                          [Page 7]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   always justifiable on a strict cost comparison basis; specialized
+   technical requirements cause organizations to invest in links that
+   have characteristics (e.g., data rate, delay, error, security) not
+   available from public carriers at a competitive rate; and critical
+   requirements cause organizations to invest in redundant back up links
+   for reliability reasons.  These exceptions to the otherwise regular
+   topology are not dispensible. They will persist and must be
+   accommodated, perhaps at the expense of optimality; see Section 5 for
+   more detail.  In addition, many private companies will retain their
+   own private long haul network facilities. (FOOTNOTE 11:  While
+   private voice networks also exist, private data networks are more
+   common.  Voice requirements are more standardized because voice
+   applications are more uniform than are data applications, and
+   therefore the commercial services more often have what the voice
+   customer wants at a price that is competitive with the private
+   network option. Data communication requirements are still more
+   specialized and dynamic.  Thus, there is less opportunity for economy
+   of scale in service offerings and it is harder to keep up to date
+   with customer demand. For this reason we expect private data networks
+   to persist for the near future. As the telephone companies begin to
+   introduce the next generation of high speed packet switched services,
+   the scenario should change. However, we maintain that the result will
+   be a predominance, but not complete dominance, of public carrier use
+   for long haul communication.  Therefore, private data networks will
+   persist and the routing architecture must accommodate controlled
+   interconnection.)  Critical differences between the two models follow
+   from the difference in assumptions regarding AD topology. In the
+   complex case, lateral connections must be supported, along with the
+   means to control the use of such connections in the routing
+   protocols.
+
+   The different topologies imply different policy requirements.  The
+   first model assumes that all policies can be expressed and enforced
+   in terms of dollars and cents and distributed charging schemes. The
+   second model assumes that ADs want more varied control over their
+   resources, control that can not be captured in a dollars and cents
+   metric alone. We describe the types of policies to be supported and
+   provide examples in the following section, Section 6. In brief, given
+   private lateral links, ADs must be able to express access and
+   charging related restrictions and privileges that discriminate on an
+   AD basis.  These policies will be diverse, dynamic, and new
+   requirements will emerge over time, consequently support must be
+   extensible.  For example, the packaging and charging schemes of any
+   single long haul service will vary over time and may be relatively
+   elaborate (e.g., many tiers of service, special package deals, to
+   achieve price discrimination).
+
+   Note that these assumptions about complexity do not preclude some
+
+
+
+Estrin                                                          [Page 8]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   collection of ADs from "negotiating away" their policy differences,
+   i.e., forming a federation, and coordinating a simplified inter-AD
+   configuration in order to reduce the requirements for inter-AD
+   mechanisms.  However, we maintain that there will persist collections
+   of ADs that will not and can not behave as a single federation; both
+   in the research community and, even more predominantly, in the
+   broader commercial arena.  Moreover, when it comes to interconnecting
+   across these federations, non-negotiable differences will arise
+   eventually.  It is our goal to develop mechanisms that are applicable
+   in the broader arena.
+
+   The Internet community developed its original protocol suite with
+   only minimal provision for resource control [9].  This was
+   appropriate at the time of development based on the assumed community
+   (i.e., researchers) and the ground breaking nature of the technology.
+   The next generation of network technology is now being designed to
+   take advantage of high speed media and to support high demand traffic
+   generated by more powerful computers and their applications [10].  As
+   with TCP/IP we hope that the technology being developed will find
+   itself applied outside of the research community. This time it would
+   be inexcusable to ignore resource control requirements and not to pay
+   careful attention to their specification.
+
+   Finally, we look forward to the Internet structure taking advantage
+   of economies of scale offered by enhanced commercial services.
+   However, in many respects the problem that stub-ADs may thus avoid,
+   will be faced by the multiple regional and long haul carriers
+   providing the services. The carriers' charging and resource control
+   policies will be complex enough to require routing mechanisms similar
+   to ones being proposed for the complex AD topology case described
+   here.  Whether the network structure is based on private or
+   commercial services, the goal is to construct policy sensitive
+   mechanisms that will be transparent to end users (i.e., the
+   mechanisms are part of the routing infrastructure at the network
+   level, and not an end to end concern).
+
+6  POLICY TYPES
+
+   This section outlines a taxonomy of internet policies for inter-AD
+   topologies that allow lateral and bypass links.  The taxonomy is
+   intended to cover a wide range of ADs and internets. Any particular
+   PR architecture we design should support a significant subset of
+   these policy types but may not support all of them due to technical
+   complexity and performance considerations.  The general taxonomy is
+   important input to a functional specification for PR. Moreover, it
+   can be used to evaluate and compare the suitability and completeness
+   of existing routing architectures and protocols for PR; see Section
+   8.
+
+
+
+Estrin                                                          [Page 9]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   We provide examples from the Research Internet of the different
+   policy types in the form of resource usage policy statements. These
+   statements were collected through interviews with agency
+   representatives, but they do not represent official policy. These
+   sample policy statements should not} be interpreted as agency policy,
+   they are provided here only as examples.
+
+   Internet policies fall into two classes, access and charging.  Access
+   policies specify who can use resources and under what conditions.
+   Charging policies specify the metering, accounting, and billing
+   implemented by a particular AD.
+
+6.1  TAXONOMY OF ACCESS POLICIES
+
+   We have identified the following types of access policies that ADs
+   may wish to enforce. Charging policies are described in the
+   subsequent section. Section 6.3 provides more specific examples of
+   both access and charging policies using FRICC policy statements.
+
+   Access policies typically are expressed in the form: principals of
+   type x can have access to resources of type y under the following
+   conditions, z. The policies are categorized below according to the
+   definition of y and z.  In any particular instance, each of the
+   policy types would be further qualified by definition of legitimate
+   principals, , x, i.e., what characteristics x must have in order to
+   access the resource in question.
+
+   We refer to access policies described by stub and transit ADs.  The
+   two roles imply different motivations for resource control, however
+   the types of policies expressed are similar; we expect the supporting
+   mechanisms to be common as well.
+
+   Stub and transit access policies may specify any of the following
+   parameters:
+
+   * SOURCE/DESTINATION
+   Source/Destination policies prevent or restrict communication
+   originated by or destined for particular ADs (or hosts or user
+   classes within an AD).
+
+   * PATH
+   Path sensitive policies specify which ADs may or may not be passed
+   through en route to a destination. The most general path sensitive
+   policies allow stub and transit ADs to express policies that depend
+   on any component in the AD path. In other words, a stub AD could
+   reject a route based on any AD (or combination of ADs) in the route.
+   Similarly, a transit AD could express a packet forwarding policy that
+   behaves differently depending upon which ADs a packet has passed
+
+
+
+Estrin                                                         [Page 10]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   through, and is going to pass through, en route to the destination.
+   Less ambitious (and perhaps more reasonable) path sensitive policies
+   might only discriminate according to the immediate neighbor ADs
+   through which the packet is traveling (i.e., a stub network could
+   reject a route based on the first transit AD in the route, and a
+   transit AD could express a packet forwarding policy that depends upon
+   the previous, and the subsequent, transit ADs in the route.)
+
+   * QUALITY/TYPE OF SERVICE(QOS OR TOS)
+   This type of policy restricts access to special resources or
+   services.  For example, a special high throughput, low delay link may
+   be made available on a selective basis.
+
+   * RESOURCE GUARANTEE
+   These policies provide a guaranteed percentage of a resource on a
+   selective, as needed basis.  In other words, the resource can be used
+   by others if the preferred-AD's offered load is below the guaranteed
+   level of service.  The guarantee may be to always carry intra-AD
+   traffic or to always carry inter-AD traffic for a specific AD.
+
+   *  TEMPORAL
+   Temporal policies restrict usage based on the time of day or other
+   time related parameters.
+
+   *  HIGH LEVEL PROTOCOL
+   Usage may be restricted to a specific high level protocol such as
+   mail or file transfer. (Alternatively, such policies can be
+   implemented as source/destination policies by configuring a host(s)
+   within an AD as an application relay and composing policy terms that
+   allow inter-AD access to only that host.)
+
+   *  RESOURCE LIMIT
+   There may be a limit on the amount of traffic load a source may
+   generate during a particular time interval, e.g., so many packets in
+   a day, hour, or minute.
+
+   *  AUTHENTICATION REQUIREMENTS
+   Conditions may be specified regarding the authenticability of
+   principal identifying information. Some ADs might require some form
+   of cryptographic proof as to the identity and affiliations of the
+   principal before providing access to critical resources.
+
+   The above policy types usually exist in combination for a particular
+   AD, i.e., an AD's policies might express a combination of transit,
+   source/destination, and QOS restrictions. This taxonomy will evolve
+   as PR is applied to other domains.
+
+   As will be seen in Section 6.3 an AD can express its charging and
+
+
+
+Estrin                                                         [Page 11]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   access policies in a single syntax. Moreover, both stub and transit
+   policies can co-exist. This is important since some ADs operate as
+   both stub and transit facilities and require such hybrid control.
+
+6.2 TAXONOMY OF CHARGING POLICIES
+
+   Stub and transit charging policies  may specify the following
+   parameters:
+
+   *  UNIT OF ACCOUNTING (e.g., dollars or credits).
+   *  BASIS FOR CHARGING (e.g., per Kbyte or per Kpkt).
+   *  ACTUAL CHARGES (e.g., actual numbers such as $.50/Mbyte).
+   *  WHO IS CHARGED OR PAID (e.g., originator of packet,
+      immediate neighbor from whom packet was received, destination
+      of packet, a third party collection agent).
+   *  WHOSE PACKET COUNT is used (e.g., source, destination, the
+      transit AD's own count, the count of some upstream or
+      downstream AD).
+   *  BOUND ON CHARGES (e.g., to limit the  amount that a stub
+      AD is willing to spend, or the amount that a transit AD is
+      willing to carry.)
+
+   The enforcement of these policies may be carried out during route
+   synthesis or route selection [4].
+
+6.3  EXAMPLE POLICY STATEMENTS
+
+   The following policy statements were collected in the fall of 1988
+   through interviews with representatives of the federal agencies most
+   involved in supporting internetworking. Once again we emphasize that
+   these are not official policy statements. They are presented here to
+   provide concrete examples of the sort of policies that agencies would
+   like to enforce.
+
+   Expressing policies as Policy Terms (PTs)
+
+   Each policy is described in English and then expressed in a policy
+   term (PT) notation suggested by Dave Clark in [4].  Each PT
+   represents a distinct policy of the AD that synthesized it.  The
+   format of a PT is:
+
+    [(H{src},AD{src},AD{ent}),(H{dst},AD{dst},AD{exit}),UCI, Cg,Cb]
+
+   Hsrc stands for source host, ADsrc for source AD, ADent for entering
+   AD (i.e., neighboring AD from which traffic is arriving directly),
+   Hdst for destination host, ADdst for destination AD, ADexit for exit
+   AD (i.e.,neighboring AD to which traffic is going directly), UCI for
+   user class identifier, and Cg and Cb for global and bilateral
+
+
+
+Estrin                                                         [Page 12]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   conditions, respectively. The purpose of a PT is to specify that
+   packets from some host, H{src}, (or a group of hosts) in a source AD,
+   AD{src}, are allowed to enter the AD in question via some directly
+   connected AD, AD{ent}, and exit through another directly connected
+   AD, AD{exit}, on its way to a host, H{dst}, (or a group of hosts) in
+   some destination AD, AD{dst}.  User Class Identifier (UCI) allows for
+   distinguishing between various user classes, e.g., Government,
+   Research, Commercial, Contract, etc.  Global Conditions (Cg)
+   represent billing and other variables.  Bilateral Conditions (Cb)
+   relate to agreements between neighboring ADs, e.g., related to
+   metering or charging.  In the example policy terms provided below we
+   make use of the following abbreviations: Fricc for
+   {DOE,NASA,DCA,NSF}, F for Federal Agency, Re for Regional, U for
+   University, Co for Commercial Corporation, and Cc for Commercial
+   Carrier. A hyphen, -, means no applicable matches.
+
+   By examining a PT we can identify the type of policy represented, as
+   per the taxonomy presented earlier.
+
+   *  If an AD specifies a policy term that has a null (-) entry for
+      the ADexit, then it is disallowing transit for some group of users,
+      and it is a transit policy.
+
+   *  If an AD specifies a  policy term that lists itself
+      explicitly as ADsrc or ADdst, it is expressing restrictions on who
+      can access particular resources within its boundaries, or on who inside
+      can obtain external access. In other words the AD is expressing a
+      source/destination policy.
+
+   *  If ADexit or ADentr is specified then the policy expressed is an
+      exit/entrance path policy.
+
+   *  If the global conditions include charging, QOS, resource
+      guarantee,  time of day, higher level application, resource limit, or
+      authentication related information it is obviously a charging, QOS,
+      resource guarantee, temporal, higher level application, resource
+      limit, or authentication policy, respectively.
+
+   As seen below, any one PT typically incorporates a combination of
+   policy types.
+
+6.3.1  THE FRICC
+
+   In the following examples all policies (and PTs) are symmetrical
+   under the assumption that communication is symmetrical.
+
+
+
+
+
+
+Estrin                                                         [Page 13]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+NATIONAL SCIENCE FOUNDATION (NSF)
+
+   1.  NSF will carry traffic for any host connected to a F/Re network
+   talking to any other host connected to a F/Re via any F/Re entry and
+   exit network, so long as there is it is being used for research or
+   support. There is no authentication of the UCI and no per packet
+   charging.  NSFnet is a backbone and so does not connect directly to
+   universities or companies...thus the indication of {F/Re} instead of
+   {F/Re/U/Co} as ADent and ADexit.
+
+   [NSF1:  (*, {F/Re}, {F/Re})(*, {F/Re}, {F/Re}){research,support}
+   {unauthenticated UCI,no-per-pkt charge}{}]
+
+   2.  NSF will carry traffic to user and expert services hosts in NSF
+   AD to/from any F/Re AD, via any F/Re AD. These are the only things
+   that directly connect to NSFnet.
+
+   [NSF2: ({User svcs, Expert Svcs},{NSF},{F/Re})(*,{F/Re},{-}){}{}{}]
+
+DEPARTMENT OF ENERGY (DOE)
+
+   1.  DOE will carry traffic to and from any host directly connected to
+   DOE so long as it is used for research or support. There is no
+   authentication of the UCI and no per packet charging.
+
+   [DOE1: (*,DOE,-)(*,*,*){research,support}
+   {unauthenticated UCI,no-per-packet charge}{}]
+
+   2.  DOE will carry traffic for any host connected to a F/Re network
+   talking to any other host connected to a F/Re via any F/Re entry and
+   exit network without regard to the UCI. There is no authentication of
+   the UCI and no per packet charging. (in other words DOE is more
+   restrictive with its own traffic than with traffic it is carrying as
+   part of a resource sharing arrangement.)
+
+   [DOE2: (*,{F/Re},{F/Re})(*,{F/Re},{F/Re}){}
+   {unauthenticated UCI, no-per-pkt charge}{}]
+
+NATIONAL AERONAUTICS AND SPACE ADMINISTRATION (NASA)
+
+   1.  Nasa will accept any traffic to/from members of the Nasa AD. But
+   no transit. No UCI authentication and no per packet charge.
+
+   [NASA1: (*,*,*)(*,Nasa,-){Nasa-research, support}
+   {unauthenticated UCI,no-per-packet-charge}{}]
+
+   2.  Nasa will carry transit traffic to/from other federal agency
+   networks if it is in support of research, and if the total use of
+
+
+
+Estrin                                                         [Page 14]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   available BW by non-nasa Federal agencies is below n%. NOTE THAT this
+   non-interference policy type needs some more work in terms of
+   integrating it into the routing algorithms. See Section 7.
+
+   [NASA2: (*,{F},*)(*,{F},*){research,support}
+   {per-packet accounting, limited to n% of available BW}{}]
+
+   3.  NASA will carry commercial traffic to federal and regional and
+   university ADs for nasa research or support. But it will not allow
+   transit. The particular entry AD is not important.
+
+   [NASA3: (*,{Co},*} (*,{F/R/U},*) {NASA research,support}
+    {unauthenticated UCI, no per packet charge}{}]
+
+   4.  On a case by case basis NASA may provide access to its resources
+   on a cost reimbursed basis. Transit traffic will not be carried on
+   this basis.
+
+    [NASA4: (*,*,-)(*,*,-){}
+    {per-packet-charge, limited to n% of available BW} {}]
+
+DEFENSE ADVANCED RESEARCH PROJECTS AGENCY (DARPA)
+
+   1.  DARPA will carry traffic to/from any host in DARPA AD from any
+   external host that can get it there so long as UCI is research or
+   support. No UCI authentication or per packet charge.
+
+   [DARPA1: (*,*,*)(*,DARPA,-){research,support}
+   {unauthenticated-UCI, no per packet charge}{}]
+
+   2.  DARPA will carry traffic for any host connected to a F/Re/U/Co
+   network talking to any other host connected to a F/Re/U/Co via any
+   F/Re/U/Co entry and exit network, so long as there is it is being
+   used for research or support, and the network is not heavily
+   congested!!.  There is no authentication of the UCI and no per packet
+   charging.  NOTE: Darpa would like to say something about the need to
+   enter the Darpa AD at the point closest to the destination...but i
+   don't know how to express this...
+
+   DARPA2: (*,{F/R/U/Co},{F/R/U/Co})(*,{F/R/U/Co},{F/R/U/Co})
+   {research,support}{unauthenticated-UCI,no per packet charge,
+   non-interference basis}{}]
+
+DEFENSE COMMUNICATIONS AGENCY (DCA)
+
+   1.  DCA will not carry any transit traffic. It will only accept and
+   send traffic to and from its mailbridge(s) and only from and to hosts
+   on other F/Re nets. All packets are marked and charged for by the
+
+
+
+Estrin                                                         [Page 15]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   kilopacket.
+
+   [DCA1:(mailbridge,DCA,-)(*,{F/Re},{F/Re}){research,support}
+   {unauthenticated UCI, all incoming packets marked, per-kilopacket
+   charge}{}]
+
+6.3.2 THE REGIONALS
+
+   Interviews with regional network administrations are now underway. In
+   general their policies are still in formation due to the relatively
+   recent formation of these regional networks. However, for the sake of
+   illustration we provide an example of a hypothetical regional's
+   network policies.
+
+REGIONAL A
+
+   1.  Regional A will carry traffic from/to any directly connected
+   F/Re/U network to any F/Re/U network via NSF if it is for a research
+   or support UCI. (NSF requires that all Regional networks only pass it
+   traffic that complies with its, NSF's, policies!)
+
+   [Regional A:(*,{F/Re/U},{F/Re/U})(*,{F/Re/U},NSF){research,support}
+   {unauthenticated UCI, no-per-packet charge}{}]
+
+REGIONAL B
+
+   1.  Regional B will carry traffic from/to any directly connected
+   F/Re/U network to any F/Re/U network via a commercial carrier
+   regardless of its UCI. In this case the packets are charged for since
+   the commercial carrier charges per kilopacket.
+
+   [Regional B:(*,{F/Re/U},{F/Re/U})(*,{F/Re/U},Cc){}
+   {unauthenticated UCI, per-kilopacket charge}{}]
+
+6.3.3 CAMPUS AND PRIVATE NETWORKS
+
+   Similar interviews should be conducted with administrators of campus
+   and private networks. However, many aspects of their policies are
+   contingent on the still unresolved policies of the regionals and
+   federal agencies.  In any event, transit policies will be critical
+   for campus and private networks to flexibly control access to lateral
+   links and private wide area networks, respectively. For example, a
+   small set of university and private laboratories may provide access
+   to special gigabit links for particular classes of researchers.  On
+   the other hand, source/destination policies should not be used in
+   place of network level access controls for these end ADs.
+
+
+
+
+
+Estrin                                                         [Page 16]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+6.3.4  COMMERCIAL SERVICES
+
+   Currently commercial communication services play a low level role in
+   most parts of today's Research Internet; they provide the
+   transmission media, i.e.,leased lines. In the future we expect
+   commercial carriers to provide increasingly higher level and enhanced
+   services such as high speed packet switched backbone services.
+   Because such services are not yet part of the Research Internet
+   infrastructure there exist no policy statements.
+
+   Charging and accounting are certain to be an important policy type in
+   this context.  Moreover, we anticipate the long haul services market
+   to be highly competitive. This implies that competing service
+   providers will engage in significant gaming in terms of packaging and
+   pricing of services. Consequently, the ability to express varied and
+   dynamic charging policies will be critical for these ADs.
+
+7  PROBLEMATIC REQUIREMENTS
+
+   Most of this paper has lobbied for articulation of relatively
+   detailed policy statements in order to help define the technical
+   mechanisms needed for enforcement.  We promoted a top down design
+   process beginning with articulation of desired policies.  Now we feel
+   compelled to mention requirements that are clearly problematic from
+   the bottom up perspective of technical feasibility.
+
+   *  Non-interference policies are of the form "I will provide
+      access for principals x to resources y so long as it does not
+      interfere with my internal usage." The problem with such policies
+      is that access to an AD at any point in time is contingent upon a
+      local, highly dynamic, parameter that is not globally available.
+      Therefore such a policy term could well result in looping,
+      oscillations, and excessive route (re)computation overhead,
+      both unacceptable. Consequently, this is one type of policy that
+      routing experts suggest would be difficult to support in a very
+      large decentralized internetwork.
+
+   *  Granularity can also be problematic, but not as devistating as
+      highly dynamic PR contingencies. Here the caution is less specific.
+      Very fine grain policies, which restrict access to particular
+      hosts, or are contingent upon very fine grain user class
+      identification, may be achieved more efficiently with network
+      level access control [11] or end system controls instead of
+      burdening the inter-AD routing mechanism.
+
+   *  Security  is expensive, as always. Routing protocols are subject
+      to fraud through impersonation, data substitution, and denial of
+      service. Some of the proposed mechanisms provide some means for
+
+
+
+Estrin                                                         [Page 17]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+      detection and non-repudiation. However, to achieve a priori
+      prevention of resource misuse is expensive in terms of per
+      connection or per packet cryptographic overhead. For some
+      environments we firmly believe that this will be necessary and
+      we would prefer an architecture that would accommodate such
+      variability [12].
+
+   In general, it is difficult to predict the impact of any particular
+   policy term. Tools will be needed to assist people in writing and
+   validating policy terms.
+
+8  PROPOSED MECHANISMS
+
+   Previous routing protocols have addressed a narrower definition of
+   PR, as appropriate for the internets of their day. In particular, EGP
+   [3], DGP[13], and BGP[6] incorporate a notion of policy restrictions
+   as to where routing database information travels. None are intended
+   to support policy based routing of packets as described here.  More
+   recent routing proposals such as Landmark [14] and Cartesian [15]
+   could be used to restrict packet forwarding but are not suited to
+   source/destination, and some of the condition-oriented, policies. We
+   feel these policy types are critical to support. We note that for
+   environments (e.g., within an AD substructure) in which the simple-
+   AD-topology conjecture holds true, these alternatives may be
+   suitable.
+
+   RFC 1104 [5] provides a good description of shorter term policy
+   routing requirements. Braun classifies three types of mechanisms,
+   policy based distribution of route information, policy based packet
+   forwarding, and policy based dynamic allocation of network resources.
+   The second class is characterized by Dave Clark's PR architecture,
+   RFC 1102 [4]. With respect to the longer term requirements laid out
+   in this document, only this second class is expressive and flexible
+   enough to support the multiplicity of stub and transit policies. In
+   other words, the power of the PR approach (e.g., RFC1102) is not just
+   in the added granularity of control pointed out by Braun, i.e., the
+   ability to specify particular hosts and user classes. Its power is in
+   the ability to express and enforce many types of stub and transit
+   policies and apply them on a discriminatory basis to different ADs.
+   In addition, this approach provides explicit support for stub ADs to
+   control routes via the use of source routing.  (FOOTNOTE 12:
+   Moreover, the source routing approach loosens the requirements for
+   every AD to share a complete view of the entire internet by allowing
+   the source to detect routing loops.)  (FOOTNOTE 13:  The match
+   between RFC1102 and the requirements specified in this document is
+   hardly a coincidence since Clark's paper and discussions with him
+   contributed to the requirements formulation presented here. His work
+   is currently being evaluated and refined by the ANRG and ORWG.)
+
+
+
+Estrin                                                         [Page 18]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+9  SUMMARY
+
+   Along with the emergence of very high speed applications and media,
+   resource management has become a critical issue in the Research
+   Internet and internets in general. A fundamental characteristic of
+   the resource management problem is allowing administratively ADs to
+   interconnect while retaining control over resource usage. However, we
+   have lacked a careful articulation of the types of resource
+   management policies that need to be supported.  This paper addresses
+   policy requirements for the Research Internet.  After justifying our
+   assumptions regarding AD topology we presented a taxonomy and
+   examples of policies that must be supported by a PR protocol.
+
+10  ACKNOWLEDGMENTS
+
+   Members of the Autonomous Networks Research Group and Open Routing
+   Working Group have contributed significantly to the ideas presented
+   here, in particular, Guy Almes, Lee Breslau, Scott Brim, Dave Clark,
+   Marianne Lepp, and Gene Tsudik. In addition, Lee Breslau and Gene
+   Tsudik provided detailed comments on a previous draft. David Cheriton
+   inadvertently caused me to write this document.  Sharon Anderson's
+   contributions deserve special recognition.  The author is supported
+   by research grants from National Science Foundation, AT&T, and GTE.
+
+11   REFERENCES
+
+   [1] J. Postel, Internet Protocol,  Network Information Center, RFC
+       791, September 1981.
+
+   [2] G. Vaudreuil, The Federal Research Internet Coordinating
+       Committee and National Research Network, ACM SIG Computer
+       Communications Review,April 1988.
+
+   [3] E. Rosen, Exterior Gateway Protocol (EGP), Network Information
+       Center, RFC 827, October 1982.
+
+   [4] D. Clark, Policy Routing in Internet Protocols, Network
+       Information Center, RFC 1102, May 1989.
+
+   [5] H.W.Braun, Models of Policy Based Routing, Network Information
+       Center, RFC 1104, June 1989.
+
+   [6] K. Lougheed, Y. Rekhter, A Border Gateway Protocol, Network
+       Information Center, RFC 1105, June 1989.
+
+   [7] J. Saltzer, M. Schroeder, The Protection of Information in
+       Computer Systems, Proceedings of the IEEE, 63, 9 September 1975.
+
+
+
+
+Estrin                                                         [Page 19]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+   [8] V. Jacobson, Congestion Avoidance and Control.  Proceedings of
+       ACM Sigcomm, pp. 106-114, August 1988, Palo Alto, CA.
+
+   [9] David Clark, Design Philosophy of the DARPA Internet Protocols,
+       Proceedings of ACM Sigcomm, pp. 106-114, August 1988, Palo Alto,
+       CA.
+
+  [10] Gigabit Networking Group, B. Leiner, Editor. Critical Issues in
+       High Bandwidth Networking, Network Information Center, RFC 1077,
+       November 1988.
+
+  [11] D. Estrin, J. Mogul and G. Tsudik, Visa Protocols for Controlling
+       Inter-Organizational Datagram Flow, To appear in IEEE Journal on
+       Selected Areas in Communications, Spring 1989.
+
+  [12] D. Estrin and G. Tsudik, Security Issues in Policy Routing, IEEE
+       Symposium on Research in Security and Privacy, Oakland, CA.  May
+       1-3 1989.
+
+  [13]  M. Little, The Dissimilar Gateway Protocol,  Technical report
+
+  [14] P. Tsuchiya, The Landmark Hierarchy: A new hierarchy for routing
+       in very large networks, IEEE SIGCOMM 88, Palo Alto, CA. September
+       1988.
+
+  [15] G. Finn, Reducing the Vulnerability of Dynamic Computer Networks
+       USC/Information Sciences Institute, Technical Report, ISI/RR-88-
+       201 July 1988.
+
+  [16] A. Nakassis Routing Algorithm for Open Routing, Unpublished
+       paper, Available from the author at the National Institute of
+       Standards and Technology (formerly NBS), Washington D.C.
+
+11  SECURITY CONSIDERATIONS
+
+       This memo does not address the security aspects of the issues
+       discussed.
+
+AUTHOR'S ADDRESS:
+
+       Deborah Estrin
+       University of Southern California
+       Computer Science Department
+       Los Angeles, CA 90089-0782
+
+       Phone: (213) 743-7842
+
+       EMail: Estrin@OBERON.USC.EDU
+
+
+
+Estrin                                                         [Page 20]
+
+RFC 1125                  Policy Requirements              November 1989
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Estrin                                                         [Page 21]
+
\ No newline at end of file