rfc1478.txt

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

   does the potential for both information corruption and denial of
   service attacks.  Thus, we have imbued the IDPR architecture with a
   variety of mechanisms to:

   - Promote timely delivery of control information.

   - Minimize acceptance and distribution of corrupted control
     information.

   - Verify authenticity of a source of control information.

   - Reduce the chances for certain types of denial of service attacks.

   Consult [11] for a general security architecture for routing and [12]
   for a security architecture for inter-domain routing.

3.3.1.  Retransmissions and Acknowledgements

   All IDPR entities must make an effort to accept and distribute only
   correct IDPR control messages.  Each IDPR entity that transmits an
   IDPR control message expects an acknowledgement from the recipient
   and must retransmit the message up to a maximum number of times when
   an acknowledgement is not forthcoming.  An IDPR entity that receives
   an IDPR control message must verify message content integrity and
   source authenticity before accepting, acknowledging, and possibly
   redistributing the message.

3.3.2.  Integrity Checks

   Integrity checks on message contents promote the detection of
   corrupted information.  Each IDPR entity that receives an IDPR
   control message must perform several integrity checks on the
   contents.  Individual IDPR protocols may apply more stringent
   integrity checks than those listed below.  The required checks
   include confirmation of:

   - Recognized message version.

   - Consistent message length.

   - Valid message checksum.

   Each IDPR entity may also apply these integrity checks to IDPR data
   messages.  Although the IDPR architecture only requires data message
   integrity checks at the last IDPR entity on a path, it does not
   preclude intermediate policy gateways from performing these checks as



Steenstrup                                                     [Page 20]

RFC 1478                   IDPR Architecture                   June 1993


   well.

3.3.3.  Source Authentication

   Authentication of a message's source promotes the detection of a
   rogue entity masquerading as another legitimate entity.  Each IDPR
   entity that receives an IDPR control message must verify the
   authenticity of the message source.  We recommend that the source of
   the message supply a digital signature for authentication by message
   recipients.  The digital signature should cover the entire message
   contents (or a hash function thereof), so that it can serve as the
   message checksum as well as the source authentication information.

   Each IDPR entity may also authenticate the source of IDPR data
   messages; however, the IDPR architecture does not require source
   authentication of data messages.  Instead, we recommend that higher
   level (end-to-end) protocols, not IDPR, assume the responsibility for
   data message source authentication, because of the amount of
   computation involved in verifying a digital signature.

3.3.4.  Timestamps

   Message timestamps promote the detection of out-of-date messages as
   well as message replays.  Each IDPR control message must carry a
   timestamp supplied by the source, 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.  Hence, 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 the IDPR architecture is on
   the order of minutes and can be achieved manually.

   Each IDPR entity that receives an IDPR control message must check
   that the message is timely.  Any IDPR control message whose timestamp
   lies outside of the acceptable range may contain stale or corrupted
   information or may have been issued by a source whose internal clock
   has lost synchronization with the message recipient's internal clock.

   IDPR data messages also carry timestamps; however, the IDPR
   architecture does not require timestamp acceptability checks on IDPR
   data messages.  Instead, we recommend that IDPR entities only check
   IDPR data message timestamps during problem diagnosis, for example,
   when checking for suspected message replays.

3.4.  An Example of IDPR Operation




Steenstrup                                                     [Page 21]

RFC 1478                   IDPR Architecture                   June 1993


   We illustrate how IDPR works by stepping through an example.  In this
   example, we assume that all domains support IDPR and that all domain
   egress points are policy gateways.

   Suppose host Hx in domain AD X wants to communicate with host Hy in
   domain AD Y.  Hx need not know the identity of its own domain or of
   Hy's domain in order to send messages to Hy.  Instead, Hx simply
   forwards a message bound for Hy to one of the gateways on its local
   network, according to its local forwarding information.  If the
   recipient gateway is a policy gateway, the resident path agent
   determines how to forward the message outside of the domain.
   Otherwise, the recipient gateway forwards the message to another
   gateway in AD X, according to its local forwarding information.
   Eventually, the message will arrive at a policy gateway in AD X, as
   described previously in section 3.2.1.

   The path agent resident in the recipient policy gateway uses the
   message header, including source and destination addresses and any
   requested service information (for example, type of service), in
   order to determine whether it is an intra-domain or inter-domain
   message, and if inter-domain, whether it requires an IDPR policy
   route.  Specifically, the path agent attempts to locate a forwarding
   information database entry for the given traffic flow.  The
   forwarding information database will already contain entries for all
   of the following:

   - All intra-domain traffic flows.  Intra-domain forwarding information
     is integrated into the forwarding database as soon as it is received.

   - Inter-domain traffic flows that do not require IDPR policy routes.
     Non-IDPR inter-domain forwarding information is integrated into the
     forwarding database as soon as it is received.

   - IDPR inter-domain traffic flows for which a path has already been set
     up.  IDPR forwarding information is integrated into the forwarding
     database only during path setup.

   The path agent uses the message header contents to guide the search
   for a forwarding information database entry for a traffic flow; we
   suggest a radix search to locate a database entry.  When the search
   terminates, it either produces a forwarding information database
   entry or a directive to generate such an entry for an IDPR traffic
   flow.  If the search terminates in an existing database entry, the
   path agent forwards the message according to that entry.

   Suppose that the search terminates indicating that the traffic flow
   between Hx and Hy requires an IDPR route and that no forwarding
   information database entry yet exists for this flow.  In this case,



