RFC2385 日本語訳
2385 Protection of BGP Sessions via the TCP MD5 Signature Option. A.Heffernan. August 1998. (Format: TXT=12315 bytes) (Status: PROPOSED STANDARD)
RFC一覧
英語原文
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.
この文書は、Internet community のための Internet standards track
protocol を明細に記述し、改良のための討議と提案を要求する。このプロ
トコルの標準化状態とステータスについては、"Internet Official
Protocol Standards" (STD 1) の最新版を参照してもらいたい。このメモの
配布は、無制限である。
-----------------------------------------------------------------------
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
-----------------------------------------------------------------------
IESG Note
IESG メモ
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 上の確
実なセキュリティ攻撃から危険を減らす。
-----------------------------------------------------------------------
1.0 Introduction
1.0 序論
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.
最終的に、コネクションでこのオプション使用のための取り決めは、ない。
もっと正確に言えば、そのコネクションがこのオプションを使用するかどう
かは、純粋にサイトポリシーの問題である。
-----------------------------------------------------------------------
2.0 Proposal
2.0 提案
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 コネクション上で、送信され
るすべてのセグメントは、16-byte MD5 ダイジェストを含む。この MD5 ダ
イジェストは、次に述べる順序でそれらアイテムに MD5 アルゴリズムを適
用することにより生成される :
1. the TCP pseudo-header (in the order: source IP address,
destination IP address, zero-padded protocol number, and
segment length)
TCP 疑似ヘッダ (順序: 始点 IP アドレス、終点 IP アドレス、
zero がパッドされたプロトコル番号とセグメント長)
2. the TCP header, excluding options, and assuming a checksum of
zero
オプションと zero のチェックサム想定を除いた、TCP ヘッダ
3. the TCP segment data (if any)
(もしあるなら) TCP セグメントデータ
4. an independently-specified key or password, known to both TCPs
and presumably connection-specific
TCP(s) 両方とたぶんコネクション特有で知られた、非依存の特有な
鍵もしくはパスワード
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 拡張 (たとえば、Window Scale オプション [RFC1323]) と違って
SYN,ACK セグメント中にこのオプションの欠如は、送信側に署名送信を不可
能にさせない。この取り決めは、non-SYN セグメント内のオプション受信の
上でいくつかの TCP 実装が不正処理するのを防ぐため、一般的におこなわ
れる。このことは、このオプションについて問題ではない。それは、コネク
ション取り決めの間に送信された SYN,ACK は署名されなく、したがい無視
されるからである。コネクションは決して張られなく、オプションを持つ
non-SYN セグメントは決して送信されない。より重要に、署名 (したもの)
を送信することは、オプションを理解しないリモートホストのなすがままで
なく、完全なアプリケーション制御のもとでなければならない。
-----------------------------------------------------------------------
3.0 Syntax
3.0 構文
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 bytes 長である。そしてこのオプションは、
コネクション上の全セグメントに現れる。
-----------------------------------------------------------------------
4.0 Some Implications
4.0 いくつかの影響
4.1 Connectionless Resets
4.1 コネクションレスリセット
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.
コネクションレスリセットは、そのリセットを受け取った受信側により無視
される。そのリセットの originator (生成者) は、鍵を知らなく、セグメ
ントに対して適切な署名を生成できないからである。これは、次のことを意
味する。それは、たとえばリスナーのいない port へと署名を生成している
TCP によるコネクション試みは、拒否される代わりにタイムアウトするとい
うことである。同様に、古いコネクションで送信されたセグメントへのレス
ポンスに対し TCP により生成されるリセットも、無視される。(ただし) 運
用上、これは問題でありうる。(なぜなら) BGP のピアクラッシュから、リ
セットは (ピアの) すばやい回復を助けるからである。
4.2 Performance
4.2 パフォーマンス
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.
ダイジェスト計算で影響するパフォーマンスは、このオプション使用を抑制
するかもしれない。単純な ACK セグメントに署名を生成するという、100
MHz R4600 上で示されたサンプル実装のある測定では、平均 0.0268 ms か
かった。4096 bytes データを運ぶデータセグメントに署名を生成するのに
平均 0.8776 ms かかったけれども。これら時間は、入力/出力パス両方に適
用した。(ただし) 入力パスには、16-byte 比較のコストも与えた。
4.3 TCP Header Size
4.3 TCP ヘッダサイズ
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 であろうと
IP の最小 MTU 576 bytes であろうと) MTU から引くヘッダサイズは、少な
くとも 18 bytes より現在大きい。
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 ヘッダは、セグメントデータがどこから
始まるかを、32-bytes word の (オプションを含む) ヘッダ全サイズを与え
る 4-bit フィールドで指定する。これは、オプションを足したヘッダの全
サイズが 60 byte より少ないか等しくなければならない -- オプションは
40 bytes のままであることを意味する。
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 は、コネクション初期化に window-scaling と
timestamp 情報を送信するのがデフォルトである。ほとんどの詰め込まれた
セグメントは、コネクションを始めるための初期 SYN パケットであろう。
MD5 署名とで、SYN パケットは、次に述べるものを含む:
-- 4 bytes MSS option
4 bytes の MSS オプション
-- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD)
4 bytes のウィンドウスケールオプション (3 bytes が 4.4BSD で
は 4 にパッドされる)
-- 12 bytes for timestamp (4.4BSD pads the option as recommended
in RFC 1323 Appendix A)
タイムスタンプのための 12 bytes (4.4BSD は、RFC 1323 Appendix
A で推奨されるとして、このオプションをパッドする)
-- 18 bytes for MD5 digest
MD5 ダイジェストのための 18 bytes
-- 2 bytes for end-of-option-list, to pad to a 32-bit boundary.
32-bit 境界にパッドするように、end-of-option-list のための
2 bytes
This sums to 40 bytes, which just makes it.
これは、合計 40 bytes になり、ちょうどうまくいく。
4.4 MD5 as a Hashing Algorithm
4.4 ハッシュアルゴリズムとしての MD5
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 アルゴリズムを指定する。それは
このオプションが運用上すでに組み込まれ、同じオプションフィールドを使
用してアップグレードを許すように定義された "algorithm type" を持たな
いからである。もともとの文書は、タイプフィールドを指定しなかった。そ
れは個のオプションが少な区とも 1 つ以上の byte を必要とし、かつその
時点で全オプションの 19 bytes を得ること (そして TCP 実装で 20 bytes
へとたぶんパディングされる) はすでに制限されたオプション空間の大変無
駄な浪費であるからである。
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 のような) 他のハッシュアルゴリズムを使用する他の同類
のオプション組み込みを妨げない。その上、もしほとんどの実装がどんな方
法にせよ 20 bytes に定義されたとして 18 bytes オプションをパディング
するなら、アルゴリズムタイプフィールドを含む新しいオプションを当然お
まけに定義するべきであろう。
This would need to be addressed in another document, however.
しかしながらこのことは、他の文書で述べられる必要があるだろう。
4.5 Key configuration
4.5 鍵設定
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 bytes か、または少ない (bytes 数の) 表示可能な ASCII 文字列
から構成される最小鍵でサポートできることが強く推奨される。
-----------------------------------------------------------------------
5.0 Security Considerations
5.0 セキュリティに関する考察
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 のために現在実践されるセキュリティメカニ
ズムを定義する。これら問題を扱うため、異なるさらに強力なメカニズムの
提供を将来の研究で期待される。
-----------------------------------------------------------------------
6.0 References
6.0 参考文献
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
April 1992.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[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
Phone: +1 408 526-8115
EMail: ahh@cisco.com
-----------------------------------------------------------------------
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (1998). All Rights Reserved.
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.
一覧
スポンサーリンク
