RFC 1125

RFC 1125: Policy Requirements for Inter Administrative Domain Routing 🎀

Okay bestie, this one is from November 1989 and it's by D. Estrin at the USC Computer Science Department ✨ It's a discussion memo, not a standard (more on that in section 1), and the header doesn't say it obsoletes or updates anything, so it's standing on its own 💅

1. Status of This Memo ✨

The whole point of this memo is to get people talking about specific problems on the Internet and possible ways to fix them 🫶 Nothing proposed in here is meant to be a standard. The hope is that a general consensus shows up about the right solutions, and that eventually leads to real standards getting developed and adopted 🌸 Distribution of this memo is unlimited, so share it with everyone 🦋

2. Abstract 💅

Okay so, there's a new generation of routing protocol being built right now 🔥 The goal is that every Administrative Domain (AD) in the growing Internet (and internets in general) can independently express and enforce its own policies about the flow of packets to, from, and through its resources 👑 (FOOTNOTE 1: The material here pulls together discussions with members of the IAB Autonomous Networks Research Group and the Open Routing Working Group. 🌈) This document lays out the requirements for policy based routing, and it's meant to be used as input when people write the functional specs and evaluate proposed protocols.

Two critical assumptions are going to shape the kind of routing mechanism that gets devised: (1) how ADs are topologically organized, and (2) the type and variability of policies that ADs express 💖 The memo justifies its assumptions about AD topology first, then gives a taxonomy and specific examples of the policies a PR protocol has to support 🧚 It wraps up with a quick look at the policy routing mechanisms proposed in earlier RFCs (827, 1102, 1104, 1105) 💜 Future RFCs will go deeper on the architecture and protocols needed to support everything here ✨

3. Background 🦋

The Research Internet glowed up from a single backbone wide area network with a bunch of connected campus networks into an internet with multiple cross-country backbones, regional access networks, and a whole profusion of campus networks 🍓 (FOOTNOTE 2: "Research Internet" refers to a collection of government, university, and some private company networks that researchers use to reach shared computing resources (for example, supercomputers) and to exchange research-related information (for example, distributing software, technical documents, and email). The networks that make up the Research Internet run the DOD Internet Protocol [1].) 🫶 For a while the topology looked kind of chaotic, honestly 🙈 Overlapping facilities and lateral connections (as opposed to hierarchical ones) were the rule, not the exception 💀 Today it's getting way more regular, because agencies are coordinating their investments and adopting a hierarchy similar to the telephone networks' 🎀 The result is several overlapping wide area backbones connected to regional networks, and those regionals connect to campus networks at universities, research labs, and private companies 🌸 The big difference is that the telephone network only has lateral connections at the very top, meaning between long haul carriers. The Research Internet has lateral connections at every level of the hierarchy, including between campus (and regional) networks too 🔥

Then there's the private network situation, which adds more complexity 💅 Lots of private companies connect to the Research Internet for research or support activities. They connect the same way campuses do, either through a regional network or through lateral links to other campuses 🦋 But many companies also run their own private wide area networks that physically overlap with backbone and/or regional networks in the Research Internet. These are private vertical bypass links 👑

Organizational boundaries are baked into all of this 🧚 Those boundaries define Administrative Domains (ADs), and they rule out imposing a single, centralized set of policies on all resources 💜 This paper is about the policy requirements for resource usage control in the Research Internet ✨

For the rest of this section, the memo describes the policy routing problem in really general terms 🌈 Section 4 looks at the constraints and requirements that make the problem so challenging, and it concludes that we need a new generation of routing and resource control protocols 💖 Section 5 gives more detail on the assumptions about the future topology and configuration of interconnected ADs 🫶 The policy requirements come back in Section 7, which sorts the different types of policies that ADs in the Research Internet may want to enforce, including examples of FRICC policy statements. (FOOTNOTE 3: The Federal Research Internet Coordinating Committee (FRICC) is made up of representatives from each of the major agencies involved in networking. They've been super effective at coordinating their efforts to cut inefficient redundancy, and they've proposed a plan for the next 10 years of internetworking for the government, scientific, and education community [2] 👑) Section 7 also flags types of policy statements that are a pain to enforce because of their dynamics, granularity, or performance implications 😭 Several proposed mechanisms for supporting PR (including RFCs 827, 1102, 1104, 1105) get a brief look in Section 8 🍓 Future RFCs will elaborate on the architecture and protocols needed to support the requirements in this memo ✨

3.1. Policy Routing 🧚

