One document matched: draft-ietf-rsvp-fix-iana-00.txt-5479.txt

Internet Engineering Task Force                              R. Braden
INTERNET DRAFT                                                     ISI
File: draft-ietf-rsvp-fix-iana-00.txt                         L. Zhang
Updates: 2747                                                     UCLA
EXPIRES: July 2001                                        January 2001


                RSVP Cryptographic Authentication --

		         New Message Type


Status of this Memo

   This document is an Internet Draft ans is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

Abstract

   This memo resolves a duplication in the assignment of RSVP Message
   Types, by changing the Message Types assigned by RFC 2747 to
   Challenge and Integrity Response messages.


1. Introduction

   RFC 2747 ("RSVP Cryptographic Authentication") [RFC 2747] assigns
   RSVP Message Type 12 to an Integrity Response message, while RFC
   xxxx ("RSVP Refresh Overhead Reduction Extensions") [RFCxxxx]
   assigns the same value to a Bundle message.  This memo resolves the
   conflict over RSVP Message Type 12 by assigning a different value to
   the Message Type of the Integrity Response Message in RFC 2747.  It
   is believed that the protocol defined by RFC xxxx entered use in the
   field before the RFC's publication and before the conflicting
   Message Type was noticed. and that it may be easier to install new
   software in environments that have deployed the Integrity object
   than in those that have deployed the refresh reduction extension.

   To simplify possible interoperability problems caused by this
   change, we also assign a new value to the Message Type of RFC 2747's
   Challenge message, to which the Integrity Response message is a
   reply.

2. Modification

   Message Types defined in the RSVP Integrity extension [RFC 2747]
   shall be changed as follows:

	o Challenge message has Message Type zz.

        o Integrity Response message has Message Type zz+1.

   [zz is TBD by the IANA; we suggest 25]


3. Compatibility

   Two communicating nodes whose Integrity implementations are
   conformant with this modification will interoperate, using Message
   Type 12 for Bundle messages and Message Types zz, zz+1 for the
   Integrity handshake.  A non-conformant implementation of the
   Integrity extension will not interoperate with a conformant
   implementation (though two non-conformant implementations can
   interoperate as before).

   There is no possibility of an Integrity handshake succeeding
   accidentally due to this change, since both sides of the handshake
   use the new numbers or the old numbers.  Furthermore, the Integrity
   Response message includes a 32-bit cookie that must match
   a cookie in the Challenge message, else the challenge will fail.
   Finally, a non-conformant implementation should never receive a
   Bundle message that it interprets as an Integrity Response message,
   since RFC xxxx requires that Bundle messages be sent only to a
   Bundle-capable node.

4. References

   [RFC2747]  Baker, F., Lindell, R., and M. Talwar, "RSVP Cryptographic
        Authentication", RFC 2747, January 2000.

   [RFCxxxx]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
	and S. Molendini, "RSVP Refresh Overhead Reduction Extensions",
	RFCxxxx, January 2001.

Security Considerations

    No new security considerations are introduced beyond RFC2747 itself
    and the compatibility issues above.

Authors' Addresses

   Bob Braden
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: (310) 822-1511
   EMail: Braden@ISI.EDU

   Lixia Zhang
   UCLA Computer Science Department
   4531G Boelter Hall
   Los Angeles, CA 90095-1596 USA

   Phone: 310-825-2695
   EMail: lixia@cs.ucla.edu


Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns."