Protocol Action: RSVP Diagnostic Messages to Proposed Standard

[The IESG <[e-mail]>]

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