The RFC Archive
 The RFC Archive   RFC 3097   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 3097

RSVP Cryptographic Authentication -- Updated Message Type Value

Last modified on Friday, April 20th, 2001

Permanent link to RFC 3097
Search GitHub Wiki for RFC 3097
Show other RFCs mentioning RFC 3097







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


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 [RFC 2747] Baker, F., Lindell, R. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [RFC 2961] 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 top

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 top

RFC 3097 RSVP Cryptographic Authentication April 2001 Full Copyright Statement Copyright © 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 top

RSVP Cryptographic Authentication -- Updated Message Type Value RFC TOTAL SIZE: 6320 bytes PUBLICATION DATE: Friday, April 20th, 2001 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 3097: The IETF Trust, Friday, April 20th, 2001
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement