rfc1477.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 731 行 · 第 1/3 页

   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