RFC 2747 (rfc2747) - Page 2 of 21

RSVP Cryptographic Authentication

RFC 2747           RSVP Cryptographic Authentication       January 2000


   number.  This allows the message receiver to identify playbacks and
   hence to thwart replay attacks.  The proposed mechanism does not
   afford confidentiality, since messages stay in the clear; however,
   the mechanism is also exportable from most countries, which would be
   impossible were a privacy algorithm to be used.  Note: this document
   uses the terms "sender" and "receiver" differently from [1].  They
   are used here to refer to systems that face each other across an RSVP
   hop, the "sender" being the system generating RSVP messages.

   The message replay prevention algorithm is quite simple.  The sender
   generates packets with monotonically increasing sequence numbers.  In
   turn, the receiver only accepts packets that have a larger sequence
   number than the previous packet.  To start this process, a receiver
   handshakes with the sender to get an initial sequence number.  This
   memo discusses ways to relax the strictness of the in-order delivery
   of messages as well as techniques to generate monotonically
   increasing sequence numbers that are robust across sender failures
   and restarts.

   The proposed mechanism is independent of a specific cryptographic
   algorithm, but the document describes the use of Keyed-Hashing for
   Message Authentication using HMAC-MD5 [7].  As noted in [7], there
   exist stronger hashes, such as HMAC-SHA1; where warranted,
   implementations will do well to make them available.  However, in the
   general case, [7] suggests that HMAC-MD5 is adequate to the purpose
   at hand and has preferable performance characteristics.  [7] also
   offers source code and test vectors for this algorithm, a boon to
   those who would test for interoperability.  HMAC-MD5 is required as a
   baseline to be universally included in RSVP implementations providing
   cryptographic authentication, with other proposals optional (see
   Section 6 on Conformance Requirements).

   The RSVP checksum MAY be disabled (set to zero) when the INTEGRITY
   object is included in the message, as the message digest is a much
   stronger integrity check.

1.1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [8].

1.2.  Why not use the Standard IPSEC Authentication Header?

   One obvious question is why, since there exists a standard
   authentication mechanism, IPSEC [3,5], we would choose not to use it.
   This was discussed at length in the working group, and the use of
   IPSEC was rejected for the following reasons.



Baker, et al.               Standards Track