The IESG has approved the following Internet-Drafts as Proposed Standards:
o RSVP Diagnostic Messages <draft-ietf-rsvp-diagnostic-msgs-08.txt>
o RSVP Operation Over IP Tunnels <draft-ietf-rsvp-tunnel-04.txt>
o RSVP Cryptographic Authentication <draft-ietf-rsvp-md5-08.txt>
These documents are the product of the Resource Reservation Setup
Protocol Working Group. The IESG contact persons are Scott Bradner and
Vern Paxson.
Technical Summary
These three documents help fill out the RSVP protocol suite.
In the basic RSVP protocol [RSVP], error messages are the only means for
an end host to receive feedback regarding a failure in setting up either
path state or reservation state. An error message carries back only the
information from the failed point, without any information about the
state at other hops before or after the failure. In the absence of
failures, a host receives no feedback regarding the details of a reser-
vation that has been put in place, such as whether, or where, or how,
its own reservation request is being merged with that of others. Such
missing information can be highly desirable for debugging purposes, or
for network resource management in general.
The RSVP Diagnostic Messages document specifies the RSVP diagnostic
facility, which is designed to fill this information gap. The diagnostic
facility can be used to collect and report RSVP state information along
the path from a receiver to a specific sender. It uses Diagnostic
messages that are independent of other RSVP control messages and produce
no side-effects; that is, they do not change any RSVP state at either
nodes or hosts. Similarly, they provide not an error report but rather
a collection of requested RSVP state information.
IP-in-IP "tunnels" have become a widespread mechanism to transport
datagrams in the Internet. Typically, a tunnel is used to route
packets through portions of the network which do not directly
implement the desired service (e.g. IPv6), or to augment and modify
the behavior of the deployed routing architecture (e.g. multicast
routing, mobile IP, Virtual Private Net).
The RSVP Operation Over IP Tunnels document describes an approach for
providing RSVP protocol services over IP tunnels.
To ensure the integrity of this admission control mechanism, RSVP
requires the ability to protect its messages against corruption and
spoofing. The RSVP Cryptographic Authentication document defines a
mechanism to protect RSVP message integrity hop-by-hop. The 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
number. This allows the message receiver to identify playbacks and
hence to thwart replay attacks. The 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.
Working Group Summary
The working group supported publishing these documents and no issues were
raised during IETF last-call.
Protocol Quality
The documents were reviewed for the IESG by Scott Bradner.
Note to RFC Editor:
the "Changes" sections should be removed from
draft-ietf-rsvp-diagnostic-msgs-08.txt and
draft-ietf-rsvp-tunnel-04.txt