rfc1479.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   header, prior to stripping it off.  Specifically, the recipient
   policy gateway should verify that the source address and the
   destination address in the encapsulating header match the adjacent
   policy gateway's address and its own address, respectively.
   Moreover, the recipient policy gateway should verify that the message
   arrived on the interface designated for the direct connection to the
   adjacent policy gateway.  These checks help to ensure that IDPR
   traffic that crosses domain boundaries does so only over direct
   connections between adjacent policy gateways.

   Policy gateways forward IDPR data messages according to a forwarding
   information database which maps "path identifiers", carried in the
   data messages, into next policy gateways.  Policy gateways forward
   IDPR control messages according to next policy gateways selected by
   the particular IDPR control protocols associated with the messages.
   Distinguishing IDPR data messages and IDPR control messages at the
   encapsulating protocol level, instead of at the IDPR protocol level,
   eliminates an extra level of dispatching and hence makes IDPR message
   forwarding more efficient.  When encapsulated within IP messages,
   IDPR data messages and IDPR control messages carry the IP protocol
   numbers 35 and 38, respectively.

1.5.1.  IDPR Data Message Format

   The path agents at a source domain determine which data messages
   generated by local hosts are to be handled by IDPR.  To each data
   message selected for IDPR handling, a source path agent prepends the
   following header:













Steenstrup                                                     [Page 11]

RFC 1479                     IDPR Protocol                     July 1993


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    VERSION    |     PROTO     |            LENGTH             |
   +---------------+---------------+-------------------------------+
   |                            PATH ID                            |
   |                                                               |
   +---------------------------------------------------------------+
   |                           TIMESTAMP                           |
   +---------------------------------------------------------------+
   |                            INT/AUTH                           |
   |                                                               |
   +---------------------------------------------------------------+

   VERSION (8 bits) Version number for IDPR data messages, currently
   equal to 1.

   PROTO (8 bits) Numeric identifier for the protocol with which to
   process the contents of the IDPR data message.  Only the path agent
   at the destination interprets and acts upon the contents of the PROTO
   field.

   LENGTH (16 bits) Length of the entire IDPR data message in bytes.

   PATH ID (64 bits) Path identifier assigned by the source's path agent
   and consisting of the numeric identifier for the path agent's domain
   (16 bits), the numeric identifier for the path agent's policy gateway
   (16 bits), and the path agent's local path identifier (32 bits) (see
   section 7.2).

   TIMESTAMP (32 bits) Number of seconds elapsed since 1 January 1970
   0:00 GMT.

   INT/AUTH (variable) Computed integrity/authentication value,
   dependent on the type of integrity/authentication requested during
   path setup.

   We describe the IDPR control message header in section 2.4.

1.6.  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.

   All IDPR messages carry a single piece of information, referred to as



Steenstrup                                                     [Page 12]

RFC 1479                     IDPR Protocol                     July 1993


   the "integrity/authentication value", which may be used not only to
   detect message corruption but also to verify the authenticity of the
   message source.  In the Internet, the IANA will sanction the set of
   valid algorithms which may be used to compute the
   integrity/authentication 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 control message originating at an entity in one domain
   can be properly checked by an entity in another domain.

   Each IDPR control message 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 [17],
   which simultaneously verifies message integrity and source
   authenticity.  The digital signature may be based on either public-
   key or private-key cryptography.  Our approach to digital signature
   use in IDPR is based on the privacy-enhanced Internet electronic mail
   service [13]-[15], already available in the Internet.

   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, and not IDPR, assume responsibility for
   checking the integrity and authenticity of data messages, because of
   the amount of computation involved.

1.7.  Timestamps and Clock Synchronization

   Each IDPR message carries a timestamp (expressed in seconds elapsed
   since 1 January 1970 0:00 GMT, following the UNIX precedent) supplied
   by the source IDPR entity, which serves to indicate the age of the
   message.  IDPR entities use the absolute value of the timestamp to
   confirm that a message is current and use the relative difference
   between timestamps to determine which message contains the more
   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.



Steenstrup                                                     [Page 13]

RFC 1479                     IDPR Protocol                     July 1993


   Thus, a clock synchronization protocol operating among all IDPR
   entities in all domains, while useful, is not necessary.

   An IDPR entity can determine whether to accept or reject a message
   based on the discrepancy between the message's timestamp and the
   entity's own internal clock time.  Any IDPR 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.
   Timestamp checks are required for control messages because of the
   consequences of propagating and acting upon incorrect control
   information.  However, timestamp checks are discretionary for data
   messages but may be invoked during problem diagnosis, for example,
   when checking for suspected message replays.

   We note that none of the IDPR protocols contain explicit provisions
   for dealing with an exhausted timestamp space.  As timestamp space
   exhaustion will not occur until well into the next century, we expect
   timestamp space viability to outlast the IDPR protocols.

1.8.  Network Management

   In this document, we do not describe how to configure and manage
   IDPR.  However, in this section, we do provide a list of the types of
   IDPR configuration information required.  Also, in later sections
   describing the IDPR protocols, we briefly note the types of
   exceptional events that must be logged for network management.
   Complete descriptions of IDPR entity configuration and IDPR managed
   objects appear in [7] and [8] respectively.

   To participate in inter-domain policy routing, policy gateways and
   route servers within a domain each require configuration information.
   Some of the configuration information is specifically defined within
   the given domain, while some of the configuration information is
   universally defined throughout an internetwork.  A domain
   administrator determines domain-specific information, and in the
   Internet, the IANA determines globally significant information.

   To produce valid domain configurations, the domain administrators
   must receive the following global information from the IANA:

   - For each integrity/authentication type, the numeric
     identifier, syntax, and semantics.  Available integrity and
     authentication types include but are not limited to:

       o    public-key based signatures;

       o    private-key based signatures;



Steenstrup                                                     [Page 14]

RFC 1479                     IDPR Protocol                     July 1993



       o    cyclic redundancy checksums;

       o    no integrity/authentication.

   - For each user class, the numeric identifier, syntax, and
     semantics.  Available user classes include but are not limited to:

       o    federal (and if necessary, agency-specific such as NSF, DOD,
            DOE, etc.);

       o    research;

       o    commercial;

       o    support.

   - For each offered service that may be advertised in transit
     policies, the numeric identifier, syntax, and semantics.  Available
     offered services include but are not limited to:

       o    average message delay;

       o    message delay variation;

       o    average bandwidth available;

       o    available bandwidth variation;

       o    maximum transfer unit (MTU);

       o    charge per byte;

       o    charge per message;

       o    charge per unit time.

   - For each access restriction that may be advertised in transit
     policies, the numeric identifier, syntax, and semantics.  Available
     access restrictions include but are not limited to:

       o    Source and destination domains and host sets.

       o    User classes.

       o    Entry and exit virtual gateways.

       o    Time of day.



Steenstrup                                                     [Page 15]

RFC 1479                     IDPR Protocol                     July 1993


   - For each requested service that may appear within a path setup
     message, the numeric identifier, syntax, and semantics.  Available
     requested services include but are not limited to:

       o    maximum path life in minutes, messages, or bytes;

       o    integrity/authentication algorithms to be used on data
            messages sent over the path;

       o    upper bound on path delay;

       o    minimum delay path;

       o    upper bound on path delay variation;

       o    minimum delay variation path;

       o    lower bound on path bandwidth;