idnits 2.17.1 draft-ietf-idpr-summary-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 174 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 1992) is 11722 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Policy Routing Working Group M. Steenstrup 3 Internet Draft BBN Communications 4 March 1992 6 IDPR as a Proposed Standard 8 Executive Summary 10 The IDPR working group of the IETF is submitting to the IESG, for 11 consideration as a proposed standard, the set of protocols and procedures 12 that compose inter-domain policy routing (IDPR). In accordance with the 13 requirements stipulated by RFC 1264, we present justification for proposed 14 standard status of IDPR. 16 The objective of IDPR is to construct and maintain routes between source 17 and destination administrative domains, that provide user traffic with the 18 services requested within the constraints stipulated for the domains 19 transited. 21 Four documents describe IDPR in detail: 23 1. M. Lepp and M. Steenstrup. An architecture for inter-domain policy 24 routing. Internet Draft. March 1992. 26 2. M. Steenstrup. Inter-domain policy routing protocol specification: 27 version 1. Internet Draft. March 1992. 29 3. H. Bowns and M. Steenstrup. Inter-domain policy routing configuration 30 and usage. Internet Draft. March 1992. 32 4. R. Woodburn. Definitions of managed objects for inter-domain policy 33 routing (version 1). Internet Draft. March 1992. 35 We request that neither the MIB nor the configuration guide be considered 36 for proposed standard status at this time. Instead, we will submit these 37 documents for proposed standard consideration, after we have gained more 38 experience in using both the MIB and the configuration guide. 40 1 The Internet Environment 42 As data communications technologies evolve and user populations grow, the 43 demand for internetworking increases. The Internet currently comprises over 44 4000 operational networks and over 10,000 registered networks. In fact, for 45 the last several years, the number of constituent networks has approximately 46 doubled annually. Although we do not expect the Internet to sustain this 47 growth rate, we must prepare for the Internet of five to ten years in the 48 future. 50 Internet connectivity has increased along with the number of component 51 networks. Internetworks proliferate through interconnection of autonomous, 52 heterogeneous networks administered by separate authorities. We use the 53 term administrative domain (AD) to refer to any collection of contiguous 54 networks, gateways, links, and hosts governed by a single administrative 55 authority that selects the intra-domain routing procedures and addressing 56 schemes, defines service requirements for locally-generated traffic, and 57 specifies service restrictions for transit traffic. 59 In the early 1980s, the Internet was purely hierarchical, with the 60 ARPANET as the single backbone. The current Internet possesses a semblance 61 of a hierarchy in the collection of backbone, regional, metropolitan, and 62 campus domains that compose it. However, technological, economical, and 63 political incentives have prompted the introduction of inter-domain links 64 outside of those in the strict hierarchy. Hence, the Internet has the 65 properties of both hierarchical and mesh connectivity. 67 We expect that, over the next five years, the Internet will grow to 68 contain O(10) backbone domains, most providing connectivity between many 69 source and destination domains and offering a wide range of qualities of 70 service, for a fee. Most domains will connect directly or indirectly to at 71 least one Internet backbone domain, in order to communicate with other 72 domains. In addition, some domains may install direct links to their most 73 favored destinations. Domains at the lower levels of the hierarchy will 74 provide some transit service, limited to traffic between selected sources 75 and destinations. However, the majority of Internet domains will be stubs, 76 that is, domains that do not provide any transit service for any other 77 domains but that connect directly to one or more transit domains. 79 The bulk of Internet traffic will be generated by hosts in the stub 80 domains, and thus, the applications running in these hosts will determine 81 the traffic service requirements. We expect application diversity 82 encompassing electronic mail, desktop videoconferencing, scientific 83 visualization, and distributed simulation, for example. Many of these 85 1 86 applications have strict requirements on delivery, delay, and bandwidth. 88 In such a large and heterogeneous Internet, the routing procedures must 89 be capable of ensuring that traffic is forwarded along routes that offer the 90 required services without violating domain usage restrictions. We believe 91 that IDPR meets this goal; it has been designed to accommodate an Internet 92 comprising O(104) administrative domains with diverse service offerings and 93 requirements. 95 2 96 2 An Overview of IDPR 98 IDPR generates, establishes, and maintains policy routes that satisfy the 99 service requirements of the users and respect the service restrictions of 100 the transit domains. Policy routes are constructed using information about 101 the services offered by and the connectivity between administrative domains 102 and information about the services requested by the users. 104 2.1 Policies 106 With IDPR, each domain administrator sets transit policies that dictate 107 how and by whom the resources in its domain should be used. Transit 108 policies are usually public, and they specify offered services comprising: 110 Accessrestrictions: e.g., applied to traffic to or from certain domains or 111 classes of users. 113 Quality:e.g., delay, throughput, or error characteristics. 115 Monetary cost:e.g., charge per byte, message, or session time. 117 Each domain administrator also sets source policies for traffic originating 118 in its domain. Source policies are usually private, and they specify 119 requested services comprising: 121 Accessrestrictions: e.g., domains to favor or avoid in routes. 123 Quality:e.g., acceptable delay, throughput, and reliability. 125 Monetary cost:e.g., acceptable cost per byte, message, or session time. 127 2.2 Functions 129 The basic IDPR functions include: 131 1. Collecting and distributing routing information, i.e., domain transit 132 policy and connectivity information. IDPR uses link state routing 133 information distribution, so that each source domain may obtain routing 134 information about all other domains. 136 2. Generating and selecting policy routes based on the routing information 137 distributed and on source policy information. IDPR gives each source 138 domain complete control over the routes it generates. 140 3 141 3. Setting up paths across the Internet, using the policy routes 142 generated. 144 4. Forwarding messages across and between administrative domains along the 145 established paths. IDPR uses source-specified message forwarding, 146 giving each source domain complete control over the paths traversed by 147 its hosts' traffic. 149 5. Maintaining databases of routing information, inter-domain policy 150 routes, forwarding information, and configuration information. 152 2.3 Entities 154 Several different entities are responsible for performing the IDPR 155 functions: 157 1. Policy gateways, the only IDPR-recognized connecting points between 158 adjacent domains, collect and distribute routing information, 159 participate in path setup, maintain forwarding information databases, 160 and forward data messages along established paths. 162 2. Path agents, resident within policy gateways, act on behalf of hosts to 163 select policy routes, to set up and manage paths, and to maintain 164 forwarding information databases. Any Internet host can reap the 165 benefits of IDPR, as long as there exists a path agent willing to act 166 on its behalf and a means by which the host's messages can reach that 167 path agent. 169 3. Special-purpose servers maintain all other IDPR databases as follows: 171 (a)Each route server is responsible for both its database of routing 172 information, including domain connectivity and transit policy 173 information, and its database of policy routes. Also, each route 174 server generates policy routes on behalf of its domain, using 175 entries from its routing information database and using source 176 policy information supplied through configuration or obtained 177 directly from the path agents. A route server may reside within a 178 policy gateway, or it may exist as an autonomous entity. 179 Separating the route server functions from the policy gateways 180 frees the policy gateways from both the memory intensive task of 181 routing information database and route database maintenance and the 182 computationally intensive task of route generation. 184 4 185 (b)Each mapping server is responsible for its database of mappings 186 that resolve Internet names and addresses to administrative 187 domains. The mapping server function can be easily integrated into 188 an existing name service such as DNS. 190 (c)Each configuration server is responsible for its database of 191 configured information that applies to policy gateways, path 192 agents, and route servers in the given administrative domain. 193 Configuration information for a given domain includes source and 194 transit policies and mappings between local IDPR entities and their 195 addresses. The configuration server function can be easily 196 integrated into a domain's existing network management system. 198 2.4 Message Handling 200 There are two kinds of IDPR messages: 202 1. Data messages containing user data generated by hosts. 204 2. Control messages containing IDPR protocol-related control information 205 generated by policy gateways and route servers. 207 Within the Internet, only policy gateways and route servers must be able to 208 generate, recognize, and process IDPR messages. Mapping servers and 209 configuration servers perform necessary but ancillary functions for IDPR, 210 and they are not required to execute IDPR protocols. The existence of IDPR 211 is invisible to all other gateways and hosts. Using encapsulation across 212 each domain, an IDPR message tunnels from source to destination across the 213 Internet through domains that may employ disparate intra-domain addressing 214 schemes and routing procedures. 216 5 217 3 Security 219 IDPR contains mechanisms for verifying message integrity and source 220 authenticity and for protecting against certain types of denial of service 221 attacks. It is particularly important to keep IDPR control messages intact, 222 because they carry control information critical to the construction and use 223 of viable policy routes between domains. 225 3.1 Integrity and Authenticity 227 All IDPR messages carry a single piece of information, referred to in the 228 IDPR documentation as the integrity/authentication value, which may be used 229 not only to detect message corruption but also to verify the authenticity of 230 the message's source IDPR entity. The Internet coordinator specifies the 231 set of valid algorithms which may be used to compute the 232 integrity/authentication values. This set may include algorithms that 233 perform only message integrity checks such as n-bit cyclic redundancy 234 checksums (CRCs), as well as algorithms that perform both message integrity 235 and source authentication checks such as signed hash functions of message 236 contents. 238 Each domain administrator is free to select any integrity/authentication 239 algorithm, from the set specified by the Internet coordinator, for computing 240 the integrity/authentication values contained in its domain's messages. 241 However, we recommend that IDPR entities in each domain be capable of 242 executing all of the valid algorithms so that an IDPR message originating at 243 an entity in one domain can be properly checked by an entity in another 244 domain. 246 IDPR control messages must carry a non-null integrity/authentication 247 value. We recommend that control message integrity/authentication be based 248 on a digital signature algorithm, such as MD5, which simultaneously verifies 249 message integrity and source authenticity. The digital signature may be 250 based on either public key or private key cryptography. However, we do not 251 require that IDPR data messages carry a non-null integrity/authentication 252 value. In fact, we recommend that a higher layer (end-to-end) procedure 253 assume responsibility for checking the integrity and authenticity of data 254 messages, because of the amount of computation involved. 256 3.2 Timestamps 258 Each IDPR message carries a timestamp (expressed in seconds elapsed since 259 1 January 1970 0:00 GMT) supplied by the source IDPR entity, which serves to 261 6 262 indicate the age of the message. IDPR entities use the absolute value of a 263 timestamp to confirm that the message is current and use the relative 264 difference between timestamps to determine which message contains the most 265 recent information. All IDPR entities must possess internal clocks that are 266 synchronized to some degree, in order for the absolute value of a message 267 timestamp to be meaningful. The synchronization granularity required by 268 IDPR is on the order of minutes and can be achieved manually. 270 Each IDPR recipient of an IDPR control message must check that the 271 message's timestamp is in the acceptable range. A message whose timestamp 272 lies outside of the acceptable range may contain stale or corrupted 273 information or may have been issued by a source whose clock has lost 274 synchronization with the message recipient. Such messages must therefore be 275 discarded, to prevent propagation of incorrect IDPR control information. We 276 do not require IDPR entities to perform a timestamp acceptability test for 277 IDPR data messages, but instead leave the choice to the individual domain 278 administrators. 280 7 281 4 Size Considerations 283 IDPR provides policy routing among administrative domains and has been 284 designed to accommodate an Internet containing tens of thousands of domains, 285 supporting diverse source and transit policies. 287 In order to construct policy routes, route servers require routing 288 information at the domain level only; no intra-domain details need be 289 included in IDPR routing information. Thus, the size of the routing 290 information database maintained by a route server depends only on the number 291 of domains and transit policies and not on the number hosts, gateways, or 292 networks in the Internet. 294 We expect that, within a domain, a pair of IDPR entities will normally be 295 connected such that when the primary intra-domain route fails, the 296 intra-domain routing procedure will be able to use an alternate route. In 297 this case, a temporary intra-domain failure is invisible at the inter-domain 298 level. Thus, we expect that most intra-domain routing changes will be 299 unlikely to force inter-domain routing changes. 301 Policy gateways distribute routing information only when detectable 302 inter-domain changes occur and may also elect to distribute routing 303 information periodically as a backup. Thus, policy gateways do not often 304 need to generate and distribute routing information messages, and the 305 frequency of distribution of these messages depends only weakly on 306 intra-domain routing changes. 308 IDPR entities rely on intra-domain routing procedures operating within 309 domains to transport inter-domain messages across domains. Hence, IDPR 310 messages must appear well-formed according to the intra-domain routing 311 procedures and addressing schemes in each domain traversed; this requires 312 appropriate header encapsulation of IDPR messages at domain boundaries. 313 Only policy gateways and route servers must be capable of handling 314 IDPR-specific messages; other gateways and hosts simply treat the 315 encapsulated IDPR messages like any other. Thus, for the Internet to 316 support IDPR, only a small proportion of Internet entities require special 317 IDPR software. 319 With domain-level routes, many different traffic flows may use not only 320 the same policy route but also the same path, as long their source domains, 321 destination domains, and requested services are identical. Thus, the size 322 of the forwarding information database maintained by a policy gateway 323 depends on the number of domains and source policies and not on the number 324 of hosts in the Internet. Moreover, memory associated with failed, expired, 326 8 327 or disused paths can be reclaimed for new paths, and thus forwarding 328 information for many paths can be accommodated. 330 9 331 5 Interactions with Other Inter-Domain Routing Procedures 333 We believe that many Internet domains will benefit from the introduction 334 of IDPR. However, the decision to support IDPR in a given domain is an 335 individual one, left to the domain administrator; not all domains must 336 support IDPR. 338 Within a domain that supports IDPR, other inter-domain routing 339 procedures, such as BGP and EGP, can comfortably coexist. Each inter-domain 340 routing procedure is independent of the others. The domain administrator 341 determines the relationship among the inter-domain routing procedures by 342 deciding which of its traffic flows should use which inter-domain routing 343 procedures and by configuring this information for use by the policy 344 gateways. 346 Hosts in stub domains may have strict service requirements and hence will 347 benefit from the policy routing provided by IDPR. However, the stub domain 348 itself need not support IDPR in order for its traffic flows to use IDPR 349 routes. Instead, a proxy domain may perform IDPR functions on behalf of the 350 stub. The proxy domain must be reachable from the stub domain according to 351 an inter-domain routing procedure independent of IDPR. Administrators of the 352 stub and potential proxy domains mutually negotiate the relationship. Once 353 an agreement is reached, the administrator of the stub domain should provide 354 the proxy domain with its hosts' service requirements. 356 IDPR policy routes must traverse a contiguous set of IDPR domains. 357 Hence, the degree of IDPR deployment in transit domains will determine the 358 availability of IDPR policy routes for Internet users. For a given traffic 359 flow, if there exists no contiguous set of IDPR domains between the source 360 and destination, the traffic flow relies on an alternate inter-domain 361 routing procedure to provide a route. However, if there does exist a 362 contiguous set of IDPR domains between the source and destination, the 363 traffic flow may take advantage of policy routes provided by IDPR. 365 6 Implementation Experience 367 To date, there exist two implementations of IDPR: one an independent 368 prototype and the other an integral part of the gated UNIX process. We 369 describe each of these implementations and our experience with them in the 370 following sections. 372 10 373 6.1 The Prototype 375 During the summer of 1990, the IDPR development group consisting of 376 participants from USC, SAIC, and BBN began work on a UNIX-based software 377 prototype of IDPR, designed for implementation in Sun workstations. This 378 prototype consisted of multiple user-level processes to provide the basic 379 IDPR functions together with kernel modifications to speed up IDPR data 380 message forwarding. 382 Most, but not all, of the IDPR functionality was captured in the 383 prototype. In the interests of producing working software as quickly as 384 possible, we intentionally left out of the IDPR prototype support for source 385 policies and for multiple policy gateways connecting two domains. This 386 simplified configuration and route generation without compromising the basic 387 functionality of IDPR. 389 The IDPR prototype software was extensively instrumented to provide 390 detailed information for monitoring its behavior. The instrumentation 391 allowed us to detect events including but not limited to: 393 1. Change in policy gateway connectivity to adjacent domains. 395 2. Change in transit policies configured for a domain. 397 3. Transmission and reception of link state routing information. 399 4. Generation of policy routes, providing a description of the actual 400 route. 402 5. Transmission and reception of path control information. 404 6. Change of path state, such as path setup or teardown. 406 With the extensive behavioral information available, we were able to track 407 most events occurring in our test networks and hence determine whether the 408 prototype software provided the expected functionality. 410 6.1.1 Test Networks 412 In February 1991, the IDPR development group began experimenting with the 413 completed IDPR prototype software. Each IDPR development site had its own 414 testing environment, consisting of a set of interconnected Sun workstations, 415 each workstation performing the functions of a policy gateway and route 416 server: 418 11 419 o USC used a laboratory test network consisting of SPARC1+ workstations, 420 each pair of workstations connected by an Ethernet segment. The 421 topology of the test network could be arbitrarily configured. 423 o SAIC used Sun3 workstations in networks at Sparta and at MITRE. These 424 two sites were connected through Alternet using a 9.6kb SLIP link and 425 through an X.25 path across the DCA EDN testbed. 427 o BBN used SPARC1+ workstations at BBN and ISI connected over both 428 DARTnet and TWBnet. 430 6.1.2 Experiments 432 The principal goal of our experiments with the IDPR prototype software was 433 to provide a proof of concept. In particular, we set out to verify that the 434 IDPR prototype software was able to: 436 1. Monitor connectivity across and between domains. 438 2. Update routing information when inter-domain connectivity changed or 439 when new transit policies were configured. 441 3. Distribute routing information to all domains. 443 4. Generate acceptable policy routes based on current link state routing 444 information. 446 5. Set up and maintain paths for these policy routes. 448 6. Tear down paths that contained failed components, supported stale 449 policies, or attained their maximum age. 451 Furthermore, we wanted to verify that the IDPR prototype software quickly 452 detected and adapted to those events that directly affected policy routes. 454 The internetwork topology on which we based most of our experiments 455 consisted of four distinct administrative domains connected in a ring. Two 456 of the four domains served as host traffic source and destination, AD S 457 and AD D respectively, while the two intervening domains provided transit 458 service for the host traffic, AD T1 and AD T2. AD S and AD D each 459 contained a single policy gateway that connected to two other policy 460 gateways, one in each transit domain. AD T1 and AD T2 each contained at 461 most two policy gateways, each policy gateway connected to the other and to 462 a policy gateway in the source or destination domain. This internetwork 464 12 465 topology provided two distinct inter-domain routes between AD S and AD D, 466 allowing us to experiment with various component failure and transit policy 467 reconfiguration scenarios in the transit domains. 469 For the first set of experiments, we configured transit policies for 470 AD T1 and AD T2 that were devoid of access restrictions. We then 471 initialized each policy gateway in our internetwork, loading in the 472 domain-specific configurations and starting up the IDPR processes. In our 473 experiments, we did not use mapping servers; instead, we configured 474 address/domain mapping tables in each policy gateway. 476 After policy gateway initialization, we observed that each policy gateway 477 immediately determined the connectivity to policy gateways in its own domain 478 and in the adjacent domains. The representative policy gateway in each 479 domain then generated a routing information message that was received by all 480 other policy gateways in the internetwork. 482 To test the route generation and path setup functionality of the IDPR 483 prototype software, we began a telnet session between a host in AD S and a 484 host in AD D. We observed that the telnet traffic prompted the path agent 485 resident in the policy gateway in AD S to request a policy route from its 486 route server. The route server then generated a policy route and returned 487 it to the path agent. Using the policy route supplied by the route server, 488 the path agent initiated path setup, and the telnet session was established 489 immediately. 491 Having confirmed that the prototype software satisfactorily performed the 492 basic IDPR functions, we proceeded to test the software under changing 493 network conditions. The first of these tests showed that the IDPR prototype 494 software was able to deal successfully with a component failure along a 495 path. To simulate a path component failure, we terminated the IDPR 496 processes on a policy gateway in the transit domain, AD T1, traversed by 497 the current path. The policy gateways on either side of the failed policy 498 gateway immediately detected the failure. Next, these two policy gateways, 499 representing two different domains, each issued a routing information 500 message indicating the connectivity change and each initiated path teardown 501 for its remaining path section. 503 Once the path was torn down, the path agent agent in AD S requested a 504 new route from its route server, to carry the existing telnet traffic. The 505 route server, having received the new routing information messages, 506 proceeded to generate a policy route through the other transit domain, 507 AD T2. Then, the path agent in AD S set up a path for the new route 508 supplied by the route server. Throughout the component failure and traffic 510 13 511 rerouting, the telnet session remained intact. 513 At this point, we restored the failed policy gateway in AD T1 to the 514 functional state, by restarting its IDPR processes. The restored policy 515 gateway connectivity prompted the generation and distribution of routing 516 information messages indicating the change in domain connectivity. 518 Having returned the internetwork topology to its initial configuration, 519 we proceeded to test that the IDPR prototype software was able to deal 520 successfully with transit policy reconfiguration. The current policy route 521 carrying the telnet traffic traversed AD T2. We then reconfigured the 522 transit policy for AD T2 to preclude access of traffic travelling from 523 AD S to AD D. The transit policy reconfiguration prompted both the 524 distribution of routing information advertising the new transit policy for 525 AD T2 and the initiation of path teardown. 527 Once the path was torn down, the path agent in AD S requested a new 528 route from its route server, to carry the existing telnet traffic. The 529 route server, having received the new routing information message, proceeded 530 to generate a policy route through the original transit domain, AD T1. 531 Then, the path agent in AD S set up a path for the new route supplied by 532 the route server. Throughout the policy reconfiguration and rerouting, the 533 telnet session remained intact. 535 This set of experiments, although simple, tested all of the major 536 functionality of the IDPR prototype software and demonstrated that the 537 prototype software could quickly and accurately adapt to changes in the 538 internetwork. 540 6.1.3 Performance Analysis 542 We (USC and SAIC members of the IDPR development group) evaluated the 543 performance of the path setup and message forwarding portions of the IDPR 544 prototype software. For path setup, we measured the amount of processing 545 required at the source path agent and at intermediate policy gateways during 546 path setup. For message forwarding, we compared the processing required at 547 each policy gateway when using IDPR forwarding with IP encapsulation and 548 when using only IP forwarding. We also compared the processing required 549 when no integrity/authentication value was calculated for the message and 550 when the MD4 digital signature algorithm was employed. 552 Our performance measurements were encouraging, but we have not listed 553 them here. We emphasize that although we tried to produce efficient 555 14 556 software for the IDPR prototype, we were not able to devote much effort to 557 optimizing this software. Hence, the performance measurements for the IDPR 558 prototype software should not be blindly extrapolated to other 559 implementations of IDPR. To obtain a copy of the performance measurements 560 for path setup and message forwarding in the IDPR prototype software, 561 contact Robert Woodburn (woody@sparta.com) and Deborah Estrin 562 (estrin@usc.edu). 564 6.2 The gated Version 566 The SAIC and BBN members of the IDPR development group, who previously 567 worked on the IDPR prototype, are now nearing completion of the task of 568 integrating IDPR into the gated UNIX process. The gated version of IDPR 569 contains the full functionality of IDPR together with a simple yet versatile 570 user interface for IDPR configuration. As a single process, the gated 571 version of IDPR should perform more efficiently than the multiple-process 572 prototype version. The central respository for the gated IDPR software is 573 cseic.saic.com; to obtain a copy of the current software, contact Robert 574 Woodburn (woody@sparta.com). 576 Once completed, the gated version of IDPR will be freely available to the 577 Internet community. Hence, anyone with a UNIX-based machine can experiment 578 with IDPR, without investing any money or implementation effort. By making 579 IDPR widely accessible, we can begin to gain Internet experience by 580 introducing IDPR into operational networks with real usage constraints 581 transporting host traffic with real service requirements. 583 15