Movatterモバイル変換

Network Working Group                                          R. BradenRequest for Comments: 3097                                           ISIUpdates:2747                                                   L. ZhangCategory: Standards Track                                           UCLA                                                              April 2001RSVP Cryptographic Authentication --Updated Message Type ValueStatus 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 byRFC 2747 to   Challenge and Integrity Response messages.1. IntroductionRFC 2747 ("RSVP Cryptographic Authentication") [RFC2747] assigns RSVP   Message Type 12 to an Integrity Response message, whileRFC 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 inRFC 2747.  It is believed   that the protocol defined byRFC 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 ofRFC 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 20012. 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, sinceRFC 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 beyondRFC 2747 itself   and the compatibility issues above.Braden & Zhang              Standards Track                     [Page 2]

RFC 3097           RSVP Cryptographic Authentication          April 2001Authors' 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.eduBraden & Zhang              Standards Track                     [Page 3]

RFC 3097           RSVP Cryptographic Authentication          April 2001Full 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]