[要約] RFC 3097は、RSVP(Resource Reservation Protocol)の暗号認証に関する更新されたメッセージタイプ値についての規格です。このRFCの目的は、RSVPメッセージの認証を強化し、セキュリティを向上させることです。

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.

Copyright(C)The Internet Society(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のIntegrity Responseメッセージのメッセージタイプに異なる値を割り当てることにより、RSVPメッセージタイプ12の競合を解決します。RFC2961で定義されたプロトコルは、RFCの公開前および競合するメッセージタイプが確認され、Integrityオブジェクトを展開した環境では、リフレッシュ削減拡張機能を展開した環境よりも新しいソフトウェアをインストールする方が簡単な場合があります。

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 Integrity拡張[RFC 2747]で定義されているメッセージタイプは、次のように変更されます。

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

o チャレンジメッセージのメッセージタイプは25です。o Integrity Responseメッセージのメッセージタイプは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).

Integrityの実装がこの変更に準拠している2つの通信ノードは、バンドルメッセージにはメッセージタイプ12を、Integrityハンドシェイクにはメッセージタイプ25および26を使用して相互運用します。 Integrity拡張機能の非準拠実装は、準拠実装と相互運用しません(ただし、2つの非準拠実装は以前と同様に相互運用できます)。

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.

ハンドシェイクの両側で新しい番号または古い番号が使用されるため、この変更により、Integrityハンドシェイクが誤って成功する可能性はありません。さらに、Integrity Responseメッセージには、チャレンジメッセージのCookieと一致する必要がある32ビットCookieが含まれています。それ以外の場合、チャレンジは失敗します。最後に、RFC 2961ではBundleメッセージをBundle対応ノードにのみ送信する必要があるため、非準拠の実装は、Integrity Responseメッセージとして解釈するBundleメッセージを受信して​​はなりません。

4. References
4. 参考文献

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

[RFC2747]ベイカー、F。、リンデル、R。およびM.タルワー、「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 2961、2001年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

ボブブレーデンUSC情報科学研究所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

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

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.

Copyright(C)The Internet Society(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 Editor機能への資金提供は、現在Internet Societyから提供されています。