draft-ietf-rsvp-fix-iana-00.txt   rfc3097.txt 
Internet Engineering Task Force R. Braden Network Working Group R. Braden
INTERNET DRAFT ISI Request for Comments: 3097 ISI
File: draft-ietf-rsvp-fix-iana-00.txt L. Zhang Updates: 2747 L. Zhang
Updates: 2747 UCLA Category: Standards Track UCLA
EXPIRES: July 2001 January 2001 April 2001
RSVP Cryptographic Authentication --
New Message Type RSVP Cryptographic Authentication --
Updated Message Type Value
Status of this Memo Status of this Memo
This document is an Internet Draft ans is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC 2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Copyright Notice
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at Copyright (C) The Internet Society (2001). All Rights Reserved.
http://www.ietf.org/ietf/1id-abstracts.txt
Abstract Abstract
This memo resolves a duplication in the assignment of RSVP Message This memo resolves a duplication in the assignment of RSVP Message
Types, by changing the Message Types assigned by RFC 2747 to Types, by changing the Message Types assigned by RFC 2747 to
Challenge and Integrity Response messages. Challenge and Integrity Response messages.
1. Introduction 1. Introduction
RFC 2747 ("RSVP Cryptographic Authentication") [RFC 2747] assigns RFC 2747 ("RSVP Cryptographic Authentication") [RFC2747] assigns RSVP
RSVP Message Type 12 to an Integrity Response message, while RFC Message Type 12 to an Integrity Response message, while RFC 2961
xxxx ("RSVP Refresh Overhead Reduction Extensions") [RFCxxxx] ("RSVP Refresh Overhead Reduction Extensions") [RFC2961] assigns the
assigns the same value to a Bundle message. This memo resolves the same value to a Bundle message. This memo resolves the conflict over
conflict over RSVP Message Type 12 by assigning a different value to RSVP Message Type 12 by assigning a different value to the Message
the Message Type of the Integrity Response Message in RFC 2747. It Type of the Integrity Response Message in RFC 2747. It is believed
is believed that the protocol defined by RFC xxxx entered use in the that the protocol defined by RFC 2961 entered use in the field before
field before the RFC's publication and before the conflicting the RFC's publication and before the conflicting Message Type was
Message Type was noticed. and that it may be easier to install new noticed, and that it may be easier to install new software in
software in environments that have deployed the Integrity object environments that have deployed the Integrity object than in those
than in those that have deployed the refresh reduction extension. that have deployed the refresh reduction extension.
To simplify possible interoperability problems caused by this To simplify possible interoperability problems caused by this change,
change, we also assign a new value to the Message Type of RFC 2747's we also assign a new value to the Message Type of RFC 2747's
Challenge message, to which the Integrity Response message is a Challenge message, to which the Integrity Response message is a
reply. reply.
2. Modification 2. Modification
Message Types defined in the RSVP Integrity extension [RFC 2747] Message Types defined in the RSVP Integrity extension [RFC 2747]
shall be changed as follows: shall be changed as follows:
o Challenge message has Message Type zz. o Challenge message has Message Type 25.
o Integrity Response message has Message Type 25+1.
o Integrity Response message has Message Type zz+1.
[zz is TBD by the IANA; we suggest 25]
3. Compatibility 3. Compatibility
Two communicating nodes whose Integrity implementations are Two communicating nodes whose Integrity implementations are
conformant with this modification will interoperate, using Message conformant with this modification will interoperate, using Message
Type 12 for Bundle messages and Message Types zz, zz+1 for the Type 12 for Bundle messages and Message Types 25 and 26 for the
Integrity handshake. A non-conformant implementation of the Integrity handshake. A non-conformant implementation of the
Integrity extension will not interoperate with a conformant Integrity extension will not interoperate with a conformant
implementation (though two non-conformant implementations can implementation (though two non-conformant implementations can
interoperate as before). interoperate as before).
There is no possibility of an Integrity handshake succeeding There is no possibility of an Integrity handshake succeeding
accidentally due to this change, since both sides of the handshake accidentally due to this change, since both sides of the handshake
use the new numbers or the old numbers. Furthermore, the Integrity use the new numbers or the old numbers. Furthermore, the Integrity
Response message includes a 32-bit cookie that must match Response message includes a 32-bit cookie that must match a cookie in
a cookie in the Challenge message, else the challenge will fail. the Challenge message, else the challenge will fail. Finally, a
Finally, a non-conformant implementation should never receive a non-conformant implementation should never receive a Bundle message
Bundle message that it interprets as an Integrity Response message, that it interprets as an Integrity Response message, since RFC 2961
since RFC xxxx requires that Bundle messages be sent only to a requires that Bundle messages be sent only to a Bundle-capable node.
Bundle-capable node.
4. References 4. References
[RFC2747] Baker, F., Lindell, R., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, R. and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFCxxxx] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.
and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", and S. Molendini, "RSVP Refresh Overhead Reduction
RFCxxxx, January 2001. Extensions", RFC 2961, April 2001.
Security Considerations Security Considerations
No new security considerations are introduced beyond RFC2747 itself No new security considerations are introduced beyond RFC 2747 itself
and the compatibility issues above. and the compatibility issues above.
Authors' Addresses Authors' Addresses
Bob Braden Bob Braden
USC Information Sciences Institute USC Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Phone: (310) 822-1511 Phone: (310) 822-1511
EMail: Braden@ISI.EDU EMail: Braden@ISI.EDU
skipping to change at line 121 skipping to change at page 4, line 7
Lixia Zhang Lixia Zhang
UCLA Computer Science Department UCLA Computer Science Department
4531G Boelter Hall 4531G Boelter Hall
Los Angeles, CA 90095-1596 USA Los Angeles, CA 90095-1596 USA
Phone: 310-825-2695 Phone: 310-825-2695
EMail: lixia@cs.ucla.edu EMail: lixia@cs.ucla.edu
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns." 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.
 End of changes. 16 change blocks. 
57 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/