1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc3097.txt b/doc/rfc/rfc3097.txt
new file mode 100644
index 0000000..9390fc3
--- /dev/null
+++ b/doc/rfc/rfc3097.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+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]
+