    Network Working Group                                          R. Braden
    Request for Comments: 3097                                           ISI
    Updates: 2747                                                   L. Zhang
    Category: Standards Track                                           UCLA
                                                                  April 2001

                      RSVP Cryptographic Authentication --
                           Updated Message Type Value

    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 (2001).  All Rights Reserved.

    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") [RFC2747] assigns RSVP
       Message Type 12 to an Integrity Response message, while RFC 2961
       ("RSVP Refresh Overhead Reduction Extensions") [RFC2961] 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 2961 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.

    Braden & Zhang              Standards Track                     [Page 1]

    RFC 3097           RSVP Cryptographic Authentication          April 2001

    2. Modification

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

          o Challenge message has Message Type 25.
          o Integrity Response message has Message Type 25+1.

    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 25 and 26 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 2961
       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.

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

    Security Considerations

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

    Braden & Zhang              Standards Track                     [Page 2]

    RFC 3097           RSVP Cryptographic Authentication          April 2001

    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

    Braden & Zhang              Standards Track                     [Page 3]

    RFC 3097           RSVP Cryptographic Authentication          April 2001

    Full Copyright Statement

       Copyright (C) The Internet Society (2001).  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.

       This document and the information contained herein is provided on an
       "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
       TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
       BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
       HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
       MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    Braden & Zhang              Standards Track                     [Page 4]