[要約] RFC 2385は、BGPセッションの保護を目的として、TCP MD5シグネチャオプションを使用する方法について説明しています。このRFCの目的は、BGPセッションの認証とデータの完全性を確保することです。
Network Working Group A. Heffernan
Request for Comments: 2385 cisco Systems
Category: Standards Track August 1998
Protection of BGP Sessions via the TCP MD5 Signature Option
TCP MD5署名オプションによるBGPセッションの保護
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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
IESG Note
IESG Note
This document describes currrent existing practice for securing BGP against certain simple attacks. It is understood to have security weaknesses against concerted attacks.
このドキュメントでは、特定の単純な攻撃からBGPを保護するための現在の慣行について説明します。協調攻撃に対してセキュリティ上の弱点があると理解されています。
Abstract
概要
This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in a TCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points. Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP.
このメモは、BGPのセキュリティを強化するためのTCP拡張について説明しています。これは、TCPセグメントでMD5 [RFC1321]ダイジェストを伝送するための新しいTCPオプションを定義します。このダイジェストは、そのセグメントの署名のように機能し、接続のエンドポイントだけが知っている情報を組み込みます。 BGPはトランスポートとしてTCPを使用するため、このホワイトペーパーで説明する方法でこのオプションを使用すると、BGPに対する特定のセキュリティ攻撃による危険が大幅に軽減されます。
The primary motivation for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. Of particular concern are TCP resets.
このオプションの主な動機は、接続ストリームへのスプーフィングされたTCPセグメントの導入からBGPを保護できるようにすることです。特に懸念されるのは、TCPリセットです。
To spoof a connection using the scheme described in this paper, an attacker would not only have to guess TCP sequence numbers, but would also have had to obtain the password included in the MD5 digest. This password never appears in the connection stream, and the actual form of the password is up to the application. It could even change during the lifetime of a particular connection so long as this change was synchronized on both ends (although retransmission can become problematical in some TCP implementations with changing passwords).
このペーパーで説明されているスキームを使用して接続を偽装するには、攻撃者はTCPシーケンス番号を推測する必要があるだけでなく、MD5ダイジェストに含まれているパスワードも入手する必要があります。このパスワードは接続ストリームに表示されることはなく、実際のパスワードの形式はアプリケーション次第です。この変更が両端で同期されている限り、特定の接続の存続期間中に変更することもできます（ただし、パスワードの変更を伴う一部のTCP実装では、再送信が問題になる可能性があります）。
Finally, there is no negotiation for the use of this option in a connection, rather it is purely a matter of site policy whether or not its connections use the option.
最後に、接続でこのオプションを使用するためのネゴシエーションはありません。接続がこのオプションを使用するかどうかは、サイトポリシーの問題です。
Every segment sent on a TCP connection to be protected against spoofing will contain the 16-byte MD5 digest produced by applying the MD5 algorithm to these items in the following order:
スプーフィングから保護するためにTCP接続で送信されるすべてのセグメントには、MD5アルゴリズムをこれらのアイテムに次の順序で適用することによって生成される16バイトのMD5ダイジェストが含まれます。
1. the TCP pseudo-header (in the order: source IP address, destination IP address, zero-padded protocol number, and segment length) 2. the TCP header, excluding options, and assuming a checksum of zero 3. the TCP segment data (if any) 4. an independently-specified key or password, known to both TCPs and presumably connection-specific
1. TCP疑似ヘッダー（順序：送信元IPアドレス、宛先IPアドレス、ゼロが埋め込まれたプロトコル番号、セグメント長）2. TCPヘッダー、オプションを除外し、チェックサムをゼロと想定3. TCPセグメントデータ（存在する場合）4.独立して指定されたキーまたはパスワード。TCPと既知の接続固有の両方で認識されています。
The header and pseudo-header are in network byte order. The nature of the key is deliberately left unspecified, but it must be known by both ends of the connection. A particular TCP implementation will determine what the application may specify as the key.
ヘッダーと疑似ヘッダーは、ネットワークバイトオーダーです。キーの性質は意図的に指定されていませんが、接続の両端で認識されている必要があります。特定のTCP実装は、アプリケーションがキーとして指定できるものを決定します。
Upon receiving a signed segment, the receiver must validate it by calculating its own digest from the same data (using its own key) and comparing the two digest. A failing comparison must result in the segment being dropped and must not produce any response back to the sender. Logging the failure is probably advisable.
受信者は、署名されたセグメントを受信すると、同じデータから独自のダイジェストを計算し（独自のキーを使用して）、2つのダイジェストを比較することにより、それを検証する必要があります。比較に失敗すると、セグメントが削除され、送信者に応答が返されないようにする必要があります。失敗をログに記録することをお勧めします。
Unlike other TCP extensions (e.g., the Window Scale option [RFC1323]), the absence of the option in the SYN,ACK segment must not cause the sender to disable its sending of signatures. This negotiation is typically done to prevent some TCP implementations from misbehaving upon receiving options in non-SYN segments. This is not a problem for this option, since the SYN,ACK sent during connection negotiation will not be signed and will thus be ignored. The connection will never be made, and non-SYN segments with options will never be sent. More importantly, the sending of signatures must be under the complete control of the application, not at the mercy of the remote host not understanding the option.
他のTCP拡張機能（ウィンドウスケールオプション[RFC1323]など）とは異なり、SYN、ACKセグメントにオプションがないため、送信者が署名の送信を無効にしてはなりません。このネゴシエーションは、通常、一部のTCP実装が非SYNセグメントのオプションを受信したときに誤動作するのを防ぐために行われます。接続ネゴシエーション中に送信されたSYN、ACKは署名されないので無視されるため、これはこのオプションの問題ではありません。接続は行われず、オプションのある非SYNセグメントは送信されません。さらに重要なことは、署名の送信は、オプションを理解していないリモートホストのなすがままではなく、アプリケーションの完全な制御下にある必要があります。
The proposed option has the following format:
提案されたオプションの形式は次のとおりです。
+---------+---------+-------------------+
| Kind=19 |Length=18| MD5 digest... |
+---------+---------+-------------------+
| |
+---------------------------------------+
| |
+---------------------------------------+
| |
+-------------------+-------------------+
| |
+-------------------+
The MD5 digest is always 16 bytes in length, and the option would appear in every segment of a connection.
MD5ダイジェストの長さは常に16バイトであり、オプションは接続のすべてのセグメントに表示されます。
A connectionless reset will be ignored by the receiver of the reset, since the originator of that reset does not know the key, and so cannot generate the proper signature for the segment. This means, for example, that connection attempts by a TCP which is generating signatures to a port with no listener will time out instead of being refused. Similarly, resets generated by a TCP in response to segments sent on a stale connection will also be ignored. Operationally this can be a problem since resets help BGP recover quickly from peer crashes.
コネクションレスリセットはリセットの受信者によって無視されます。リセットの発信者はキーを認識していないため、セグメントに適切な署名を生成できないためです。これは、たとえば、リスナーのないポートへのシグネチャを生成しているTCPによる接続試行は、拒否される代わりにタイムアウトになることを意味します。同様に、古い接続で送信されたセグメントに応答してTCPによって生成されたリセットも無視されます。リセットはピアのクラッシュからBGPを迅速に回復するのに役立つため、運用上これは問題になる可能性があります。
The performance hit in calculating digests may inhibit the use of this option. Some measurements of a sample implementation showed that on a 100 MHz R4600, generating a signature for simple ACK segment took an average of 0.0268 ms, while generating a signature for a data segment carrying 4096 bytes of data took 0.8776 ms on average. These times would be applied to both the input and output paths, with the input path also bearing the cost of a 16-byte compare.
ダイジェストの計算におけるパフォーマンスヒットにより、このオプションの使用が妨げられる場合があります。サンプル実装のいくつかの測定は、100 MHz R4600で、単純なACKセグメントの署名の生成に平均0.0268ミリ秒かかり、4096バイトのデータを運ぶデータセグメントの署名の生成に平均0.8776ミリ秒かかることを示しました。これらの時間は入力パスと出力パスの両方に適用され、入力パスも16バイト比較のコストを負担します。
As with other options that are added to every segment, the size of the MD5 option must be factored into the MSS offered to the other side during connection negotiation. Specifically, the size of the header to subtract from the MTU (whether it is the MTU of the outgoing interface or IP's minimal MTU of 576 bytes) is now at least 18 bytes larger.
すべてのセグメントに追加される他のオプションと同様に、MD5オプションのサイズは、接続ネゴシエーション中に相手側に提供されるMSSに考慮される必要があります。具体的には、MTUから差し引くヘッダーのサイズ（発信インターフェイスのMTUであるか、IPの最小MTUである576バイトであるか）は、少なくとも18バイト大きくなっています。
The total header size is also an issue. The TCP header specifies where segment data starts with a 4-bit field which gives the total size of the header (including options) in 32-byte words. This means that the total size of the header plus option must be less than or equal to 60 bytes -- this leaves 40 bytes for options.
合計ヘッダーサイズも問題です。 TCPヘッダーは、セグメントデータが4バイトフィールドで始まる場所を指定します。これは、ヘッダー（オプションを含む）の合計サイズを32バイトのワードで示します。これは、ヘッダーとオプションの合計サイズが60バイト以下でなければならないことを意味します。これにより、オプション用に40バイトが残ります。
As a concrete example, 4.4BSD defaults to sending window-scaling and timestamp information for connections it initiates. The most loaded segment will be the initial SYN packet to start the connection. With MD5 signatures, the SYN packet will contain the following:
具体的な例として、4.4BSDはデフォルトで、開始する接続のウィンドウスケーリングとタイムスタンプ情報を送信します。最もロードされたセグメントは、接続を開始するための最初のSYNパケットです。 MD5シグネチャを使用すると、SYNパケットには次のものが含まれます。
-- 4 bytes MSS option
-- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD)
-- 12 bytes for timestamp (4.4BSD pads the option as recommended
in RFC 1323 Appendix A)
-- 18 bytes for MD5 digest
-- 2 bytes for end-of-option-list, to pad to a 32-bit boundary.
This sums to 40 bytes, which just makes it.
これは合計で40バイトになり、単純にそれだけになります。
Since this memo was first issued (under a different title), the MD5 algorithm has been found to be vulnerable to collision search attacks [Dobb], and is considered by some to be insufficiently strong for this type of application.
このメモが最初に発行されて（別のタイトルで）以来、MD5アルゴリズムは衝突検索攻撃に対して脆弱であることが判明しており[Dobb]、このタイプのアプリケーションには強度が不十分であると考える人もいます。
This memo still specifies the MD5 algorithm, however, since the option has already been deployed operationally, and there was no "algorithm type" field defined to allow an upgrade using the same option number. The original document did not specify a type field since this would require at least one more byte, and it was felt at the time that taking 19 bytes for the complete option (which would probably be padded to 20 bytes in TCP implementations) would be too much of a waste of the already limited option space.
ただし、このメモはMD5アルゴリズムを指定していますが、オプションはすでに運用上に展開されており、同じオプション番号を使用してアップグレードできるように定義された「アルゴリズムタイプ」フィールドがありませんでした。元のドキュメントではタイプフィールドが指定されていなかったため、少なくとも1バイトが必要であり、完全なオプションに19バイトを使用する（TCP実装ではおそらく20バイトにパディングされる）ことも考えられました。すでに限られたオプションスペースの無駄の多く。
This does not prevent the deployment of another similar option which uses another hashing algorithm (like SHA-1). Also, if most implementations pad the 18 byte option as defined to 20 bytes anyway, it would be just as well to define a new option which contains an algorithm type field.
これは、別のハッシュアルゴリズム（SHA-1など）を使用する別の同様のオプションの展開を妨げません。また、ほとんどの実装が18バイトのオプションを20バイトに定義されているように埋め込んでいる場合は、アルゴリズムタイプフィールドを含む新しいオプションを定義するのも同様です。
This would need to be addressed in another document, however.
ただし、これは別のドキュメントで対処する必要があります。
It should be noted that the key configuration mechanism of routers may restrict the possible keys that may be used between peers. It is strongly recommended that an implementation be able to support at minimum a key composed of a string of printable ASCII of 80 bytes or less, as this is current practice.
ルーターのキー構成メカニズムは、ピア間で使用される可能性のあるキーを制限する場合があることに注意してください。これは現在の慣行であるため、実装では、80バイト以下の印刷可能なASCIIの文字列で構成されるキーをサポートできることが強く推奨されます。
This document defines a weak but currently practiced security mechanism for BGP. It is anticipated that future work will provide different stronger mechanisms for dealing with these issues.
このドキュメントは、BGPの弱いが現在実践されているセキュリティメカニズムを定義しています。今後の作業では、これらの問題に対処するためのさまざまな強力なメカニズムが提供されることが予想されます。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のTCP拡張機能」、RFC 1323、1992年5月。
[Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack", RSA
Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
http://www.rsa.com/rsalabs/pubs/cryptobytes.html
Author's Address
著者のアドレス
Andy Heffernan cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Andy Heffernan cisco Systems 170 West Tasman Drive San Jose、CA 95134 USA
Phone: +1 408 526-8115
EMail: ahh@cisco.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。