Earlier protocols like the Exterior Gateway Protocol (EGP) [3] had a pretty limited idea of policy and ADs 🙈 Autonomous system boundaries limited the flow of routing database information, and they only indirectly affected the flow of packets themselves 💅 Here, an Administrative Domain (AD) is a set of hosts and network resources (gateways, links, etc.) that's governed by common policies 🦋

In large internets that cross organizational boundaries, like the Research Internet, inter-AD routes have to be selected based on policy-related parameters such as cost and access rights, on top of the traditional parameters of connectivity and congestion 🔥 In other words, Policy Routing (PR) is needed to get through the complex web of policy boundaries that show up when a bunch of ADs are interconnected 🌈 Each AD has its own privileges and perspective, so each one has to make its own evaluation of which routes are legal and which it prefers 💖 Efforts are now underway to build a new generation of routing protocol that lets each AD independently express and enforce policies about 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 more info, contact the author. 🫶)

The purpose of this paper is to lay out the requirements for policy based routing 👑 Two critical assumptions will shape the kind of routing mechanism that gets devised:

• The topological organization of ADs, and
• The type and variability of policies expressed by ADs.

The memo uses the policies that owners of current Research Internet resources, and private networks connected to the Research Internet, already express to generalize the types of policies that must be supported 🧚 This top down effort has to pay attention to the technical implications of those policy statements, or the result won't actually help guide technical development 💀 For example, some ADs want to enforce local constraints over how packets travel to their destination 🎀 Other ADs only care about stopping other people from using their own network resources, so they restrict transit 🌸 And still others mainly want to recover the cost of carrying traffic and give users feedback so they'll limit their own data flows, which is what the memo calls charging 💜 The memo calls ADs whose main concern is communication to and from hosts within their AD stub, and ADs whose main concern is carrying packets to and from other ADs transit}. If we only address control of transit, the resulting mechanisms won't necessarily let an AD control the flow of its packets from source to destination, or implement flexible charging schemes 😭 (FOOTNOTE 5: Gene Tsudik uses the international travel analogy to explain why we need both source and transit controls 🧳 Each country sets its own policies about travel to and through its land. Going through one country on the way to another is like transit traffic in the network world. A traveler collects policy information from each country of interest and plans an itinerary that follows those policies as well as the preferences of the traveler and his/her home nation. So there's both source and transit region control of routing 🌍) Our purpose is to lay out a comprehensive set of requirements for PR as input to the functional specification and evaluation of proposed protocols 🦋

4. WHY THE PROBLEM IS DIFFICULT ✨

okay bestie, before we get into topology and policy requirements, this section lays out a few 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 some seriously tricky technical issues 😭

the whole point of policy based routing is to let ADs interconnect and share computer and network resources in a controlled way 💅. unlike a lot of other resource control problems, there is no global authority 👑. each AD defines its own policies for its own traffic and resources. BUT, 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 and requirements for interdependence. so our mechanisms should let ADs design their boundaries, instead of requiring that the boundaries be either impenetrable or eliminated 🧱✨

one of the most problematic parts of the policy routing requirements here is supporting both network resource sharing and interconnection across ADs 🌸. an example of resource sharing is two ADs (e.g., agencies, divisions, companies) 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, where ADs interconnect 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 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 that comes 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. but 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 driving 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 that must be taken into account in the design of both policies and supporting technical mechanisms 🎀.

5. Topology Model of Internet ✨

okay bestie, before we get into policies themselves we need to talk about our model of inter-AD topology 🦋 and how it changes the kind of policy support we actually need. most of the internet crowd agrees the future internet will connect on the order of 150,000,000 termination points and 100,000 ADs 🌐 but people really disagree about which AD topology we should design PR mechanisms for. the informal argument is laid out right here 💜

Simple AD Topology and Policy Model

some members of the internet community believe the current complex topology of interconnected ADs is a transient artifact 🫠 left over 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 Internet workshop in Santa Clara, January, 1989). the critical points of this argument are about topology and policy 🎀 and they contend that in the long term these 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. it's giving tidy, honestly ✨

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 significantly different assumptions about AD policies. 🧩

this model assumes 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 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 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 dispensable. 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 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 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. 🎀

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 ✨

okay bestie, so here's the lineup of access policies that ADs might wanna enforce 💅 Charging policies get their own section next, and Section 6.3 has super concrete examples of both access AND charging policies written as FRICC policy statements 🎀

Access policies basically look like this: principals of type x can have access to resources of type y under the following conditions, z 🦋 The policies below are sorted by what y and z are. For any particular instance, each policy type also gets qualified by what makes a principal legit, aka what characteristics x has to have before it can touch the resource in question 👑

