Difference between revisions of "RFC1125"
imported>Admin (Created page with " Network Working Group D. Estrin Request for Comments: 1125 USC Computer Science Department ...") |
|||
Line 7: | Line 7: | ||
Network Working Group D. Estrin | Network Working Group D. Estrin | ||
Request for Comments: 1125 USC Computer Science Department | Request for Comments: 1125 USC Computer Science Department | ||
− | + | November 1989 | |
− | + | POLICY REQUIREMENTS FOR INTER ADMINISTRATIVE DOMAIN ROUTING | |
1 STATUS OF THIS MEMO | 1 STATUS OF THIS MEMO | ||
− | The purpose of this memo is to focus discussion on particular | + | The purpose of this memo is to focus discussion on particular |
− | problems in the Internet and possible methods of solution. No | + | problems in the Internet and possible methods of solution. No |
− | proposed solutions in this document are intended as standards for the | + | proposed solutions in this document are intended as standards for the |
− | Internet. Rather, it is hoped that a general consensus will emerge | + | Internet. Rather, it is hoped that a general consensus will emerge |
− | as to the appropriate solution to such problems, leading eventually | + | as to the appropriate solution to such problems, leading eventually |
− | to the development and adoption of standards. Distribution of this | + | to the development and adoption of standards. Distribution of this |
− | memo is unlimited. | + | memo is unlimited. |
2 ABSTRACT | 2 ABSTRACT | ||
− | Efforts are now underway to develop a new generation of routing | + | Efforts are now underway to develop a new generation of routing |
− | protocol that will allow each Administrative Domain (AD) in the | + | protocol that will allow each Administrative Domain (AD) in the |
− | growing Internet (and internets in general) to independently express | + | growing Internet (and internets in general) to independently express |
− | and enforce policies regarding the flow of packets to, from, and | + | and enforce policies regarding the flow of packets to, from, and |
− | through its resources. (FOOTNOTE 1: The material presented here | + | through its resources. (FOOTNOTE 1: The material presented here |
− | incorporates discussions held with members of the IAB Autonomous | + | incorporates discussions held with members of the IAB Autonomous |
− | Networks Research Group and the Open Routing Working Group.) This | + | Networks Research Group and the Open Routing Working Group.) This |
− | document articulates the requirements for policy based routing and | + | document articulates the requirements for policy based routing and |
− | should be used as input to the functional specification and | + | should be used as input to the functional specification and |
− | evaluation of proposed protocols. | + | evaluation of proposed protocols. |
− | Two critical assumptions will shape the type of routing mechanism | + | Two critical assumptions will shape the type of routing mechanism |
− | that is devised: (1) the topological organization of ADs, and (2) the | + | that is devised: (1) the topological organization of ADs, and (2) the |
− | type and variability of policies expressed by ADs. After justifying | + | type and variability of policies expressed by ADs. After justifying |
− | our assumptions regarding AD topology we present a taxonomy, and | + | our assumptions regarding AD topology we present a taxonomy, and |
− | specific examples, of policies that must be supported by a PR | + | specific examples, of policies that must be supported by a PR |
− | protocol. We conclude with a brief discussion of policy routing | + | protocol. We conclude with a brief discussion of policy routing |
− | mechanisms proposed in previous RFCs (827, 1102, 1104, 1105). Future | + | mechanisms proposed in previous RFCs (827, 1102, 1104, 1105). Future |
− | RFCs will elaborate on the architecture and protocols needed to | + | RFCs will elaborate on the architecture and protocols needed to |
− | support the requirements presented here. | + | support the requirements presented here. |
3 BACKGROUND | 3 BACKGROUND | ||
− | The Research Internet has evolved from a single backbone wide area | + | The Research Internet has evolved from a single backbone wide area |
− | network with many connected campus networks, to an internet with | + | network with many connected campus networks, to an internet with |
− | multiple cross-country backbones, regional access networks, and a | + | multiple cross-country backbones, regional access networks, and a |
− | profusion of campus networks. (FOOTNOTE 2: The term Research Internet | + | profusion of campus networks. (FOOTNOTE 2: The term Research Internet |
− | refers to a collection of government, university, and some private | + | refers to a collection of government, university, and some private |
− | company, networks that are used by researchers to access shared | + | 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 | |
− | These | + | 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 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | 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] | ||
− | for the next 10 years of internetworking for the government, | + | RFC 1125 Policy Requirements November 1989 |
− | 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 | + | for the next 10 years of internetworking for the government, |
− | mechanisms for supporting PR (including RFCs 827, 1102, 1104, 1105) | + | scientific, and education community [2].) Section 7 identifies types |
− | are discussed briefly in Section 8. Future RFCs will elaborate on the | + | of policy statements that are problematic to enforce due to their |
− | architecture and protocols needed to support the requirements | + | dynamics, granularity, or performance implications. Several proposed |
− | presented here. | + | 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 | 3.1 POLICY ROUTING | ||
− | Previous protocols such as the Exterior Gateway Protocol (EGP)[3] | + | Previous protocols such as the Exterior Gateway Protocol (EGP)[3] |
− | embodied a limited notion of policy and ADs. In particular, | + | embodied a limited notion of policy and ADs. In particular, |
− | autonomous system boundaries constrained the flow of routing database | + | autonomous system boundaries constrained the flow of routing database |
− | information, and only indirectly affected the flow of packets | + | information, and only indirectly affected the flow of packets |
− | themselves. We consider an Administrative Domain (AD) to be a set of | + | themselves. We consider an Administrative Domain (AD) to be a set of |
− | hosts and network resources (gateways, links, etc.) that is governed | + | hosts and network resources (gateways, links, etc.) that is governed |
− | by common policies. In large internets that cross organization | + | by common policies. In large internets that cross organization |
− | boundaries, e.g., the Research Internet, inter-AD routes must be | + | boundaries, e.g., the Research Internet, inter-AD routes must be |
− | selected according to policy-related parameters such as cost and | + | selected according to policy-related parameters such as cost and |
− | access rights, in addition to the traditional parameters of | + | access rights, in addition to the traditional parameters of |
− | connectivity and congestion. In other words, Policy Routing (PR) is | + | connectivity and congestion. In other words, Policy Routing (PR) is |
− | needed to navigate through the complex web of policy boundaries | + | needed to navigate through the complex web of policy boundaries |
− | created by numerous interconnected ADs. Moreover, each AD has its own | + | created by numerous interconnected ADs. Moreover, each AD has its own |
− | privileges and perspective and therefore must make its own evaluation | + | privileges and perspective and therefore must make its own evaluation |
− | of legal and preferred routes. Efforts are now underway to develop a | + | of legal and preferred routes. Efforts are now underway to develop a |
− | new generation of routing protocol that will allow each AD to | + | new generation of routing protocol that will allow each AD to |
− | independently express and enforce policies regarding the flow of | + | independently express and enforce policies regarding the flow of |
− | packets to, from, and through its resources [4]. (FOOTNOTE 4: These | + | packets to, from, and through its resources [4]. (FOOTNOTE 4: These |
− | issues are under investigation by the IAB Autonomous Networks | + | issues are under investigation by the IAB Autonomous Networks |
− | Research Group and the IAB Open Routing Working Group. For further | + | Research Group and the IAB Open Routing Working Group. For further |
− | information contact the author.) | + | information contact the author.) |
− | The purpose of this paper is to articulate the requirements for such | + | The purpose of this paper is to articulate the requirements for such |
− | policy based routing. Two critical assumptions will shape the type of | + | policy based routing. Two critical assumptions will shape the type of |
− | routing mechanism that is devised: | + | routing mechanism that is devised: |
− | * The topological organization of ADs, and | + | * The topological organization of ADs, and |
− | * The type and variability of policies expressed by ADs. | + | * The type and variability of policies expressed by ADs. |
− | We make use of the policies expressed by owners of current Research | + | We make use of the policies expressed by owners of current Research |
− | Internet resources and private networks connected to the Research | + | Internet resources and private networks connected to the Research |
− | Internet to generalize types of policies that must be supported. This | + | Internet to generalize types of policies that must be supported. This |
− | top down effort must be done with attention to the technical | + | top down effort must be done with attention to the technical |
− | implications of the policy statements if the result is to be useful | + | implications of the policy statements if the result is to be useful |
− | in guiding technical development. For example, some ADs express the | + | in guiding technical development. For example, some ADs express the |
− | desire to enforce local constraints over how packets travel to their | + | desire to enforce local constraints over how packets travel to their |
− | destination. Other ADs are only concerned with preventing use of | + | 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 | + | their own network resources by restricting transit. Still other ADs |
− | traffic and providing feedback to users so that users will limit | + | are concerned primarily with recovering the expense of carrying |
− | their own data flows; in other words they are concerned with | + | traffic and providing feedback to users so that users will limit |
− | charging. We refer to ADs whose primary concern is communication to | + | their own data flows; in other words they are concerned with |
− | and from hosts within their AD as stub and to ADs whose primary | + | charging. We refer to ADs whose primary concern is communication to |
− | concern is carrying packets to and from other ADs as transit}. If we | + | and from hosts within their AD as stub and to ADs whose primary |
− | address control of transit alone, for example, the resulting | + | concern is carrying packets to and from other ADs as transit}. If we |
− | mechanisms will not necessarily allow an AD to control the flow of | + | address control of transit alone, for example, the resulting |
− | its packets from source to destination, or to implement flexible | + | mechanisms will not necessarily allow an AD to control the flow of |
− | charging schemes. (FOOTNOTE 5: Gene Tsudik uses the analogy of | + | its packets from source to destination, or to implement flexible |
− | international travel to express the need for source and transit | + | charging schemes. (FOOTNOTE 5: Gene Tsudik uses the analogy of |
− | controls. Each country expresses its own policies about travel to and | + | international travel to express the need for source and transit |
− | through its land. Travel through one country enroute to another is | + | controls. Each country expresses its own policies about travel to and |
− | analogous to transit traffic in the network world. A traveler | + | through its land. Travel through one country enroute to another is |
− | collects policy information from each of the countries of interest | + | analogous to transit traffic in the network world. A traveler |
− | and plans an itinerary that conforms to those policies as well as the | + | collects policy information from each of the countries of interest |
− | preferences of the traveler and his/her home nation. Thus there is | + | and plans an itinerary that conforms to those policies as well as the |
− | both source and transit region control of routing.) Our purpose is | + | preferences of the traveler and his/her home nation. Thus there is |
− | to articulate a comprehensive set of requirements for PR as input to | + | both source and transit region control of routing.) Our purpose is |
− | the functional specification, and evaluation, of proposed protocols. | + | 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 | 4 WHY THE PROBLEM IS DIFFICULT | ||
− | Before proceeding with our description of topology and policy | + | Before proceeding with our description of topology and policy |
− | requirements this section outlines several assumptions and | + | requirements this section outlines several assumptions and |
− | constraints, namely: the lack of global authority, the need to | + | constraints, namely: the lack of global authority, the need to |
− | support network resource sharing as well as network interconnection, | + | support network resource sharing as well as network interconnection, |
− | the complex and dynamic mapping of users to ADs and privileges, and | + | the complex and dynamic mapping of users to ADs and privileges, and |
− | the need for accountability across ADs. These assumptions limit the | + | the need for accountability across ADs. These assumptions limit the |
− | solution space and raise challenging technical issues. | + | 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 | |
− | users | + | 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 | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | can not be | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | resources | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | Estrin [Page 5] | ||
+ | RFC 1125 Policy Requirements November 1989 | ||
− | different capabilities and rights with different principals. (The | + | different capabilities and rights with different principals. (The |
− | term principal is taken from the computer security community[7].) | + | term principal is taken from the computer security community[7].) |
− | One way of reducing the compromise of autonomy associated with | + | One way of reducing the compromise of autonomy associated with |
− | interconnection is to implement mechanisms that assure | + | interconnection is to implement mechanisms that assure |
− | accountability} for resources used. Accountability may be enforced a | + | accountability} for resources used. Accountability may be enforced a |
− | priori, e.g., access control mechanisms applied before resource usage | + | priori, e.g., access control mechanisms applied before resource usage |
− | is permitted. Alternatively, accountability may be enforced after | + | is permitted. Alternatively, accountability may be enforced after |
− | the fact, e.g., record keeping or metering that supports detection | + | the fact, e.g., record keeping or metering that supports detection |
− | and provides evidence to third parties (i.e., non-repudiation). | + | and provides evidence to third parties (i.e., non-repudiation). |
− | Accountability mechanisms can also be used to provide feedback to | + | Accountability mechanisms can also be used to provide feedback to |
− | users as to consumption of resources. Internally an AD often decides | + | users as to consumption of resources. Internally an AD often decides |
− | to do away with such feedback under the premise that communication is | + | 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 | + | a global good and should not be inhibited. There is not necessarily a |
− | "global good" across AD boundaries. Therefore, it becomes more | + | "global good" across AD boundaries. Therefore, it becomes more |
− | appropriate to have resource usage visible to users, whether or not | + | appropriate to have resource usage visible to users, whether or not |
− | actual charging for usage takes place. Another motivation that | + | actual charging for usage takes place. Another motivation that |
− | drives the need for accountability across AD boundaries is the | + | drives the need for accountability across AD boundaries is the |
− | greater variability in implementations. Different implementations of | + | greater variability in implementations. Different implementations of |
− | a single network protocol can vary greatly as to their efficiency | + | a single network protocol can vary greatly as to their efficiency |
− | [8]. We can not assume control over implementation across AD | + | [8]. We can not assume control over implementation across AD |
− | boundaries. Feedback mechanisms such as metering (and charging in | + | boundaries. Feedback mechanisms such as metering (and charging in |
− | some cases) would introduce a concrete incentive for ADs to employ | + | some cases) would introduce a concrete incentive for ADs to employ |
− | efficient and correct implementations. PR should allow an AD to | + | efficient and correct implementations. PR should allow an AD to |
− | advertise and apply such accounting measures to inter-AD traffic. | + | advertise and apply such accounting measures to inter-AD traffic. |
− | In summary, the lack of global authority, the need to support network | + | In summary, the lack of global authority, the need to support network |
− | resource sharing as well as network interconnection, the complex and | + | resource sharing as well as network interconnection, the complex and |
− | dynamic mapping of users to ADs and rights, and the need for | + | dynamic mapping of users to ADs and rights, and the need for |
− | accountability across ADs, are characteristics of inter-AD | + | accountability across ADs, are characteristics of inter-AD |
− | communications which must be taken into account in the design of both | + | communications which must be taken into account in the design of both |
− | policies and supporting technical mechanisms. | + | policies and supporting technical mechanisms. |
5 TOPOLOGY MODEL OF INTERNET | 5 TOPOLOGY MODEL OF INTERNET | ||
− | Before discussing policies per se, we outline our model of inter-AD | + | Before discussing policies per se, we outline our model of inter-AD |
− | topology and how it influences the type of policy support required. | + | topology and how it influences the type of policy support required. |
− | Most members of the Internet community agree that the future Internet | + | Most members of the Internet community agree that the future Internet |
− | will connect on the order of 150,000,000 termination points and | + | will connect on the order of 150,000,000 termination points and |
− | 100,000 ADs. However, there are conflicting opinions as to the AD | + | 100,000 ADs. However, there are conflicting opinions as to the AD |
− | topology for which we must design PR mechanisms. The informal | + | topology for which we must design PR mechanisms. The informal |
− | argument is described here. | + | 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 | + | Internet workshop in Santa Clara, January, 1989). The critical points |
− | of this argument relate to topology and policy. They contend that in | + | of this argument relate to topology and policy. They contend that in |
− | the long term the following three conditions will prevail: | + | the long term the following three conditions will prevail: |
− | * The public carriers will provide pervasive, competitively | + | * The public carriers will provide pervasive, competitively |
− | + | priced, high speed data services. | |
− | * The resulting topology of ADs will be | + | * 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 | + | * 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 | + | Under these assumptions, the primary requirement for general AD |
− | interconnect is a metering and charging protocol. The routing | + | interconnect is a metering and charging protocol. The routing |
− | decision can be modeled as a simple least cost path with the metric | + | decision can be modeled as a simple least cost path with the metric |
− | in dollars and cents. In other words, restrictions on access to | + | in dollars and cents. In other words, restrictions on access to |
− | transit services will be minimal and the functionality provided by | + | transit services will be minimal and the functionality provided by |
− | the routing protocol need not be changed significantly from current | + | the routing protocol need not be changed significantly from current |
− | day approaches. | + | day approaches. |
− | COMPLEX AD TOPOLOGY AND POLICY MODEL The counter argument is that a | + | COMPLEX AD TOPOLOGY AND POLICY MODEL The counter argument is that a |
− | more complex AD topology will persist. (FOOTNOTE 10: Much of the | + | more complex AD topology will persist. (FOOTNOTE 10: Much of the |
− | remainder of this paper attempts to justify and provide evidence for | + | remainder of this paper attempts to justify and provide evidence for |
− | this statement.) The different assumptions about AD topology lead to | + | this statement.) The different assumptions about AD topology lead to |
− | the significantly different assumptions about AD policies. | + | the significantly different assumptions about AD policies. |
− | This model assumes that the topology of ADs will in many respects | + | This model assumes that the topology of ADs will in many respects |
− | agree with the previous model of increased commercial carrier | + | agree with the previous model of increased commercial carrier |
− | participation and resulting hierarchical structure. However, we | + | participation and resulting hierarchical structure. However, we |
− | anticipate unavoidable and persistent exceptions to the hierarchy. | + | anticipate unavoidable and persistent exceptions to the hierarchy. |
− | We assume that there will be a relatively small number of long haul | + | 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 | + | 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 | + | thousands of regional ADs and hundreds of thousands of stub ADs |
− | (e.g., campuses, laboratories, and private companies). The competing | + | (e.g., campuses, laboratories, and private companies). The competing |
− | long haul offerings will differ, both in the services provided and in | + | long haul offerings will differ, both in the services provided and in |
− | their packaging and pricing. Regional networks will overlap less and | + | their packaging and pricing. Regional networks will overlap less and |
− | will connect campus and private company networks. However, many | + | will connect campus and private company networks. However, many |
− | stub-ADs will retain some private lateral links for political, | + | stub-ADs will retain some private lateral links for political, |
− | technical, and reliability reasons. For example, political | + | technical, and reliability reasons. For example, political |
− | incentives cause organizations to invest in bypass links that are not | + | 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 | |
− | private | + | 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 | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Finally, we look forward to the Internet structure taking advantage | + | collection of ADs from "negotiating away" their policy differences, |
− | of economies of scale offered by enhanced commercial services. | + | i.e., forming a federation, and coordinating a simplified inter-AD |
− | However, in many respects the problem that stub-ADs may thus avoid, | + | configuration in order to reduce the requirements for inter-AD |
− | will be faced by the multiple regional and long haul carriers | + | mechanisms. However, we maintain that there will persist collections |
− | providing the services. The carriers' charging and resource control | + | of ADs that will not and can not behave as a single federation; both |
− | policies will be complex enough to require routing mechanisms similar | + | in the research community and, even more predominantly, in the |
− | to ones being proposed for the complex AD topology case described | + | broader commercial arena. Moreover, when it comes to interconnecting |
− | here. Whether the network structure is based on private or | + | across these federations, non-negotiable differences will arise |
− | commercial services, the goal is to construct policy sensitive | + | eventually. It is our goal to develop mechanisms that are applicable |
− | mechanisms that will be transparent to end users (i.e., the | + | in the broader arena. |
− | mechanisms are part of the routing infrastructure at the network | + | |
− | level, and not an end to end concern). | + | 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 | 6 POLICY TYPES | ||
− | This section outlines a taxonomy of internet policies for inter-AD | + | This section outlines a taxonomy of internet policies for inter-AD |
− | topologies that allow lateral and bypass links. The taxonomy is | + | topologies that allow lateral and bypass links. The taxonomy is |
− | intended to cover a wide range of ADs and internets. Any particular | + | intended to cover a wide range of ADs and internets. Any particular |
− | PR architecture we design should support a significant subset of | + | PR architecture we design should support a significant subset of |
− | these policy types but may not support all of them due to technical | + | these policy types but may not support all of them due to technical |
− | complexity and performance considerations. The general taxonomy is | + | complexity and performance considerations. The general taxonomy is |
− | important input to a functional specification for PR. Moreover, it | + | important input to a functional specification for PR. Moreover, it |
− | can be used to evaluate and compare the suitability and completeness | + | can be used to evaluate and compare the suitability and completeness |
− | of existing routing architectures and protocols for PR; see Section | + | of existing routing architectures and protocols for PR; see Section |
− | 8. | + | 8. |
+ | Estrin [Page 9] | ||
+ | RFC 1125 Policy Requirements November 1989 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Internet policies fall into two classes, access and charging. Access | + | We provide examples from the Research Internet of the different |
− | policies specify who can use resources and under what conditions. | + | policy types in the form of resource usage policy statements. These |
− | Charging policies specify the metering, accounting, and billing | + | statements were collected through interviews with agency |
− | implemented by a particular AD. | + | 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 | 6.1 TAXONOMY OF ACCESS POLICIES | ||
− | We have identified the following types of access policies that ADs | + | We have identified the following types of access policies that ADs |
− | may wish to enforce. Charging policies are described in the | + | may wish to enforce. Charging policies are described in the |
− | subsequent section. Section 6.3 provides more specific examples of | + | subsequent section. Section 6.3 provides more specific examples of |
− | both access and charging policies using FRICC policy statements. | + | both access and charging policies using FRICC policy statements. |
− | Access policies typically are expressed in the form: principals of | + | Access policies typically are expressed in the form: principals of |
− | type x can have access to resources of type y under the following | + | type x can have access to resources of type y under the following |
− | conditions, z. The policies are categorized below according to the | + | conditions, z. The policies are categorized below according to the |
− | definition of y and z. In any particular instance, each of the | + | definition of y and z. In any particular instance, each of the |
− | policy types would be further qualified by definition of legitimate | + | policy types would be further qualified by definition of legitimate |
− | principals, , x, i.e., what characteristics x must have in order to | + | principals, , x, i.e., what characteristics x must have in order to |
− | access the resource in question. | + | access the resource in question. |
− | We refer to access policies described by stub and transit ADs. The | + | We refer to access policies described by stub and transit ADs. The |
− | two roles imply different motivations for resource control, however | + | two roles imply different motivations for resource control, however |
− | the types of policies expressed are similar; we expect the supporting | + | the types of policies expressed are similar; we expect the supporting |
− | mechanisms to be common as well. | + | mechanisms to be common as well. |
− | Stub and transit access policies may specify any of the following | + | Stub and transit access policies may specify any of the following |
− | parameters: | + | parameters: |
− | * SOURCE/DESTINATION | + | * SOURCE/DESTINATION |
− | Source/Destination policies prevent or restrict communication | + | Source/Destination policies prevent or restrict communication |
− | originated by or destined for particular ADs (or hosts or user | + | originated by or destined for particular ADs (or hosts or user |
− | classes within an AD). | + | classes within an AD). |
− | * PATH | + | * PATH |
− | Path sensitive policies specify which ADs may or may not be passed | + | Path sensitive policies specify which ADs may or may not be passed |
− | through en route to a destination. The most general path sensitive | + | through en route to a destination. The most general path sensitive |
− | policies allow stub and transit ADs to express policies that depend | + | 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 | + | 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. | + | 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 | + | Similarly, a transit AD could express a packet forwarding policy that |
− | behaves differently depending upon which ADs a packet has passed | + | 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 | |
− | a | + | 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] | ||
− | access policies in a single syntax. Moreover, both stub and transit | + | RFC 1125 Policy Requirements November 1989 |
− | policies can co-exist. This is important since some ADs operate as | + | |
− | both stub and transit facilities and require such hybrid control. | + | |
+ | 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 | 6.2 TAXONOMY OF CHARGING POLICIES | ||
− | Stub and transit charging policies may specify the following | + | Stub and transit charging policies may specify the following |
− | parameters: | + | parameters: |
− | * UNIT OF ACCOUNTING (e.g., dollars or credits). | + | * UNIT OF ACCOUNTING (e.g., dollars or credits). |
− | * BASIS FOR CHARGING (e.g., per Kbyte or per Kpkt). | + | * BASIS FOR CHARGING (e.g., per Kbyte or per Kpkt). |
− | * ACTUAL CHARGES (e.g., actual numbers such as $.50/Mbyte). | + | * ACTUAL CHARGES (e.g., actual numbers such as $.50/Mbyte). |
− | * WHO IS CHARGED OR PAID (e.g., originator of packet, | + | * 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 | + | * 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 | + | * 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 | + | The enforcement of these policies may be carried out during route |
− | synthesis or route selection [4]. | + | synthesis or route selection [4]. |
6.3 EXAMPLE POLICY STATEMENTS | 6.3 EXAMPLE POLICY STATEMENTS | ||
− | The following policy statements were collected in the fall of 1988 | + | The following policy statements were collected in the fall of 1988 |
− | through interviews with representatives of the federal agencies most | + | through interviews with representatives of the federal agencies most |
− | involved in supporting internetworking. Once again we emphasize that | + | involved in supporting internetworking. Once again we emphasize that |
− | these are not official policy statements. They are presented here to | + | these are not official policy statements. They are presented here to |
− | provide concrete examples of the sort of policies that agencies would | + | provide concrete examples of the sort of policies that agencies would |
− | like to enforce. | + | like to enforce. |
− | Expressing policies as Policy Terms (PTs) | + | Expressing policies as Policy Terms (PTs) |
− | Each policy is described in English and then expressed in a policy | + | Each policy is described in English and then expressed in a policy |
− | term (PT) notation suggested by Dave Clark in [4]. Each PT | + | term (PT) notation suggested by Dave Clark in [4]. Each PT |
− | represents a distinct policy of the AD that synthesized it. The | + | represents a distinct policy of the AD that synthesized it. The |
− | format of a PT is: | + | 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 | + | Hsrc stands for source host, ADsrc for source AD, ADent for entering |
− | AD (i.e., neighboring AD from which traffic is arriving directly), | + | AD (i.e., neighboring AD from which traffic is arriving directly), |
− | Hdst for destination host, ADdst for destination AD, ADexit for exit | + | Hdst for destination host, ADdst for destination AD, ADexit for exit |
− | AD (i.e.,neighboring AD to which traffic is going directly), UCI for | + | AD (i.e.,neighboring AD to which traffic is going directly), UCI for |
− | user class identifier, and Cg and Cb for global and bilateral | + | 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 | + | * 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 | + | * 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 the | + | * If ADexit or ADentr is specified then the policy expressed is an |
− | + | exit/entrance path policy. | |
− | |||
− | |||
− | |||
− | As seen below, any one PT typically incorporates a combination of | + | * If the global conditions include charging, QOS, resource |
− | policy types. | + | 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 | 6.3.1 THE FRICC | ||
− | In the following examples all policies (and PTs) are symmetrical | + | In the following examples all policies (and PTs) are symmetrical |
− | under the assumption that communication is symmetrical. | + | under the assumption that communication is symmetrical. |
Line 692: | Line 728: | ||
+ | Estrin [Page 13] | ||
+ | |||
+ | RFC 1125 Policy Requirements November 1989 | ||
NATIONAL SCIENCE FOUNDATION (NSF) | NATIONAL SCIENCE FOUNDATION (NSF) | ||
− | 1. NSF will carry traffic for any host connected to a F/Re network | + | 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 | + | 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 | + | 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 | + | support. There is no authentication of the UCI and no per packet |
− | charging. NSFnet is a backbone and so does not connect directly to | + | charging. NSFnet is a backbone and so does not connect directly to |
− | universities or companies...thus the indication of {F/Re} instead of | + | universities or companies...thus the indication of {F/Re} instead of |
− | {F/Re/U/Co} as ADent and ADexit. | + | {F/Re/U/Co} as ADent and ADexit. |
− | [NSF1: (*, {F/Re}, {F/Re})(*, {F/Re}, {F/Re}){research,support} | + | [NSF1: (*, {F/Re}, {F/Re})(*, {F/Re}, {F/Re}){research,support} |
− | {unauthenticated UCI,no-per-pkt charge}{}] | + | {unauthenticated UCI,no-per-pkt charge}{}] |
− | 2. NSF will carry traffic to user and expert services hosts in NSF | + | 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 | + | AD to/from any F/Re AD, via any F/Re AD. These are the only things |
− | that directly connect to NSFnet. | + | that directly connect to NSFnet. |
− | [NSF2: ({User svcs, Expert Svcs},{NSF},{F/Re})(*,{F/Re},{-}){}{}{}] | + | [NSF2: ({User svcs, Expert Svcs},{NSF},{F/Re})(*,{F/Re},{-}){}{}{}] |
DEPARTMENT OF ENERGY (DOE) | DEPARTMENT OF ENERGY (DOE) | ||
− | 1. DOE will carry traffic to and from any host directly connected to | + | 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 | + | DOE so long as it is used for research or support. There is no |
− | authentication of the UCI and no per packet charging. | + | authentication of the UCI and no per packet charging. |
− | [DOE1: (*,DOE,-)(*,*,*){research,support} | + | [DOE1: (*,DOE,-)(*,*,*){research,support} |
− | {unauthenticated UCI,no-per-packet charge}{}] | + | {unauthenticated UCI,no-per-packet charge}{}] |
− | 2. DOE will carry traffic for any host connected to a F/Re network | + | 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 | + | 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 | + | 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 | + | 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 | + | restrictive with its own traffic than with traffic it is carrying as |
− | part of a resource sharing arrangement.) | + | part of a resource sharing arrangement.) |
− | [DOE2: (*,{F/Re},{F/Re})(*,{F/Re},{F/Re}){} | + | [DOE2: (*,{F/Re},{F/Re})(*,{F/Re},{F/Re}){} |
− | {unauthenticated UCI, no-per-pkt charge}{}] | + | {unauthenticated UCI, no-per-pkt charge}{}] |
NATIONAL AERONAUTICS AND SPACE ADMINISTRATION (NASA) | NATIONAL AERONAUTICS AND SPACE ADMINISTRATION (NASA) | ||
− | 1. Nasa will accept any traffic to/from members of the Nasa AD. But | + | 1. Nasa will accept any traffic to/from members of the Nasa AD. But |
− | no transit. No UCI authentication and no per packet charge. | + | no transit. No UCI authentication and no per packet charge. |
− | [NASA1: (*,*,*)(*,Nasa,-){Nasa-research, support} | + | [NASA1: (*,*,*)(*,Nasa,-){Nasa-research, support} |
− | {unauthenticated UCI,no-per-packet-charge}{}] | + | {unauthenticated UCI,no-per-packet-charge}{}] |
− | 2. Nasa will carry transit traffic to/from other federal agency | + | 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 | + | 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}{}] | |
− | |||
− | [NASA4: (*,*,-)(*,*,-){} | + | 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) | DEFENSE ADVANCED RESEARCH PROJECTS AGENCY (DARPA) | ||
− | 1. DARPA will carry traffic to/from any host in DARPA AD from any | + | 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 | + | external host that can get it there so long as UCI is research or |
− | support. No UCI authentication or per packet charge. | + | support. No UCI authentication or per packet charge. |
− | [DARPA1: (*,*,*)(*,DARPA,-){research,support} | + | [DARPA1: (*,*,*)(*,DARPA,-){research,support} |
− | {unauthenticated-UCI, no per packet charge}{}] | + | {unauthenticated-UCI, no per packet charge}{}] |
− | 2. DARPA will carry traffic for any host connected to a F/Re/U/Co | + | 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 | + | 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 | + | 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 | + | used for research or support, and the network is not heavily |
− | congested!!. There is no authentication of the UCI and no per packet | + | congested!!. There is no authentication of the UCI and no per packet |
− | charging. NOTE: Darpa would like to say something about the need to | + | 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 | + | enter the Darpa AD at the point closest to the destination...but i |
− | don't know how to express this... | + | don't know how to express this... |
− | DARPA2: (*,{F/R/U/Co},{F/R/U/Co})(*,{F/R/U/Co},{F/R/U/Co}) | + | 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, | + | {research,support}{unauthenticated-UCI,no per packet charge, |
− | non-interference basis}{}] | + | non-interference basis}{}] |
DEFENSE COMMUNICATIONS AGENCY (DCA) | DEFENSE COMMUNICATIONS AGENCY (DCA) | ||
− | 1. DCA will not carry any transit traffic. It will only accept and | + | 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 | + | 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 | + | on other F/Re nets. All packets are marked and charged for by the |
+ | Estrin [Page 15] | ||
+ | RFC 1125 Policy Requirements November 1989 | ||
− | |||
− | [DCA1:(mailbridge,DCA,-)(*,{F/Re},{F/Re}){research,support} | + | kilopacket. |
− | {unauthenticated UCI, all incoming packets marked, per-kilopacket | + | |
− | charge}{}] | + | [DCA1:(mailbridge,DCA,-)(*,{F/Re},{F/Re}){research,support} |
+ | {unauthenticated UCI, all incoming packets marked, per-kilopacket | ||
+ | charge}{}] | ||
6.3.2 THE REGIONALS | 6.3.2 THE REGIONALS | ||
− | Interviews with regional network administrations are now underway. In | + | Interviews with regional network administrations are now underway. In |
− | general their policies are still in formation due to the relatively | + | general their policies are still in formation due to the relatively |
− | recent formation of these regional networks. However, for the sake of | + | recent formation of these regional networks. However, for the sake of |
− | illustration we provide an example of a hypothetical regional's | + | illustration we provide an example of a hypothetical regional's |
− | network policies. | + | network policies. |
REGIONAL A | REGIONAL A | ||
− | 1. Regional A will carry traffic from/to any directly connected | + | 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 | + | 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 | + | or support UCI. (NSF requires that all Regional networks only pass it |
− | traffic that complies with its, NSF's, policies!) | + | traffic that complies with its, NSF's, policies!) |
− | [Regional A:(*,{F/Re/U},{F/Re/U})(*,{F/Re/U},NSF){research,support} | + | [Regional A:(*,{F/Re/U},{F/Re/U})(*,{F/Re/U},NSF){research,support} |
− | {unauthenticated UCI, no-per-packet charge}{}] | + | {unauthenticated UCI, no-per-packet charge}{}] |
REGIONAL B | REGIONAL B | ||
− | 1. Regional B will carry traffic from/to any directly connected | + | 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 | + | 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 | + | regardless of its UCI. In this case the packets are charged for since |
− | the commercial carrier charges per kilopacket. | + | the commercial carrier charges per kilopacket. |
− | [Regional B:(*,{F/Re/U},{F/Re/U})(*,{F/Re/U},Cc){} | + | [Regional B:(*,{F/Re/U},{F/Re/U})(*,{F/Re/U},Cc){} |
− | {unauthenticated UCI, per-kilopacket charge}{}] | + | {unauthenticated UCI, per-kilopacket charge}{}] |
6.3.3 CAMPUS AND PRIVATE NETWORKS | 6.3.3 CAMPUS AND PRIVATE NETWORKS | ||
− | Similar interviews should be conducted with administrators of campus | + | Similar interviews should be conducted with administrators of campus |
− | and private networks. However, many aspects of their policies are | + | and private networks. However, many aspects of their policies are |
− | contingent on the still unresolved policies of the regionals and | + | contingent on the still unresolved policies of the regionals and |
− | federal agencies. In any event, transit policies will be critical | + | federal agencies. In any event, transit policies will be critical |
− | for campus and private networks to flexibly control access to lateral | + | for campus and private networks to flexibly control access to lateral |
− | links and private wide area networks, respectively. For example, a | + | links and private wide area networks, respectively. For example, a |
− | small set of university and private laboratories may provide access | + | small set of university and private laboratories may provide access |
− | to special gigabit links for particular classes of researchers. On | + | to special gigabit links for particular classes of researchers. On |
− | the other hand, source/destination policies should not be used in | + | the other hand, source/destination policies should not be used in |
− | place of network level access controls for these end ADs. | + | place of network level access controls for these end ADs. |
Line 851: | Line 896: | ||
+ | Estrin [Page 16] | ||
+ | |||
+ | RFC 1125 Policy Requirements November 1989 | ||
6.3.4 COMMERCIAL SERVICES | 6.3.4 COMMERCIAL SERVICES | ||
− | Currently commercial communication services play a low level role in | + | Currently commercial communication services play a low level role in |
− | most parts of today's Research Internet; they provide the | + | most parts of today's Research Internet; they provide the |
− | transmission media, i.e.,leased lines. In the future we expect | + | transmission media, i.e.,leased lines. In the future we expect |
− | commercial carriers to provide increasingly higher level and enhanced | + | commercial carriers to provide increasingly higher level and enhanced |
− | services such as high speed packet switched backbone services. | + | services such as high speed packet switched backbone services. |
− | Because such services are not yet part of the Research Internet | + | Because such services are not yet part of the Research Internet |
− | infrastructure there exist no policy statements. | + | infrastructure there exist no policy statements. |
− | Charging and accounting are certain to be an important policy type in | + | Charging and accounting are certain to be an important policy type in |
− | this context. Moreover, we anticipate the long haul services market | + | this context. Moreover, we anticipate the long haul services market |
− | to be highly competitive. This implies that competing service | + | to be highly competitive. This implies that competing service |
− | providers will engage in significant gaming in terms of packaging and | + | providers will engage in significant gaming in terms of packaging and |
− | pricing of services. Consequently, the ability to express varied and | + | pricing of services. Consequently, the ability to express varied and |
− | dynamic charging policies will be critical for these ADs. | + | dynamic charging policies will be critical for these ADs. |
7 PROBLEMATIC REQUIREMENTS | 7 PROBLEMATIC REQUIREMENTS | ||
− | Most of this paper has lobbied for articulation of relatively | + | Most of this paper has lobbied for articulation of relatively |
− | detailed policy statements in order to help define the technical | + | detailed policy statements in order to help define the technical |
− | mechanisms needed for enforcement. We promoted a top down design | + | mechanisms needed for enforcement. We promoted a top down design |
− | process beginning with articulation of desired policies. Now we feel | + | process beginning with articulation of desired policies. Now we feel |
− | compelled to mention requirements that are clearly problematic from | + | compelled to mention requirements that are clearly problematic from |
− | the bottom up perspective of technical feasibility. | + | 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 | + | In general, it is difficult to predict the impact of any particular |
− | policy term. Tools will be needed to assist people in writing and | + | policy term. Tools will be needed to assist people in writing and |
− | validating policy terms. | + | validating policy terms. |
8 PROPOSED MECHANISMS | 8 PROPOSED MECHANISMS | ||
− | Previous routing protocols have addressed a narrower definition of | + | Previous routing protocols have addressed a narrower definition of |
− | PR, as appropriate for the internets of their day. In particular, EGP | + | PR, as appropriate for the internets of their day. In particular, EGP |
− | [3], DGP[13], and BGP[6] incorporate a notion of policy restrictions | + | [3], DGP[13], and BGP[6] incorporate a notion of policy restrictions |
− | as to where routing database information travels. None are intended | + | as to where routing database information travels. None are intended |
− | to support policy based routing of packets as described here. More | + | to support policy based routing of packets as described here. More |
− | recent routing proposals such as Landmark [14] and Cartesian [15] | + | recent routing proposals such as Landmark [14] and Cartesian [15] |
− | could be used to restrict packet forwarding but are not suited to | + | could be used to restrict packet forwarding but are not suited to |
− | source/destination, and some of the condition-oriented, policies. We | + | source/destination, and some of the condition-oriented, policies. We |
− | feel these policy types are critical to support. We note that for | + | feel these policy types are critical to support. We note that for |
− | environments (e.g., within an AD substructure) in which the simple- | + | environments (e.g., within an AD substructure) in which the simple- |
− | AD-topology conjecture holds true, these alternatives may be | + | AD-topology conjecture holds true, these alternatives may be |
− | suitable. | + | 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 | 9 SUMMARY | ||
− | Along with the emergence of very high speed applications and media, | + | Along with the emergence of very high speed applications and media, |
− | resource management has become a critical issue in the Research | + | resource management has become a critical issue in the Research |
− | Internet and internets in general. A fundamental characteristic of | + | Internet and internets in general. A fundamental characteristic of |
− | the resource management problem is allowing administratively ADs to | + | the resource management problem is allowing administratively ADs to |
− | interconnect while retaining control over resource usage. However, we | + | interconnect while retaining control over resource usage. However, we |
− | have lacked a careful articulation of the types of resource | + | have lacked a careful articulation of the types of resource |
− | management policies that need to be supported. This paper addresses | + | management policies that need to be supported. This paper addresses |
− | policy requirements for the Research Internet. After justifying our | + | policy requirements for the Research Internet. After justifying our |
− | assumptions regarding AD topology we presented a taxonomy and | + | assumptions regarding AD topology we presented a taxonomy and |
− | examples of policies that must be supported by a PR protocol. | + | examples of policies that must be supported by a PR protocol. |
10 ACKNOWLEDGMENTS | 10 ACKNOWLEDGMENTS | ||
− | Members of the Autonomous Networks Research Group and Open Routing | + | Members of the Autonomous Networks Research Group and Open Routing |
− | Working Group have contributed significantly to the ideas presented | + | Working Group have contributed significantly to the ideas presented |
− | here, in particular, Guy Almes, Lee Breslau, Scott Brim, Dave Clark, | + | here, in particular, Guy Almes, Lee Breslau, Scott Brim, Dave Clark, |
− | Marianne Lepp, and Gene Tsudik. In addition, Lee Breslau and Gene | + | Marianne Lepp, and Gene Tsudik. In addition, Lee Breslau and Gene |
− | Tsudik provided detailed comments on a previous draft. David Cheriton | + | Tsudik provided detailed comments on a previous draft. David Cheriton |
− | inadvertently caused me to write this document. Sharon Anderson's | + | inadvertently caused me to write this document. Sharon Anderson's |
− | contributions deserve special recognition. The author is supported | + | contributions deserve special recognition. The author is supported |
− | by research grants from National Science Foundation, AT&T, and GTE. | + | by research grants from National Science Foundation, AT&T, and GTE. |
11 REFERENCES | 11 REFERENCES | ||
− | [1] J. Postel, Internet Protocol, Network Information Center, RFC | + | [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 | + | [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, | + | [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 | [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 | [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 | [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 | [13] M. Little, The Dissimilar Gateway Protocol, Technical report | ||
[14] P. Tsuchiya, The Landmark Hierarchy: A new hierarchy for routing | [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 | [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 | [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 | 11 SECURITY CONSIDERATIONS | ||
− | + | This memo does not address the security aspects of the issues | |
− | + | discussed. | |
AUTHOR'S ADDRESS: | AUTHOR'S ADDRESS: | ||
− | + | Deborah Estrin | |
− | + | University of Southern California | |
− | + | Computer Science Department | |
− | + | Los Angeles, CA 90089-0782 | |
+ | |||
+ | Phone: (213) 743-7842 | ||
+ | |||
+ | EMail: [email protected] | ||
+ | |||
+ | |||
+ | |||
+ | Estrin [Page 20] | ||
+ | |||
+ | RFC 1125 Policy Requirements November 1989 | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
− | |||
− | + | Estrin [Page 21] |
Revision as of 22:52, 22 September 2020
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: [email protected]
Estrin [Page 20]
RFC 1125 Policy Requirements November 1989
Estrin [Page 21]