Network Working Group                                          R. Braden
Request for Comments: 3097                                           ISI
Updates: 2747                                                   L. Zhang
Category: Standards Track                                           UCLA
                                                              April 2001
        
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

RSVP加密身份验证--更新的消息类型值

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.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2001). All Rights Reserved.

版权所有(C)互联网协会(2001年)。版权所有。

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.

本备忘录通过将RFC 2747分配的消息类型更改为质询和完整性响应消息,解决了RSVP消息类型分配中的重复问题。

1. Introduction
1. 介绍

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.

RFC 2747(“RSVP加密身份验证”)[RFC2747]将RSVP消息类型12分配给完整性响应消息,而RFC 2961(“RSVP刷新开销减少扩展”)[RFC2961]将相同的值分配给捆绑消息。此备忘录通过为RFC 2747中完整性响应消息的消息类型指定不同的值,解决了RSVP消息类型12的冲突。据信,RFC 2961定义的协议在RFC发布之前和注意到冲突消息类型之前进入现场使用,并且在部署Integrity对象的环境中安装新软件可能比在部署refresh Reduce 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.

为了简化此更改可能导致的互操作性问题,我们还为RFC 2747的质询消息的消息类型分配了一个新值,完整性响应消息就是对该消息的回复。

2. Modification
2. 修改

Message Types defined in the RSVP Integrity extension [RFC 2747] shall be changed as follows:

RSVP完整性扩展[RFC 2747]中定义的消息类型应更改如下:

o Challenge message has Message Type 25. o Integrity Response message has Message Type 25+1.

o 质询消息的消息类型为25。o完整性响应消息的消息类型为25+1。

3. Compatibility
3. 兼容性

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).

完整性实现符合此修改的两个通信节点将进行互操作,将消息类型12用于捆绑消息,将消息类型25和26用于完整性握手。完整性扩展的非一致性实现不会与一致性实现互操作(尽管两个非一致性实现可以像以前一样互操作)。

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.

由于此更改,不存在完整性握手意外成功的可能性,因为握手双方都使用新号码或旧号码。此外,完整性响应消息包含一个32位cookie,该cookie必须与质询消息中的cookie匹配,否则质询将失败。最后,非一致性实现永远不应该接收它解释为完整性响应消息的捆绑包消息,因为RFC 2961要求捆绑包消息只发送到支持捆绑包的节点。

4. References
4. 工具书类

[RFC2747] Baker, F., Lindell, R. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.

[RFC2747]Baker,F.,Lindell,R.和M.Talwar,“RSVP加密认证”,RFC 2747,2000年1月。

[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.

[RFC2961]Berger,L.,Gan,D.,Swallow,G.,Pan,P.,Tommasi,F.和S.Molendini,“RSVP刷新开销减少扩展”,RFC 29612001年4月。

Security Considerations

安全考虑

No new security considerations are introduced beyond RFC 2747 itself and the compatibility issues above.

除了RFC 2747本身和上述兼容性问题之外,没有引入新的安全注意事项。

Authors' Addresses

作者地址

Bob Braden USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292

鲍勃·布拉登南加州信息科学研究所,地址:加利福尼亚州马里纳·德雷市金钟路4676号,邮编:90292

Phone: (310) 822-1511 EMail: Braden@ISI.EDU

电话:(310)822-1511电子邮件:Braden@ISI.EDU

Lixia Zhang UCLA Computer Science Department 4531G Boelter Hall Los Angeles, CA 90095-1596 USA

加州大学洛杉矶分校计算机科学系4531G Boelter Hall洛杉矶,加利福尼亚90095-1596

Phone: 310-825-2695 EMail: lixia@cs.ucla.edu

电话:310-825-2695电子邮件:lixia@cs.ucla.edu

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2001). All Rights Reserved.

版权所有(C)互联网协会(2001年)。版权所有。

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.

RFC编辑功能的资金目前由互联网协会提供。