We're talking about access policies from both stub ADs and transit ADs 🌸 The two roles have different reasons for controlling resources, but the kinds of policies are pretty similar, so we expect the supporting mechanisms to be common too 🫶

Stub and transit access policies may specify any of the following parameters:

• SOURCE/DESTINATION: Source/Destination policies stop or limit communication that comes from or is headed to particular ADs (or hosts or user classes within an AD) 🙈
• PATH: Path sensitive policies decide which ADs may or may not be passed through en route to a destination 🧚 The most general version lets stub and transit ADs write policies that depend on any component in the AD path. So a stub AD could reject a route based on any AD (or combo of ADs) in that route. A transit AD could also make a forwarding policy that acts differently depending on which ADs a packet has already passed through, and which ones it's gonna pass through on the way to the destination 😭 Less ambitious (and maybe more reasonable) path sensitive policies only care about the immediate neighbor ADs the packet is traveling through. So a stub network could reject a route based on the first transit AD in the route, and a transit AD could make a forwarding policy that depends on the previous and the subsequent transit ADs in the route.
• QUALITY/TYPE OF SERVICE (QOS OR TOS): This one restricts access to special resources or services. For example, a special high throughput, low delay link might only be available on a selective basis ⚡
• RESOURCE GUARANTEE: These policies guarantee a percentage of a resource on a selective, as-needed basis 🍓 In other words, others can use the resource 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, like mail or file transfer. (Alternatively, you can do this with source/destination policies by setting up a host within an AD as an application relay and writing policy terms that allow inter-AD access to only that host 🎀)
• RESOURCE LIMIT: There may be a limit on how much traffic load a source can generate in a given time interval, e.g., so many packets in a day, hour, or minute 🌈
• AUTHENTICATION REQUIREMENTS: Conditions may be set on how authenticable the principal's identifying info is. Some ADs might require some form of cryptographic proof of the principal's identity and affiliations before giving access to critical resources 🔐

The above policy types usually show up in combos for a particular AD. An AD's policies might mix transit, source/destination, and QOS restrictions all at once 💖 This taxonomy will evolve as PR is applied to other domains 🦋

As you'll see in Section 6.3, an AD can express its charging and access policies in a single syntax 🎀 Also, stub and transit policies can coexist. This matters because some ADs operate as both a stub and a transit facility and need that 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, these are not official policy statements 🙃 They're here to give concrete examples of the sort of policies 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 is the source host, ADsrc is the source AD, ADent is the entering AD (i.e., the neighboring AD that traffic is arriving from directly), Hdst is the destination host, ADdst is the destination AD, ADexit is the exit AD (i.e., the neighboring AD that traffic is going to directly), UCI is the user class identifier, and Cg and Cb are the global and bilateral conditions. The whole point of a PT is to say 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 their way to a host, H{dst} (or a group of hosts), in some destination AD, AD{dst} 🧚 The User Class Identifier (UCI) lets you tell apart user classes like Government, Research, Commercial, Contract, etc. 🎀 Global Conditions (Cg) cover billing and other variables 💰 Bilateral Conditions (Cb) are about agreements between neighboring ADs, e.g., metering or charging 🤝

In the example policy terms below we use these 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 there are no applicable matches 🙅

By looking at a PT, you can figure out what type of policy it represents, based on the taxonomy from earlier 🔍

• If an AD specifies a policy term with a null (-) entry for the ADexit, then it's disallowing transit for some group of users, which makes it a transit policy 🚫
• If an AD specifies a policy term that lists itself explicitly as ADsrc or ADdst, it's expressing restrictions on who can access particular resources within its boundaries, or on who inside can get 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, then it's obviously a charging, QOS, resource guarantee, temporal, higher level application, resource limit, or authentication policy, respectively 🌈

As you'll see below, any one PT usually mixes several policy types together 🫶

6.3.1. THE FRICC 🌟

In the following examples, all policies (and PTs) are symmetrical, under the assumption that communication is symmetrical 🦋

NATIONAL SCIENCE FOUNDATION (NSF)

