rfc2747.txt

<VC++网络游戏建摸与实现>源代码

   to be larger than any possible value of the counter at the time of
   the failure.  This can be computed, knowing the interval at which the
   counter was saved to stable storage and incrementing the stored value
   by that amount.

3.2.  Sequence Numbers Based on a Real Time Clock

   Most devices will probably not have the capability to save sequence
   number counters to stable storage for each key.  A more universal
   solution is to base sequence numbers on the stable storage of a real
   time clock.  Many computing devices have a real time clock module
   that includes stable storage of the clock.  These modules generally
   include some form of nonvolatile memory to retain clock information
   in the event of a power failure.

   In this approach, we could use an NTP based timestamp value as the
   sequence number.  The roll-over period of an NTP timestamp is about
   136 years, much longer than any reasonable lifetime of a key.  In
   addition, the granularity of the NTP timestamp is fine enough to
   allow the generation of an RSVP message every 200 picoseconds for a
   given key.  Many real time clock modules do not have the resolution
   of an NTP timestamp.  In these cases, the least significant bits of
   the timestamp can be generated using a message counter, which is
   reset every clock tick.  For example, when the real time clock
   provides a resolution of 1 second, the 32 least significant bits of
   the sequence number can be generated using a message counter.  The
   remaining 32 bits are filled with the 32 least significant bits of
   the timestamp.  Assuming that the recovery time after failure takes
   longer than one tick of the real time clock, the message counter for
   the low order bits can be safely reset to zero after a restart.

3.3.  Sequence Numbers Based on a Network Recovered Clock

   If the device does not contain any stable storage of sequence number
   counters or of a real time clock, it could recover the real time
   clock from the network using NTP.  Once the clock has been recovered
   following a restart, the sequence number generation procedure would
   be identical to the procedure described above.




Baker, et al.               Standards Track                     [Page 6]

RFC 2747           RSVP Cryptographic Authentication       January 2000


4.  Message Processing

   Implementations SHOULD allow specification of interfaces that are to
   be secured, for either sending messages, or receiving them, or both.
   The sender must ensure that all RSVP messages sent on secured sending
   interfaces include an INTEGRITY object, generated using the
   appropriate Key.  Receivers verify whether RSVP messages, except of
   the type "Integrity Challenge" (Section 4.3), arriving on a secured
   receiving interface contain the INTEGRITY object.  If the INTEGRITY
   object is absent, the receiver discards the message.

   Security associations are simplex - the keys that a sending system
   uses to sign its messages may be different from the keys that its
   receivers use to sign theirs.  Hence, each association is associated
   with a unique sending system and (possibly) multiple receiving
   systems.

   Each sender SHOULD have distinct security associations (and keys) per
   secured sending interface (or LIH).  While administrators may
   configure all the routers and hosts on a subnet (or for that matter,
   in their network) using a single security association,
   implementations MUST assume that each sender may send using a
   distinct security association on each secured interface.  At the
   sender, security association selection is based on the interface
   through which the message is sent.  This selection MAY include
   additional criteria, such as the destination address (when sending
   the message unicast, over a broadcast LAN with a large number of
   hosts) or user identities at the sender or receivers [2].  Finally,
   all intended message recipients should participate in this security
   association.  Route flaps in a non RSVP cloud might cause messages
   for the same receiver to be sent on different interfaces at different
   times.  In such cases, the receivers should participate in all
   possible security associations that may be selected for the
   interfaces through which the message might be sent.

   Receivers select keys based on the Key Identifier and the sending
   system's IP address.  The Key Identifier is included in the INTEGRITY
   object.  The sending system's address can be obtained either from the
   RSVP_HOP object, or if that's not present (as is the case with
   PathErr and ResvConf messages) from the IP source address.  Since the
   Key Identifier is unique for a sender, this method uniquely
   identifies the key.

   The integrity mechanism slightly modifies the processing rules for
   RSVP messages, both when including the INTEGRITY object in a message
   sent over a secured sending interface and when accepting a message
   received on a secured receiving interface.  These modifications are
   detailed below.



Baker, et al.               Standards Track                     [Page 7]

RFC 2747           RSVP Cryptographic Authentication       January 2000


4.1.  Message Generation

   For an RSVP message sent over a secured sending interface, the
   message is created as described in [1], with these exceptions:

     (1)  The RSVP checksum field is set to zero.  If required, an RSVP
          checksum can be calculated when the processing of the
          INTEGRITY object is complete.

     (2)  The INTEGRITY object is inserted in the appropriate place, and
          its location in the message is remembered for later use.

     (3)  The sending interface and other appropriate criteria (as
          mentioned above) are used to determine the Authentication Key
          and the hash algorithm to be used.

     (4)  The unused flags and the reserved field in the INTEGRITY
          object MUST be set to 0.  The Handshake Flag (HF) should be
          set according to rules specified in Section 2.1.

     (5)  The sending sequence number MUST be updated to ensure a
          unique, monotonically increasing number.  It is then placed in
          the Sequence Number field of the INTEGRITY object.

     (6)  The Keyed Message Digest field is set to zero.

     (7)  The Key Identifier is placed into the INTEGRITY object.

     (8)  An authenticating digest of the message is computed using the
          Authentication Key in conjunction with the keyed-hash
          algorithm.  When the HMAC-MD5 algorithm is used, the hash
          calculation is described in [7].

     (9)  The digest is written into the Cryptographic Digest field of
          the INTEGRITY object.