Steenstrup                                                     [Page 22]

RFC 1478                   IDPR Architecture                   June 1993


   the path agent first determines the source and destination domains
   associated with the message's source and destination addresses,
   before attempting to obtain a policy route.  The path agent relies on
   the mapping servers to supply the domain information, but it caches
   all mapping server responses locally to limit the number of future
   queries.  When attempting to resolve an address to a domain, the path
   agent always checks its local cache before contacting a mapping
   server.

   After obtaining the source and destination domain information, the
   path agent attempts to obtain a policy route to carry the traffic
   from Hx to Hy.  The path agent relies on the route servers to supply
   policy routes, but it caches all route server responses locally to
   limit the number of future queries.  When attempting to locate a
   suitable policy route, the path agent consults its local cache before
   contacting a route server.  A policy route contained in the cache is
   suitable provided that its associated source domain is AD X, its
   associated destination domain is AD Y, and it satisfies the service
   requirements specified in the data message or through source policy
   configuration.

   If no suitable cache entry exists, the path agent queries the route
   server, providing it with the source and destination domains together
   with the requested services.  Upon receiving a policy route query, a
   route server consults its route database.  If it cannot locate a
   suitable route in its route database, the route server attempts to
   generate at least one route to domain AD Y, consistent with the
   requested services for Hx.

   The response to a successful route query consists of a set of
   candidate routes, from which the path agent makes its selection.  We
   expect that a path agent will normally choose a single route from a
   candidate set.  Nevertheless, the IDPR architecture does not preclude
   a path agent from selecting multiple routes from the candidate set.
   A path agent may desire multiple routes to support features such as
   fault tolerance or load balancing; however, the IDPR architecture
   does not specify how the path agent should use multiple routes.  In
   any case, a route server always returns a response to a path agent's
   query, even if it is not successful in locating a suitable policy
   route.

   If the policy route is a new route provided by the route server,
   there will be no existing path for the route and thus the path agent
   must set up such a path.  However, if the policy route is an existing
   route extracted from the path agent's cache, there may well be an
   existing path for the route, set up to accommodate a different host
   traffic flow.  The IDPR architecture permits multiple host traffic
   flows to use the same path, provided that all flows sharing the path



Steenstrup                                                     [Page 23]

RFC 1478                   IDPR Architecture                   June 1993


   travel between the same endpoint domains and have the same service
   requirements.  Nevertheless, the IDPR architecture does not preclude
   a path agent from setting up distinct paths along the same policy
   route to preserve the distinction between host traffic flows.

   The path agent associates an identifier with the path, which will be
   included in each message that travels down the path and will be used
   by the policy gateways along the path in order to determine how to
   forward the message.  If the path already exists, the path agent uses
   the preexisting identifier.  However, for new paths, the path agent
   chooses a path identifier that is different from those of all other
   paths that it manages.  The path agent also updates its forwarding
   information database to reference the path identifier and modifies
   its search procedure to yield the correct forwarding information
   database entry given the data message header.

   For new paths, the path agent initiates path setup, communicating the
   policy route, in terms of requested services, constituent domains,
   relevant transit policies, and the connecting virtual gateways, to
   policy gateways in intermediate domains.  Using this information, an
   intermediate policy gateway determines whether to accept or refuse
   the path and to which policy gateway to forward the path setup
   information.  The path setup procedure allows policy gateways to set
   up a path in both directions simultaneously.  Each intermediate
   policy gateway, after path acceptance, updates its forwarding
   information database to include an entry that associates the path
   identifier with the appropriate previous and next hop policy
   gateways.  Paths remain in place until they are torn down because of
   failure, expiration, or when resources are scarce, preemption in
   favor of other paths.

   When a policy gateway in AD Y accepts a path, it notifies the source
   path agent in AD X.  We expect that the source path agent will
   normally wait until a path has been successfully established before
   using it to transport data traffic.  However, the IDPR architecture
   does not preclude a path agent from forwarding data messages along a
   path prior to confirmation of successful path establishment.  In this
   case, the source path agent transmits data messages along the path
   with full knowledge that the path may not yet have been successfully
   established at all intermediate policy gateways and thus that these
   data messages will be immediately discarded by any policy gateway not
   yet able to recognize the path identifier.

   We note that data communication between Hx and Hy may occur over two
   separate IDPR paths: one from AD X to AD Y and one from AD Y to AD X.