Network Working Group T. Przygienda
Request for Comments: 3358 Xebeo
Category: Informational August 2002
Optional Checksums in
Intermediate System to Intermediate System (ISIS)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document describes an optional extension to the Intermediate System to Intermediate System (ISIS) protocol, used today by several Internet Service Proviers (ISPs) for routing within their clouds. ISIS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as Interior Gateway Protocol (IGP). ISIS originally does not provide Complete Sequence Numbers Protocol Data (CSNP) and Partial Sequence Numbers Protocol Data Unit (PSNP) checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protocol shows that this precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a new optional Type, Length and Value (TLV) providing checksums.
この文書は、その雲の中にルーティングするために、いくつかのインターネットサービスProviers（のISP）によって現在使用されている中間システム（ISIS）プロトコルへの中間システムにオプションの拡張について説明します。 ISISは、内部ゲートウェイルーティングプロトコルOSIによって元々開発されインテリアゲートウェイプロトコル（IGP）としてIP拡張機能と共に使用されます。 ISISは、元々提供された情報の完全性を検証するために下にある層に頼って、完全なシーケンス番号プロトコルデータ（CSNP）と部分シーケンス番号プロトコルデータユニット（PSNP）チェックサムを提供していません。プロトコルでの経験は、この前提条件が常に保持していないとのシナリオは、そのインパクトプロトコル機能を想像できることを示しています。この文書では、チェックサムを提供する新しいオプションの種類、長さ、および値（TLV）を紹介します。
ISIS [ISO90, Cal90a, Cal90b] CSNPs and PSNPs and IIHs can be corrupted in case of faulty implementations of L2 hardware or lack of checksuming on a specific network technology. As a particularly ugly case, corruption of length and/or TLV length fields may lead to the generation of extensive numbers of "empty" LSPs in the receiving node. Since we cannot rely on authentication as a checksum mechanism, this document proposes an optional TLV to add checksums to the elements.
ISIS [ISO90、Cal90a、Cal90b]のcSNPとPSNPsとIIHSは、L2ハードウェアまたは特定のネットワーク技術にchecksumingの欠如の不完全な実装の場合に破損することができます。特に醜いケースとして、長さ及び/又はTLVの長さフィールドの破損は、受信ノードにおける「空」LSPの大規模な数の発生につながる可能性があります。私たちは、チェックサムメカニズムとして認証に頼ることはできませんので、このドキュメントでは、要素にチェックサムを追加するには、オプションのTLVを提案しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [Bra97].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります【Bra97]に記載されているように解釈されます。
This optional TLV MAY BE included in all CSNP, PSNP and IIH packets and an implementation that implements optional checksums MUST accept PDUs if they do NOT contain the optional checksum. Implementations that receive an optional checksum TLV and support it MUST discard the PDU if the checksum is incorrect. An implementation that does NOT implement optional checksums MUST accept a PDU that contains the checksum TLV. An implementation that supports optional checksums and receives it within any other PDU than CSNP, PSNP or IIH MUST discard the PDU. Such an implementation MUST discard the PDU as well if more than one optional checksum TLVs are included within it. Additionally, any implementation supporting optional checksums MUST accept PDUs with an optional checksum with the value 0 and consider such a checksum as correct.
このオプションのTLVはすべてCSNP、PSNPとIIHパケットに含ませることができると、彼らは、オプションのチェックサムが含まれていない場合は、オプションのチェックサムを実装して実装はPDUを受け入れなければなりません。オプションのチェックサムTLVを受け取り、チェックサムが正しくない場合、それはPDUを捨てなければなりませんサポートする実装。オプションのチェックサムを実装していない実装では、チェックサムTLVが含まれているPDUを受け入れなければなりません。オプションのチェックサムをサポートし、CSNP、PSNP又はIIH以外のPDU内にそれを受信する実装はPDUを破棄しなければなりません。そのような実装は、複数のオプションのチェックサムのTLVは、その中に含まれている場合も同様にPDUを破棄しなければなりません。さらに、オプションのチェックサムをサポートしている実装では、値0と任意のチェックサムを持つPDUを受け入れ、そのようなチェックサムが正しいとして考慮しなければなりません。
The checksum is a fletcher checksum computed according to [ISO98], Annex C over the complete PDU. To compute the correct checksum, an implementation MUST add the optional checksum TLV to the PDU with the initial checksum value of 0 and compute the checksum over such a PDU.
チェックサムは[ISO98]、完全なPDU上附属書Cに従って計算フレッチャーチェックサムです。正しいチェックサムを計算するために、実装は0の初期チェックサム値とPDUにオプションのチェックサムTLVを追加し、そのようなPDUにわたってチェックサムを計算しなければなりません。
The implementation MUST either omit the optional checksum on an interface or send a 0 checksum value if it includes in the PDU signatures that provide equivalent or stronger functionality, such as HMAC or MD5. Otherwise an implementation that handles such signatures but does not handle the optional checksums, may fail to compute the MD5 signature on the packet. Such a failure would be caused by the fact that MD5 is computed with the checksum value set to 0 and only as a final step is the checksum value being filled in.
実装は、インターフェイス上で任意のチェックサムを省略するか、そのようなHMACまたはMD5と同等またはより強力な機能を提供するPDU署名に含まれている場合0チェックサム値を送信する必要があります。そうでなければそのような署名を処理するが、任意のチェックサムを処理しない実装では、パケット上のMD5署名を計算するのに失敗することがあります。このような障害は、MD5が0にのみ最後のステップは、内に充填されているチェックサム値であるとして設定されたチェックサム値が計算されるという事実に起因します。
[Prz01] lists the according value of the TLV type and discusses issues surrounding the assignment of new TLV codepoints.
【Prz01] TLVタイプの応じた値をリストし、新しいTLVコードポイントの割り当てを取り巻く問題について説明します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type =12 | TLV Length =2 | Checksum (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tony Li mentioned the original problem. Mike Shand provided comments. Somehow related problems with purging on LSP checksum errors have been observed by others before. Nischal Sheth spelled out the issues of interaction between MD5 and the optional checksums.
トニー・リーは、元の問題に言及しました。マイクシャンドは、コメントを提供しました。 LSPチェックサムエラーにパージするとどういうわけか、関連する問題は、前に他の人が観察されています。 Nischal ShethはMD5とオプションのチェックサムの間の相互作用の問題をスペルアウト。
ISIS security applies to the work presented. No specific security issues as to the new element are known.
ISISのセキュリティは提示の仕事に適用されます。新しい要素についての具体的なセキュリティ上の問題が知られていません。
References
リファレンス
[Bra97] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[Cal90a] Callon, R., "OSI ISIS Intradomain Routing Protocol", RFC 1142, February 1990.
[Cal90a] Callon、R.、 "OSI ISISイントラドメインルーティングプロトコル"、RFC 1142、1990年2月。
[Cal90b] Callon, R., "Use of OSI ISIS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990.
[Cal90b] Callon、R.、RFC 1195、1990年12月、 "TCP / IPおよびデュアル環境におけるルーティングのためのOSI ISISの使用"。
[ISO90] ISO. Information Technology - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO, 1990.
[ISO90] ISO。情報技術 - 電気通信及びシステム間情報交換 - コネクションレスモードのネットワークサービスを提供するためのプロトコルと組み合わせて使用する中間システムルーティング交換プロトコルへの中間システム。 ISO 1990。
[ISO98] ISO. Information Technology - Protocol for Providing the Connectionless-Mode Network Service: Protocol Specification. ISO, 1998.
[ISO98] ISO。情報技術 - コネクションレスモードのネットワークサービスを提供するためのプロトコル：プロトコル仕様。 ISO 1998。
[Prz01] Przygienda, T., "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System", RFC 3359, August 2002.
[Prz01] Przygienda、T.、 "予約の種類、長さと中間システムへの中間システムでの値（TLV）コードポイント"、RFC 3359、2002年8月。
Author's Address
著者のアドレス
Tony Przygienda Xebeo One Cragwood Road South Plainfield, NJ 07080
トニーPrzygienda Xebeo一つCragwoodロードサウスプレインフィールド、NJ 07080
Phone: (908) 222 4225 Email: prz@xebeo.com
電話：（908）222 4225 Eメール：prz@xebeo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。