4.2.  Message Reception

   When the message is received on a secured receiving interface, and is
   not of the type "Integrity Challenge", it is processed in the
   following manner:


     (1)  The RSVP checksum field is saved and the field is subsequently
          set to zero.

     (2)  The Cryptographic Digest field of the INTEGRITY object is
          saved and the field is subsequently set to zero.



Baker, et al.               Standards Track                     [Page 8]

RFC 2747           RSVP Cryptographic Authentication       January 2000


     (3)  The Key Identifier field and the sending system address are
          used to uniquely determine the Authentication Key and the hash
          algorithm to be used.  Processing of this packet might be
          delayed when the Key Management System (Appendix 1) is queried
          for this information.

     (4)  A new keyed-digest is calculated using the indicated algorithm
          and the Authentication Key.

     (5)  If the calculated digest does not match the received digest,
          the message is discarded without further processing.

     (6)  If the message is of type "Integrity Response", verify that
          the CHALLENGE object identically matches the originated
          challenge.  If it matches, save the sequence number in the
          INTEGRITY object as the largest sequence number received to
          date.

          Otherwise, for all other RSVP Messages, the sequence number is
          validated to prevent replay attacks, and messages with invalid
          sequence numbers are ignored by the receiver.

          When a message is accepted, the sequence number of that
          message could update a stored value corresponding to the
          largest sequence number received to date.  Each subsequent
          message must then have a larger (modulo 2^64) sequence number
          to be accepted.  This simple processing rule prevents message
          replay attacks, but it must be modified to tolerate limited
          out-of-order message delivery.  For example, if several
          messages were sent in a burst (in a periodic refresh generated
          by a router, or as a result of a tear down function), they
          might get reordered and then the sequence numbers would not be
          received in an increasing order.

          An implementation SHOULD allow administrative configuration
          that sets the receiver's tolerance to out-of-order message
          delivery.  A simple approach would allow administrators to
          specify a message window corresponding to the worst case
          reordering behavior.  For example, one might specify that
          packets reordered within a 32 message window would be
          accepted.  If no reordering can occur, the window is set to
          one.

          The receiver must store a list of all sequence numbers seen
          within the reordering window.  A received sequence number is
          valid if (a) it is greater than the maximum sequence number
          received or (b) it is a past sequence number lying within the
          reordering window and not recorded in the list.  Acceptance of



Baker, et al.               Standards Track                     [Page 9]

RFC 2747           RSVP Cryptographic Authentication       January 2000


          a sequence number implies adding it to the list and removing a
          number from the lower end of the list.  Messages received with
          sequence numbers lying below the lower end of the list or
          marked seen in the list are discarded.

   When an "Integrity Challenge" message is received on a secured
   sending interface it is processed in the following manner:

     (1)  An "Integrity Response" message is formed using the Challenge
          object received in the challenge message.

     (2)  The message is sent back to the receiver, based on the source
          IP address of the challenge message, using the "Message
          Generation" steps outlined above.  The selection of the
          Authentication Key and the hash algorithm to be used is
          determined by the key identifier supplied in the challenge
          message.

4.3.  Integrity Handshake at Restart or Initialization of the Receiver

   To obtain the starting sequence number for a live Authentication Key,
   the receiver MAY initiate an integrity handshake with the sender.
   This handshake consists of a receiver's Challenge and the sender's
   Response, and may be either initiated during restart or postponed
   until a message signed with that key arrives.

   Once the receiver has decided to initiate an integrity handshake for
   a particular Authentication Key, it identifies the sender using the
   sending system's address configured in the corresponding security
   association.  The receiver then sends an RSVP Integrity Challenge
   message to the sender.  This message contains the Key Identifier to
   identify the sender's key and MUST have a unique challenge cookie
   that is based on a local secret to prevent guessing.  see Section
   2.5.3 of [4]).  It is suggested that the cookie be an MD5 hash of a
   local secret and a timestamp to provide uniqueness (see Section 9).

   An RSVP Integrity Challenge message will carry a message type of 11.
   The message format is as follows:

     <Integrity Challenge message> ::= <Common Header> <CHALLENGE>











Baker, et al.               Standards Track                    [Page 10]

RFC 2747           RSVP Cryptographic Authentication       January 2000


   he CHALLENGE object has the following format:

                CHALLENGE Object: Class = 64, C-Type = 1

       +-------------+-------------+-------------+-------------+
       |        0 (Reserved)       |                           |
       +-------------+-------------+                           +
       |                    Key Identifier                     |
       +-------------+-------------+-------------+-------------+
       |                    Challenge Cookie                   |
       |                                                       |
       +-------------+-------------+-------------+-------------+

   The sender accepts the "Integrity Challenge" without doing an
   integrity check.  It returns an RSVP "Integrity Response" message
   that contains the original CHALLENGE object.  It also includes an
   INTEGRITY object, signed with the key specified by the Key Identifier
   included in the "Integrity Challenge".

   An RSVP Integrity Response message will carry a message type of 12.
   The message format is as follows:

     <Integrity Response message> ::= <Common Header> <INTEGRITY>
                                      <CHALLENGE>