GENWiki

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]