From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1477.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc1477.txt (limited to 'doc/rfc/rfc1477.txt') diff --git a/doc/rfc/rfc1477.txt b/doc/rfc/rfc1477.txt new file mode 100644 index 0000000..7fc5f37 --- /dev/null +++ b/doc/rfc/rfc1477.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group M. Steenstrup +Request for Comments: 1477 BBN Systems and Technologies + July 1993 + + + IDPR as a Proposed Standard + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard. Distribution of this memo is + unlimited. + +1. Introduction + + This document contains a discussion of inter-domain policy routing + (IDPR), including an overview of functionality and a discussion of + experiments. The objective of IDPR is to construct and maintain + routes between source and destination administrative domains, that + provide user traffic with the services requested within the + constraints stipulated for the domains transited. + + Four documents describe IDPR in detail: + + M. Steenstrup. An architecture for inter-domain policy routing. + RFC 1478. July 1993. + + M. Steenstrup. Inter-domain policy routing protocol + specification: version 1. RFC 1479. July 1993. + + H. Bowns and M. Steenstrup. Inter-domain policy routing + configuration and usage. Work in Progress. July 1991. + + R. Woodburn. Definitions of managed objects for inter-domain + policy routing (version 1). Work in Progress. March 1993. + + This is a product of the Inter-Domain Policy Routing Working Group of + the Internet Engineering Task Force (IETF). + +2. The Internet Environment + + As data communications technologies evolve and user populations grow, + the demand for internetworking increases. The Internet currently + comprises over 7000 operational networks and over 10,000 registered + networks. In fact, for the last several years, the number of + constituent networks has approximately doubled annually. Although we + do not expect the Internet to sustain this growth rate, we must + prepare for the Internet of five to ten years in the future. + + + +Steenstrup [Page 1] + +RFC 1477 IDPR July 1993 + + + Internet connectivity has increased along with the number of + component networks. Internetworks proliferate through + interconnection of autonomous, heterogeneous networks administered by + separate authorities. We use the term "administrative domain" (AD) + to refer to any collection of contiguous networks, gateways, links, + and hosts governed by a single administrative authority that selects + the intra-domain routing procedures and addressing schemes, specifies + service restrictions for transit traffic, and defines service + requirements for locally-generated traffic. + + In the early 1980s, the Internet was purely hierarchical, with the + ARPANET as the single backbone. The current Internet possesses a + semblance of a hierarchy in the collection of backbone, regional, + metropolitan, and campus domains that compose it. However, + technological, economical, and political incentives have prompted the + introduction of inter-domain links outside of those in the strict + hierarchy. Hence, the Internet has the properties of both + hierarchical and mesh connectivity. + + We expect that, over the next five years, the Internet will grow to + contain O(10) backbone domains, most providing connectivity between + many source and destination domains and offering a wide range of + qualities of service, for a fee. Most domains will connect directly + or indirectly to at least one Internet backbone domain, in order to + communicate with other domains. In addition, some domains may + install direct links to their most favored destinations. Domains at + the lower levels of the hierarchy will provide some transit service, + limited to traffic between selected sources and destinations. + However, the majority of Internet domains will be "stubs", that is, + domains that do not provide any transit service for any other domains + but that connect directly to one or more transit domains. + + The bulk of Internet traffic will be generated by hosts in the stub + domains, and thus, the applications running in these hosts will + determine the traffic service requirements. We expect application + diversity encompassing electronic mail, desktop videoconferencing, + scientific visualization, and distributed simulation, for example. + Many of these applications have strict requirements on loss, delay, + and throughput. + + In such a large and heterogeneous Internet, the routing procedures + must be capable of ensuring that traffic is forwarded along routes + that offer the required services without violating domain usage + restrictions. We believe that IDPR meets this goal; it has been + designed to accommodate an Internet comprising O(10,000) + administrative domains with diverse service offerings and + requirements. + + + + +Steenstrup [Page 2] + +RFC 1477 IDPR July 1993 + + +3. An Overview of IDPR + + IDPR generates, establishes, and maintains "policy routes" that + satisfy the service requirements of the users and respect the service + restrictions of the transit domains. Policy routes are constructed + using information about the services offered by and the connectivity + between administrative domains and information about the services + requested by the users. + +3.1 Policies + + With IDPR, each domain administrator sets "transit policies" that + dictate how and by whom the resources in its domain should be used. + Transit policies are usually public, and they specify offered + services comprising: + + - Access restrictions: e.g., applied to traffic to or from certain + domains or classes of users. + + - Quality: e.g., delay, throughput, or error characteristics. + + - Monetary cost: e.g., charge per byte, message, or session time. + + Each domain administrator also sets "source policies" for traffic + originating in its domain. Source policies are usually private, and + they specify requested services comprising: + + - Access: e.g., domains to favor or avoid in routes. + + - Quality: e.g., acceptable delay, throughput, and reliability. + + - Monetary cost: e.g., acceptable cost per byte, message, or session + time. + +3.2 Functions + + The basic IDPR functions include: + + - Collecting and distributing routing information, i.e., domain + transit policy and connectivity information. IDPR uses link state + routing information distribution, so that each source domain may + obtain routing information about all other domains. + + - Generating and selecting policy routes based on the routing + information distributed and on source policy information. IDPR + gives each source domain complete control over the routes it + generates. + + + + +Steenstrup [Page 3] + +RFC 1477 IDPR July 1993 + + + - Setting up paths across the Internet, using the policy routes + generated. + + - Forwarding messages across and between administrative domains along + the established paths. IDPR uses source-specified message + forwarding, giving each source domain complete control over the + paths traversed by its hosts' inter-domain traffic. + + - Maintaining databases of routing information, inter-domain policy + routes, forwarding information, and configuration information. + +3.3 Entities + + Several different entities are responsible for performing the IDPR + functions: + + - "Policy gateways", the only IDPR-recognized connecting points + between adjacent domains, collect and distribute routing + information, participate in path setup, maintain forwarding + information databases, and forward data messages along established + paths. + + - "Path agents", resident within policy gateways, act on behalf of + hosts to select policy routes, to set up and manage paths, and to + maintain forwarding information databases. Any Internet host can + reap the benefits of IDPR, as long as there exists a path agent + willing to act on its behalf and a means by which the host's + messages can reach that path agent. + + - Special-purpose servers maintain all other IDPR databases as + follows: + + o Each "route server" is responsible for both its database of + routing information, including domain connectivity and transit + policy information, and its database of policy routes. Also, + each route server generates policy routes on behalf of its + domain, using entries from its routing information database + and using source policy information supplied through + configuration or obtained directly from the path agents. A + route server may reside within a policy gateway, or it may + exist as an autonomous entity. Separating the route server + functions from the policy gateways frees the policy gateways + from both the memory intensive task of routing information + database and route database maintenance and the + computationally intensive task of route generation. + + o Each "mapping server" is responsible for its database of + mappings that resolve Internet names and addresses to + + + +Steenstrup [Page 4] + +RFC 1477 IDPR July 1993 + + + administrative domains. The mapping server function can be + easily integrated into an existing name service such as the + DNS. + + o Each "configuration server" is responsible for its database of + configured information that applies to policy gateways, path + agents, and route servers in the given administrative domain. + Configuration information for a given domain includes source + and transit policies and mappings between local IDPR entities + and their addresses. The configuration server function can be + easily integrated into a domain's existing network management + system. + +3.4 Message Handling + + There are two kinds of IDPR messages: + + - "Data messages" containing user data generated by hosts. + + - "Control messages" containing IDPR protocol-related control + information generated by policy gateways and route servers. + + Within the Internet, only policy gateways and route servers must be + able to generate, recognize, and process IDPR messages. Mapping + servers and configuration servers perform necessary but ancillary + functions for IDPR, and they are not required to execute IDPR + protocols. The existence of IDPR is invisible to all other gateways + and hosts. Using encapsulation across each domain, an IDPR message + tunnels from source to destination across the Internet through + domains that may employ disparate intra-domain addressing schemes and + routing procedures. + +4. Security + + IDPR contains mechanisms for verifying message integrity and source + authenticity and for protecting against certain types of denial of + service attacks. It is particularly important to keep IDPR control + messages intact, because they carry control information critical to + the construction and use of viable policy routes between domains. + +4.1 Integrity and Authenticity + + All IDPR messages carry a single piece of information, referred to in + the IDPR documentation as the "integrity/authentication value", which + may be used not only to detect message corruption but also to verify + the authenticity of the message's source IDPR entity. The Internet + Assigned Numbers Authority (IANA) specifies the set of valid + algorithms which may be used to compute the integrity/authentication + + + +Steenstrup [Page 5] + +RFC 1477 IDPR July 1993 + + + values. This set may include algorithms that perform only message + integrity checks such as n-bit cyclic redundancy checksums (CRCs), as + well as algorithms that perform both message integrity and source + authentication checks such as signed hash functions of message + contents. + + Each domain administrator is free to select any + integrity/authentication algorithm, from the set specified by the + IANA, for computing the integrity/authentication values contained in + its domain's messages. However, we recommend that IDPR entities in + each domain be capable of executing all of the valid algorithms so + that an IDPR message originating at an entity in one domain can be + properly checked by an entity in another domain. + + IDPR control messages must carry a non-null integrity/authentication + value. We recommend that control message integrity/authentication be + based on a digital signature algorithm applied to a one-way hash + function, such as RSA applied to MD5, which simultaneously verifies + message integrity and source authenticity. The digital signature may + be based on either public key or private key cryptography. However, + we do not require that IDPR data messages carry a non-null + integrity/authentication value. In fact, we recommend that a higher + layer (end-to-end) procedure assume responsibility for checking the + integrity and authenticity of data messages, because of the amount of + computation involved. + +4.2 Timestamps + + Each IDPR message carries a timestamp (expressed in seconds elapsed + since 1 January 1970 0:00 GMT) supplied by the source IDPR entity, + which serves to indicate the age of the message. IDPR entities use + the absolute value of a timestamp to confirm that the message is + current and use the relative difference between timestamps to + determine which message contains the most recent information. All + IDPR entities must possess internal clocks that are synchronized to + some degree, in order for the absolute value of a message timestamp + to be meaningful. The synchronization granularity required by IDPR + is on the order of minutes and can be achieved manually. + + Each IDPR recipient of an IDPR control message must check that the + message's timestamp is in the acceptable range. A message whose + timestamp lies outside of the acceptable range may contain stale or + corrupted information or may have been issued by a source whose clock + has lost synchronization with the message recipient. Such messages + must therefore be discarded, to prevent propagation of incorrect IDPR + control information. We do not require IDPR entities to perform a + timestamp acceptability test for IDPR data messages, but instead + leave the choice to the individual domain administrators. + + + +Steenstrup [Page 6] + +RFC 1477 IDPR July 1993 + + +5. Size Considerations + + IDPR provides policy routing among administrative domains and has + been designed to accommodate an Internet containing tens of thousands + of domains, supporting diverse source and transit policies. + + In order to construct policy routes, route servers require routing + information at the domain level only; no intra-domain details need be + included in IDPR routing information. Thus, the size of the routing + information database maintained by a route server depends on the + number of domains and transit policies and not on the number hosts, + gateways, or networks in the Internet. + + We expect that, within a domain, a pair of IDPR entities will + normally be connected such that when the primary intra-domain route + fails, the intra-domain routing procedure will be able to use an + alternate route. In this case, a temporary intra-domain failure is + invisible at the inter-domain level. Thus, we expect that most + intra-domain routing changes will be unlikely to force inter-domain + routing changes. + + Policy gateways distribute routing information when detectable + inter-domain changes occur but may also elect to distribute routing + information periodically as a backup. Thus, policy gateways do not + often need to generate and distribute routing information messages, + and the frequency of distribution of these messages depends only + weakly on intra-domain routing changes. + + IDPR entities rely on intra-domain routing procedures operating + within domains to transport inter-domain messages across domains. + Hence, IDPR messages must appear well-formed according to the intra- + domain routing procedures and addressing schemes in each domain + traversed; this requires appropriate header encapsulation of IDPR + messages at domain boundaries. Only policy gateways and route + servers must be capable of handling IDPR-specific messages; other + gateways and hosts simply treat the encapsulated IDPR messages like + any other. Thus, for the Internet to support IDPR, only a small + proportion of Internet entities require special IDPR software. + + With domain-level routes, many different traffic flows may use not + only the same policy route but also the same path, as long their + source domains, destination domains, and requested services are + identical. Thus, the size of the forwarding information database + maintained by a policy gateway depends on the number of domains and + source policies and not on the number of hosts in the Internet. + Moreover, memory associated with failed, expired, or disused paths + can be reclaimed for new paths, and thus forwarding information for + many paths can be accommodated. + + + +Steenstrup [Page 7] + +RFC 1477 IDPR July 1993 + + +6. Interactions with Other Inter-Domain Routing Procedures + + We believe that many Internet domains will benefit from the + introduction of IDPR. However, the decision to support IDPR in a + given domain is an individual one, left to the domain administrator; + not all domains must support IDPR. + + Within a domain that supports IDPR, other inter-domain routing + procedures, such as BGP and EGP, can comfortably coexist. Each + inter-domain routing procedure is independent of the others. The + domain administrator determines the relationship among the inter- + domain routing procedures by deciding which of its traffic flows + should use which inter-domain routing procedures and by configuring + this information for use by the policy gateways. + + Hosts in stub domains may have strict service requirements and hence + will benefit from the policy routing provided by IDPR. However, the + stub domain itself need not support IDPR in order for its traffic + flows to use IDPR routes. Instead, a "proxy domain" may perform IDPR + functions on behalf of the stub. The proxy domain must be reachable + from the stub domain according to an inter-domain routing procedure + independent of IDPR. Administrators of the stub and potential proxy + domains mutually negotiate the relationship. Once an agreement is + reached, the administrator of the stub domain should provide the + proxy domain with its hosts' service requirements. + + IDPR policy routes must traverse a contiguous set of IDPR domains. + Hence, the degree of IDPR deployment in transit domains will + determine the availability of IDPR policy routes for Internet users. + For a given traffic flow, if there exists no contiguous set of IDPR + domains between the source and destination, the traffic flow relies + on an alternate inter-domain routing procedure to provide a route. + However, if there does exist a contiguous set of IDPR domains between + the source and destination, the traffic flow may take advantage of + policy routes provided by IDPR. + +7. Implementation Experience + + To date, there exist two implementations of IDPR: one an independent + prototype and the other an integral part of the gated UNIX process. + We describe each of these implementations and our experience with + them in the following sections. + +7.1 The Prototype + + During the summer of 1990, the IDPR development group consisting of + participants from USC, SAIC, and BBN began work on a UNIX-based + software prototype of IDPR, designed for implementation in Sun + + + +Steenstrup [Page 8] + +RFC 1477 IDPR July 1993 + + + workstations. This prototype consisted of multiple user-level + processes to provide the basic IDPR functions together with kernel + modifications to speed up IDPR data message forwarding. + + Most, but not all, of the IDPR functionality was captured in the + prototype. In the interests of producing working software as quickly + as possible, we intentionally left out of the IDPR prototype support + for source policies and for multiple policy gateways connecting two + domains. This simplified configuration and route generation without + compromising the basic functionality of IDPR. + + The IDPR prototype software was extensively instrumented to provide + detailed information for monitoring its behavior. The + instrumentation allowed us to detect events including but not limited + to: + + - Change in policy gateway connectivity to adjacent domains. + + - Change in transit policies configured for a domain. + + - Transmission and reception of link state routing information. + + - Generation of policy routes, providing a description of the actual + route. + + - Transmission and reception of path control information. + + - Change of path state, such as path setup or teardown. + + With the extensive behavioral information available, we were able to + track most events occurring in our test networks and hence determine + whether the prototype software provided the expected functionality. + +7.1.1 Test Networks + + In February 1991, the IDPR development group began experimenting with + the completed IDPR prototype software. Each IDPR development site + had its own testing environment, consisting of a set of + interconnected Sun workstations, each workstation performing the + functions of a policy gateway and route server: + + - USC used a laboratory test network consisting of SPARC1+ + workstations, each pair of workstations connected by an Ethernet + segment. The topology of the test network could be arbitrarily + configured. + + - SAIC used Sun3 workstations in networks at Sparta and at MITRE. + These two sites were connected through Alternet using a 9.6kb SLIP + + + +Steenstrup [Page 9] + +RFC 1477 IDPR July 1993 + + + link and through an X.25 path across the DCA EDN testbed. + + - BBN used SPARC1+ workstations at BBN and ISI connected over both + DARTnet and TWBnet. + +7.1.2 Experiments + + The principal goal of our experiments with the IDPR prototype + software was to provide a proof of concept. In particular, we set + out to verify tha t the IDPR prototype software was able to: + + - Monitor connectivity across and between domains. + + - Update routing information when inter-domain connectivity changed + or when new transit policies were configured. + + - Distribute routing information to all domains. + + - Generate acceptable policy routes based on current link state + routing information. + + - Set up and maintain paths for these policy routes. + + - Tear down paths that contained failed components, supported stale + policies, or attained their maximum age. + + Furthermore, we wanted to verify that the IDPR prototype software + quickly detected and adapted to those events that directly affected + policy routes. + + The internetwork topology on which we based most of our experiments + consisted of four distinct administrative domains connected in a + ring. Two of the four domains served as host traffic source and + destination, AD S and AD D respectively, while the two intervening + domains provided transit service for the host traffic, AD T1 and AD + T2. AD S and AD D each contained a single policy gateway that + connected to two other policy gateways, one in each transit domain. + AD T1 and AD T2 each contained at most two policy gateways, each + policy gateway connected to the other and to a policy gateway in the + source or destination domain. This internetwork topology provided + two distinct inter-domain routes between AD S and AD D, allowing us + to experiment with various component failure and transit policy + reconfiguration scenarios in the transit domains. + + For the first set of experiments, we configured transit policies for + AD T1 and AD T2 that were devoid of access restrictions. We then + initialized each policy gateway in our internetwork, loading in the + domain-specific configurations and starting up the IDPR processes. + + + +Steenstrup [Page 10] + +RFC 1477 IDPR July 1993 + + + In our experiments, we did not use mapping servers; instead, we + configured address/domain mapping tables in each policy gateway. + + After policy gateway initialization, we observed that each policy + gateway immediately determined the connectivity to policy gateways in + its own domain and in the adjacent domains. The representative + policy gateway in each domain then generated a routing information + message that was received by all other policy gateways in the + internetwork. + + To test the route generation and path setup functionality of the IDPR + prototype software, we began a telnet session between a host in AD S + and a host in AD D. We observed that the telnet traffic prompted the + path agent resident in the policy gateway in AD S to request a policy + route from its route server. The route server then generated a + policy route and returned it to the path agent. Using the policy + route supplied by the route server, the path agent initiated path + setup, and the telnet session was established immediately. + + Having confirmed that the prototype software satisfactorily performed + the basic IDPR functions, we proceeded to test the software under + changing network conditions. The first of these tests showed that + the IDPR prototype software was able to deal successfully with a + component failure along a path. To simulate a path component + failure, we terminated the IDPR processes on a policy gateway in the + transit domain, AD T1, traversed by the current path. The policy + gateways on either side of the failed policy gateway immediately + detected the failure. Next, these two policy gateways, representing + two different domains, each issued a routing information message + indicating the connectivity change and each initiated path teardown + for its remaining path section. + + Once the path was torn down, the path agent agent in AD S requested a + new route from its route server, to carry the existing telnet + traffic. The route server, having received the new routing + information messages, proceeded to generate a policy route through + the other transit domain, AD T2. Then, the path agent in AD S set up + a path for the new route supplied by the route server. Throughout + the component failure and traffic rerouting, the telnet session + remained intact. + + At this point, we restored the failed policy gateway in AD T1 to the + functional state, by restarting its IDPR processes. The restored + policy gateway connectivity prompted the generation and distribution + of routing information messages indicating the change in domain + connectivity. + + + + + +Steenstrup [Page 11] + +RFC 1477 IDPR July 1993 + + + Having returned the internetwork topology to its initial + configuration, we proceeded to test that the IDPR prototype software + was able to deal successfully with transit policy reconfiguration. + The current policy route carrying the telnet traffic traversed AD T2. + We then reconfigured the transit policy for AD T2 to preclude access + of traffic travelling from AD S to AD D. The transit policy + reconfiguration prompted both the distribution of routing information + advertising the new transit policy for AD T2 and the initiation of + path teardown. + + Once the path was torn down, the path agent in AD S requested a new + route from its route server, to carry the existing telnet traffic. + The route server, having received the new routing information + message, proceeded to generate a policy route through the original + transit domain, AD T1. Then, the path agent in AD S set up a path + for the new route supplied by the route server. Throughout the + policy reconfiguration and rerouting, the telnet session remained + intact. + + This set of experiments, although simple, tested all of the major + functionality of the IDPR prototype software and demonstrated that + the prototype software could quickly and accurately adapt to changes + in the internetwork. + +7.1.3 Performance Analysis + + We (USC and SAIC members of the IDPR development group) evaluated the + performance of the path setup and message forwarding portions of the + IDPR prototype software. For path setup, we measured the amount of + processing required at the source path agent and at intermediate + policy gateways during path setup. For message forwarding, we + compared the processing required at each policy gateway when using + IDPR forwarding with IP encapsulation and when using only IP + forwarding. We also compared the processing required when no + integrity/authentication value was calculated for the message and + when the RSA/MD4 algorithms were employed. + + Our performance measurements were encouraging, but we have not listed + them here. We emphasize that although we tried to produce efficient + software for the IDPR prototype, we were not able to devote much + effort to optimizing this software. Hence, the performance + measurements for the IDPR prototype software should not be blindly + extrapolated to other implementations of IDPR. To obtain a copy of + the performance measurements for path setup and message forwarding in + the IDPR prototype software, contact Robert Woodburn + (woody@sparta.com) and Deborah Estrin (estrin@usc.edu). + + + + + +Steenstrup [Page 12] + +RFC 1477 IDPR July 1993 + + +7.2 The Gated Version + + In 1992, SRI joined the IDPR development group, and together SRI, + SAIC, and BBN completed the task of integrating IDPR into the gated + UNIX process. As a result, IDPR is now available as part of gated. + The gated version of IDPR contains the full functionality of IDPR + together with a simple yet versatile user interface for IDPR + configuration. As a single process, the gated version of IDPR + performs more efficiently than the multiple-process prototype + version. + + The gated version of IDPR is freely available to the Internet + community. Hence, anyone with a UNIX-based machine can experiment + with IDPR, without investing any money or implementation effort. By + making IDPR widely accessible, we can gain Internet experience by + introducing IDPR into operational networks with real usage + constraints and transporting host traffic with real service + requirements. Currently, a pilot deployment and demonstration of + IDPR is under way in selected locations in the Internet. + +8. Security Considerations + + Refer to section 4 for details on security in IDPR. + +9. Author's Address + + Martha Steenstrup + BBN Systems and Technologies + 10 Moulton Street + Cambridge, MA 02138 + + Phone: (617) 873-3192 + Email: msteenst@bbn.com + + + + + + + + + + + + + + + + + + +Steenstrup [Page 13] + \ No newline at end of file -- cgit v1.2.3