1. NSF will carry traffic for any host connected to an F/Re network talking to any other host connected to an F/Re via any F/Re entry and exit network, so long as it's being used for research or support 📚 There's no authentication of the UCI and no per packet charging. NSFnet is a backbone, so it doesn't connect directly to universities or companies... which is why it's {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 and from user and expert services hosts in the 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's used for research or support. There's 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 an F/Re network talking to any other host connected to an F/Re via any F/Re entry and exit network, without regard to the UCI. There's no authentication of the UCI and no per packet charging. (In other words, DOE is stricter with its own traffic than with traffic it's 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 and 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 and from other federal agency networks if it's in support of research, and if the total use of available BW by non-Nasa Federal agencies is below n%. Heads up: this non-interference policy type still needs more work to fit 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, regional, and university ADs for Nasa research or support. But it won't allow transit. The particular entry AD doesn't matter 🌷

[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 won't be carried on this basis 💖

[NASA4: (*,*,-)(*,*,-){}
{per-packet-charge, limited to n% of available BW} {}]

DEFENSE ADVANCED RESEARCH PROJECTS AGENCY (DARPA) 🛸

1. Okay so DARPA will carry traffic to and from any host in DARPA AD from any external host that can get it there, as long as the UCI is research or support 🔬. No UCI authentication and no per packet charge, bestie 💖.

[DARPA1: (*,*,*)(*,DARPA,-){research,support}
{unauthenticated-UCI, no per packet charge}{}]

2. DARPA will carry traffic for any host connected to an F/Re/U/Co network that's talking to any other host connected to an F/Re/U/Co, through any F/Re/U/Co entry and exit network 🌐. It has to be used for research or support, and the network can't be heavily congested!! 🚦 There's 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 only accepts and sends 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 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 🗣️. Their policies are still forming, since these regional networks are pretty new 🌱. For the sake of illustration, though, here's an example of a hypothetical regional's network policies 🧁.

REGIONAL A

1. Regional A will carry traffic from and to any directly connected F/Re/U network, to any F/Re/U network via NSF, as long as it's for 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 and to any directly connected F/Re/U network, to any F/Re/U network via a commercial carrier, regardless of its UCI. Here the packets get charged because 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 🗒️. Lots of their policies depend on the still-unresolved policies of the regionals and federal agencies. Either way, 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 🔐.

6.3.4 COMMERCIAL SERVICES 💼

Right now commercial communication services play a low level role in most parts of today's Research Internet. They mostly provide the transmission media, i.e., leased lines 🛤️. In the future we expect commercial carriers to offer increasingly higher level and enhanced services, such as high speed packet switched backbone services ⚡. Because those services aren't part of the Research Internet infrastructure yet, there exist no policy statements.

Charging and accounting are certain to be an important policy type in this context 💅. We also anticipate the long haul services market to be highly competitive 🏁. That means competing service providers will engage in significant gaming when it comes to packaging and pricing 🎲. So 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 fairly detailed policy statements, to help define the technical mechanisms needed for enforcement 📜. We promoted a top down design process that starts with articulating the desired policies. Now we feel compelled to mention requirements that are clearly problematic from the bottom up perspective of technical feasibility 🙃.

• Non-interference policies take 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 is that access to an AD at any point in time depends on a local, highly dynamic parameter that isn't globally available 🌀. So 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 devastating as highly dynamic PR contingencies 🫶. The caution here is less specific. Very fine grain policies, which restrict access to particular hosts or depend on 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 detection and non-repudiation. However, achieving a priori prevention of resource misuse is expensive in terms of per connection or per packet cryptographic overhead. For some environments we firmly believe this will be necessary, and we would prefer an architecture that accommodates such variability [12] 🔒.

In general, it is difficult to predict the impact of any particular policy term 🔮. Tools will be needed to help people write and validate policy terms.

8 PROPOSED MECHANISMS 🧩

Previous routing protocols 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 on 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 they aren't 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) where 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) isn't just 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. Plus, 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.) 🥰

9 SUMMARY 🦋

Along with very high speed applications and media, resource management has become a critical issue in the Research Internet and in 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've 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 ✨

okay so this is the shoutout section and it's giving gratitude diary 🫶 Members of the Autonomous Networks Research Group and Open Routing Working Group helped shape the ideas here, especially Guy Almes, Lee Breslau, Scott Brim, Dave Clark, Marianne Lepp, and Gene Tsudik 💖 Lee Breslau and Gene Tsudik also gave super detailed comments on an earlier draft, which is literally the most bestie thing ever 😭 David Cheriton accidentally inspired the author to write this document 🦋 and Sharon Anderson gets special recognition because she's iconic 👑 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.
• [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 🔐

okay the official line is "This memo does not address the security aspects of the issues discussed." 💀 so no security stuff is covered in this doc, not me being dramatic, it's just literally not in scope 🙈

AUTHOR'S ADDRESS 📬

Deborah Estrin University of Southern California Computer Science Department Los Angeles, CA 90089-0782

Phone: (213) 743-7842

EMail: Estrin@OBERON.USC.EDU