RSVP Cryptographic Authentication
RFC 2747

Document Type RFC - Proposed Standard (January 2000; Errata)
Updated by RFC 3097
Last updated 2015-03-26
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2747 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           F. Baker
Request for Comments: 2747                                         Cisco
Category: Standards Track                                     B. Lindell
                                                                 USC/ISI
                                                               M. Talwar
                                                               Microsoft
                                                            January 2000

                   RSVP Cryptographic Authentication

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document describes the format and use of RSVP's INTEGRITY object
   to provide hop-by-hop integrity and authentication of RSVP messages.

1.  Introduction

   The Resource ReSerVation Protocol RSVP [1] is a protocol for setting
   up distributed state in routers and hosts, and in particular for
   reserving resources to implement integrated service.  RSVP allows
   particular users to obtain preferential access to network resources,
   under the control of an admission control mechanism.  Permission to
   make a reservation will depend both upon the availability of the
   requested resources along the path of the data, and upon satisfaction
   of policy rules.

   To ensure the integrity of this admission control mechanism, RSVP
   requires the ability to protect its messages against corruption and
   spoofing.  This document defines a mechanism to protect RSVP message
   integrity hop-by-hop.  The proposed scheme transmits an
   authenticating digest of the message, computed using a secret
   Authentication Key and a keyed-hash algorithm.  This scheme provides
   protection against forgery or message modification.  The INTEGRITY
   object of each RSVP message is tagged with a one-time-use sequence

Baker, et al.               Standards Track                     [Page 1]
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
Show full document text