RFC 6528 - Defending against Sequence Number Attacks 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6528
タイトル : RFC 6528 - シーケンス番号攻撃に対する防御
翻訳編集 : 自動生成

[要約] RFC 6528は、シーケンス番号攻撃に対する防御策を提案している。その目的は、TCPプロトコルのセキュリティを向上させ、攻撃者がシーケンス番号を予測してデータを傍受することを防ぐことである。

Internet Engineering Task Force (IETF)                           F. Gont
Request for Comments: 6528                        SI6 Networks / UTN-FRH
Obsoletes: 1948                                              S. Bellovin
Updates: 793                                         Columbia University
Category: Standards Track                                  February 2012
ISSN: 2070-1721

Defending against Sequence Number Attacks

シーケンス番号攻撃に対する防御

Abstract

概要

This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793.

このドキュメントでは、TCPの初期シーケンス番号（ISN）を生成するためのアルゴリズムを指定しています。これにより、オフパスの攻撃者がターゲット接続で使用されているシーケンス番号を推測する可能性が低くなります。このドキュメントは、RFC 1948を改訂（および廃止）し、そのドキュメントで最初に提案されたISN生成アルゴリズムを規格トラックに取り入れ、正式にRFC 793を更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6528.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6528で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Generation of Initial Sequence Numbers . . . . . . . . . . . .  3
   3.  Proposed Initial Sequence Number Generation Algorithm  . . . .  4
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  6
     6.2.  Informative References . . . . . . . . . . . . . . . . . .  7
   Appendix A.  Address-Based Trust-Relationship Exploitation
                Attacks . . . . . . . . . . . . . . . . . . . . . . . 10
     A.1.  Blind TCP Connection-Spoofing  . . . . . . . . . . . . . . 10
   Appendix B.  Changes from RFC 1948 . . . . . . . . . . . . . . . . 12

1. Introduction

1. はじめに

For a long time, the Internet has experienced a number of off-path attacks against TCP connections. These attacks have ranged from trust-relationship exploitation to denial-of-service attacks [CPNI-TCP]. Discussion of some of these attacks dates back to at least 1985, when Morris [Morris1985] described a form of attack based on guessing what sequence numbers TCP [RFC0793] will use for new connections between two known end-points.

長い間、インターネットはTCP接続に対する多数のパス外攻撃を経験しています。これらの攻撃は、信頼関係の悪用からサービス拒否攻撃[CPNI-TCP]までさまざまです。これらの攻撃のいくつかの議論は、少なくとも1985年に遡り、Morris [Morris1985]は、TCP [RFC0793]が2つの既知のエンドポイント間の新しい接続に使用するシーケンス番号の推測に基づく攻撃の形式を説明しました。

In 1996, RFC 1948 [RFC1948] proposed an algorithm for the selection of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing valid sequence numbers are reduced. With the aforementioned algorithm, such attacks would remain possible if and only if the attacker already has the ability to perform "man-in-the-middle" attacks.

1996年に、RFC 1948 [RFC1948]は、TCPの初期シーケンス番号（ISN）を選択するためのアルゴリズムを提案しました。これにより、パスを離れた攻撃者が有効なシーケンス番号を推測する可能性が低くなります。前述のアルゴリズムでは、攻撃者が「man-in-the-middle」攻撃を実行する能力をすでに持っている場合に限り、そのような攻撃は引き続き可能です。

This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track.

このドキュメントは、RFC 1948を改訂（および廃止）し、そのドキュメントで最初に提案されたISN生成アルゴリズムを標準化トラックに取り入れます。

Section 2 provides a brief discussion of the requirements for a good ISN generation algorithm. Section 3 specifies a good ISN selection algorithm. Appendix A provides a discussion of the trust-relationship exploitation attacks that originally motivated the publication of RFC 1948 [RFC1948]. Finally, Appendix B lists the differences from RFC 1948 to this document.

セクション2では、優れたISN生成アルゴリズムの要件について簡単に説明します。セクション3では、適切なISN選択アルゴリズムを指定しています。付録Aは、RFC 1948 [RFC1948]の発行を最初に動機とした信頼関係の悪用攻撃について説明しています。最後に、付録Bに、RFC 1948とこのドキュメントの違いを示します。

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 RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

2. Generation of Initial Sequence Numbers

2. 初期シーケンス番号の生成

RFC 793 [RFC0793] suggests that the choice of the ISN of a connection is not arbitrary, but aims to reduce the chances of a stale segment from being accepted by a new incarnation of a previous connection. RFC 793 [RFC0793] suggests the use of a global 32-bit ISN generator that is incremented by 1 roughly every 4 microseconds.

RFC 793 [RFC0793]は、接続のISNの選択は任意ではないことを示唆していますが、古いセグメントが以前の接続の新しい化身によって受け入れられる可能性を減らすことを目的としています。 RFC 793 [RFC0793]は、おおよそ4マイクロ秒ごとに1ずつ増加するグローバル32ビットISNジェネレータの使用を提案しています。

It is interesting to note that, as a matter of fact, protection against stale segments from a previous incarnation of the connection is enforced by preventing the creation of a new incarnation of a previous connection before 2*MSL have passed since a segment corresponding to the old incarnation was last seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This is accomplished by the TIME-WAIT state and TCP's "quiet time" concept (see Appendix B of [RFC1323]).

実際のところ、以前の接続のインカネーションからの古いセグメントに対する保護は、2 * MSLが対応するセグメントから経過する前に、以前の接続の新しいインカネーションが作成されないようにすることで適用されます。古い化身が最後に見られました（「MSL」は「最大セグメント寿命」[RFC0793]です）。これは、TIME-WAIT状態とTCPの「静かな時間」の概念によって実現されます（[RFC1323]の付録Bを参照）。

Based on the assumption that ISNs are monotonically increasing across connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an incoming SYN segment to perform "heuristics" that enable the creation of a new incarnation of a connection while the previous incarnation is still in the TIME-WAIT state (see p. 945 of [Wright1994]). This avoids an interoperability problem that may arise when a node establishes connections to a specific TCP end-point at a high rate [Silbersack2005].

ISNが接続全体で単調に増加しているという仮定に基づいて、多くのスタック（たとえば、4.2BSDから派生）は、着信SYNセグメントのISNを使用して「ヒューリスティック」を実行し、前のインカネーション中に接続の新しいインカネーションを作成できるようにします。まだTIME-WAIT状態です（[Wright1994]の945ページを参照）。これにより、ノードが特定のTCPエンドポイントへの接続を高速で確立するときに発生する可能性がある相互運用性の問題が回避されます[Silbersack2005]。

Unfortunately, the ISN generator described in [RFC0793] makes it trivial for an off-path attacker to predict the ISN that a TCP will use for new connections, thus allowing a variety of attacks against TCP connections [CPNI-TCP]. One of the possible attacks that takes advantage of weak sequence numbers was first described in [Morris1985], and its exploitation was widely publicized about 10 years later [Shimomura1995]. [CERT2001] and [USCERT2001] are advisories about the security implications of weak ISN generators. [Zalewski2001] and [Zalewski2002] contain a detailed analysis of ISN generators, and a survey of the algorithms in use by popular TCP implementations.

残念ながら、[RFC0793]で説明されているISNジェネレーターは、TCPが新しい接続に使用するISNをオフパス攻撃者が予測することを簡単にし、TCP接続に対するさまざまな攻撃を許可します[CPNI-TCP]。弱いシーケンス番号を利用する可能性のある攻撃の1つは[Morris1985]で最初に説明され、その悪用は約10年後[Shimomura1995]で広く公表されました。 [CERT2001]と[USCERT2001]は、弱いISNジェネレータのセキュリティへの影響に関する勧告です。 [Zalewski2001]と[Zalewski2002]には、ISNジェネレータの詳細な分析と、一般的なTCP実装で使用されているアルゴリズムの調査が含まれています。

Simple random selection of the TCP ISNs would mitigate those attacks that require an attacker to guess valid sequence numbers. However, it would also break the 4.4BSD "heuristics" to accept a new incoming connection when there is a previous incarnation of that connection in the TIME-WAIT state [Silbersack2005].

TCP ISNの単純なランダム選択は、攻撃者が有効なシーケンス番号を推測することを必要とする攻撃を緩和します。ただし、TIME-WAIT状態でその接続の以前の具体化がある場合、新しい着信接続を受け入れる4.4BSDの「ヒューリスティック」も破られます[Silbersack2005]。

We can prevent sequence number guessing attacks by giving each connection -- that is, each four-tuple of (localip, localport, remoteip, remoteport) -- a separate sequence number space. Within each space, the ISN is incremented according to [RFC0793]; however, there is no obvious relationship between the numbering in different spaces.

各接続（つまり、（localip、localport、remoteip、remoteport）の各4タプル）に個別のシーケンス番号スペースを与えることで、シーケンス番号推測攻撃を防ぐことができます。各スペース内で、ISNは[RFC0793]に従って増分されます。ただし、異なるスペースでの番号付けには明確な関係はありません。

An obvious way to prevent sequence number guessing attacks while not breaking the 4.4BSD heuristics would be to perform a simple random selection of TCP ISNs while maintaining state for dead connections (e.g. changing the TCP state transition diagram so that both end-points of all connections go to TIME-WAIT state). That would work but would consume system memory to store the additional state. Instead, we propose an improvement to the TCP ISN generation algorithm that does not require TCP to keep state for all recently terminated connections.

4.4BSDヒューリスティックを壊さずにシーケンス番号推測攻撃を防ぐ明白な方法は、デッド接続の状態を維持しながらTCP ISNの単純なランダム選択を実行することです（たとえば、すべての接続の両方のエンドポイントが変化するようにTCP状態遷移図を変更する） TIME-WAIT状態に移行します）。これは機能しますが、追加の状態を保存するためにシステムメモリを消費します。代わりに、最近終了したすべての接続の状態を維持するためにTCPを必要としない、TCP ISN生成アルゴリズムの改善を提案します。

3. Proposed Initial Sequence Number Generation Algorithm

3. 提案された初期シーケンス番号生成アルゴリズム

TCP SHOULD generate its Initial Sequence Numbers with the expression:

TCPは、次の式を使用して初期シーケンス番号を生成する必要があります（SHOULD）。

      ISN = M + F(localip, localport, remoteip, remoteport, secretkey)

where M is the 4 microsecond timer, and F() is a pseudorandom function (PRF) of the connection-id. F() MUST NOT be computable from the outside, or an attacker could still guess at sequence numbers from the ISN used for some other connection. The PRF could be implemented as a cryptographic hash of the concatenation of the connection-id and some secret data; MD5 [RFC1321] would be a good choice for the hash function.

ここで、Mは4マイクロ秒のタイマー、F()は接続IDの疑似ランダム関数（PRF）です。 F()は外部から計算可能であってはなりません。さもないと、攻撃者は他の接続に使用されるISNからのシーケンス番号を推測することができます。 PRFは、接続IDといくつかの秘密データを連結した暗号化ハッシュとして実装できます。 MD5 [RFC1321]は、ハッシュ関数に適しています。

The result of F() is no more secure than the secret key. If an attacker is aware of which cryptographic hash function is being used by the victim (which we should expect), and the attacker can obtain enough material (i.e., ISNs selected by the victim), the attacker may simply search the entire secret-key space to find matches. To protect against this, the secret key should be of a reasonable length. Key lengths of 128 bits should be adequate. The secret key can either be a true random number [RFC4086] or some per-host secret. A possible mechanism for protecting the secret key would be to change it on occasion. For example, the secret key could be changed whenever one of the following events occur:

F()の結果は、秘密鍵と同じくらい安全ではありません。攻撃者が被害者が使用している暗号化ハッシュ関数（私たちが予想するはずです）を認識しており、攻撃者が十分な資料（つまり、被害者が選択したISN）を取得できる場合、攻撃者は秘密鍵全体を検索するだけです。一致を検索するスペース。これを防ぐために、秘密鍵は適切な長さにする必要があります。 128ビットのキー長で十分です。秘密鍵は、真の乱数[RFC4086]またはホストごとの秘密のいずれかです。秘密鍵を保護するための可能なメカニズムは、時々それを変更することです。たとえば、次のいずれかのイベントが発生するたびに秘密鍵を変更できます。

o The system is being bootstrapped (e.g., the secret key could be a combination of some secret and the boot time of the machine).

o システムがブートストラップされています（たとえば、秘密鍵は、いくつかの秘密とマシンの起動時間の組み合わせである可能性があります）。

o Some predefined/random time has expired.

o 事前に定義された/ランダムな時間が経過しました。

o The secret key has been used sufficiently often that it should be regarded as insecure at that point.

o 秘密鍵は十分に頻繁に使用されているため、その時点では安全ではないと見なされます。

Note that changing the secret would change the ISN space used for reincarnated connections, and thus could cause the 4.4BSD heuristics to fail; to maintain safety, either dead connection state could be kept or a quiet time observed for two maximum segment lifetimes before such a change.

シークレットを変更すると、生まれ変わりの接続に使用されるISNスペースが変更され、4.4BSDヒューリスティックが失敗する可能性があることに注意してください。安全を維持するために、このような変更の前に、2つの最大セグメントライフタイムの間、デッド接続状態を維持するか、休止時間が観察されます。

It should be noted that while there have been concerns about the security properties of MD5 [RFC6151], the algorithm specified in this document simply aims at reducing the chances of an off-path attacker guessing the ISN of a new connection, and thus in our threat model it is not worth the effort for an attacker to try to learn the secret key. Since MD5 is faster than other "stronger" alternatives, and is used in virtually all existing implementations of this algorithm, we consider that use of MD5 in the specified algorithm is acceptable. However, implementations should consider the trade-offs involved in using functions with stronger security properties, and employ them if it is deemed appropriate.

MD5 [RFC6151]のセキュリティプロパティについて懸念がありましたが、このドキュメントで指定されているアルゴリズムは、オフパスの攻撃者が新しい接続のISNを推測する可能性を減らすことを目的としているため、脅威モデル攻撃者が秘密鍵を学習しようとしても、努力する価値はありません。 MD5は他の「より強力な」代替手段よりも高速であり、このアルゴリズムの既存のすべての実装で使用されているため、指定されたアルゴリズムでのMD5の使用は許容できると考えています。ただし、実装では、より強力なセキュリティプロパティを持つ関数の使用に伴うトレードオフを考慮し、適切であると考えられる場合はそれらを採用する必要があります。

4. Security Considerations

4. セキュリティに関する考慮事項

Good sequence numbers are not a replacement for cryptographic authentication, such as that provided by IPsec [RFC4301] or the TCP Authentication Option (TCP-AO) [RFC5925]. At best, they are a palliative measure.

適切なシーケンス番号は、IPsec [RFC4301]またはTCP認証オプション（TCP-AO）[RFC5925]によって提供されるものなど、暗号化認証の代わりにはなりません。せいぜい、緩和策です。

If random numbers are used as the sole source of the secret, they MUST be chosen in accordance with the recommendations given in [RFC4086].

乱数がシークレットの唯一のソースとして使用される場合、それらは[RFC4086]で与えられた推奨事項に従って選択されなければなりません（MUST）。

A security consideration that should be made about the algorithm proposed in this document is that it might allow an attacker to count the number of systems behind a Network Address Translator (NAT) [RFC3022]. Depending on the ISN generators implemented by each of the systems behind the NAT, an attacker might be able to count the number of systems behind a NAT by establishing a number of TCP connections (using the public address of the NAT) and identifying the number of different sequence number "spaces". [Gont2009] discusses how this and other information leakages at NATs could be mitigated.

このドキュメントで提案されているアルゴリズムについて行う必要があるセキュリティ上の考慮事項は、攻撃者がネットワークアドレス変換（NAT）[RFC3022]の背後にあるシステムの数をカウントできる可能性があることです。 NATの背後にある各システムで実装されているISNジェネレーターによっては、攻撃者は（NATのパブリックアドレスを使用して）TCP接続の数を確立し、異なるシーケンス番号「スペース」。 [Gont2009]は、NATでのこの情報漏えいやその他の情報漏えいをどのように軽減できるかについて説明しています。

An eavesdropper who can observe the initial messages for a connection can determine its sequence number state, and may still be able to launch sequence number guessing attacks by impersonating that connection. However, such an eavesdropper can also hijack existing connections [Joncheray1995], so the incremental threat is not that high. Still, since the offset between a fake connection and a given real connection will be more or less constant for the lifetime of the secret, it is important to ensure that attackers can never capture such packets. Typical attacks that could disclose them include both eavesdropping and the variety of routing attacks discussed in [Bellovin1989].

接続の最初のメッセージを監視できる盗聴者は、シーケンス番号の状態を判断でき、その接続を偽装することでシーケンス番号推測攻撃を開始できる可能性があります。ただし、このような盗聴者は既存の接続をハイジャックすることもできるため[Joncheray1995]、増分の脅威はそれほど高くありません。それでも、偽の接続と特定の実際の接続との間のオフセットは、シークレットの存続期間中はほぼ一定であるため、攻撃者がそのようなパケットをキャプチャできないようにすることが重要です。それらを開示できる典型的な攻撃には、盗聴と[Bellovin1989]で説明されているさまざまなルーティング攻撃の両方が含まれます。

Off-path attacks against TCP connections require the attacker to guess or know the four-tuple (localip, localport, remoteip, remoteport) that identifies the target connection. TCP port number randomization [RFC6056] reduces the chances of an attacker of guessing such a four-tuple by obfuscating the selection of TCP ephemeral ports, therefore contributing to the mitigation of such attacks. [RFC6056] provides advice on the selection of TCP ephemeral ports, such that the overall protection of TCP connections against off-path attacks is improved.

TCP接続に対するオフパス攻撃では、攻撃者はターゲット接続を識別する4つのタプル（localip、localport、remoteip、remoteport）を推測または認識する必要があります。 TCPポート番号のランダム化[RFC6056]は、TCPエフェメラルポートの選択を難読化することにより、攻撃者がこのような4タプルを推測する可能性を減らし、そのような攻撃の緩和に貢献します。 [RFC6056]は、TCP一時ポートの選択に関するアドバイスを提供し、オフパス攻撃に対するTCP接続の全体的な保護が改善されるようにします。

[CPNI-TCP] contains a discussion of all the currently known attacks that require an attacker to know or be able to guess the TCP sequence numbers in use by the target connection.

[CPNI-TCP]には、攻撃者がターゲット接続で使用されているTCPシーケンス番号を知っている、または推測できるようにする必要がある、現在知られているすべての攻撃に関する説明が含まれています。

5. Acknowledgements

5. 謝辞

Matt Blaze and Jim Ellis contributed some crucial ideas to RFC 1948, on which this document is based. Frank Kastenholz contributed constructive comments to that memo.

Matt BlazeとJim Ellisは、このドキュメントのベースとなっているRFC 1948にいくつかの重要なアイデアを提供しました。フランク・カステンホルツはそのメモに建設的なコメントを寄稿しました。

The authors of this document would like to thank (in chronological order) Alfred Hoenes, Lloyd Wood, Lars Eggert, Joe Touch, William Allen Simpson, Tim Shepard, Wesley Eddy, Anantha Ramaiah, and Ben Campbell for providing valuable comments on draft versions of this document.

このドキュメントの作成者は、ドラフトバージョンに関する貴重なコメントを提供してくれたAlfred Hoenes、Lloyd Wood、Lars Eggert、Joe Touch、William Allen Simpson、Tim Shepard、Wesley Eddy、Anantha Ramaiah、およびBen Campbellに（年代順に）感謝します。このドキュメント。

Fernando Gont wishes to thank Jorge Oscar Gont, Nelida Garcia, and Guillermo Gont for their love and support, and Daniel Bellomo and Christian O'Flaherty for their support in his Internet engineering activities.

フェルナンドゴントは、ホルヘオスカーゴント、ネリダガルシア、ギジェルモゴントの愛とサポート、ダニエルベッロモとクリスチャンオフラティのインターネットエンジニアリング活動へのサポートに感謝します。

Fernando Gont's attendance to IETF meetings was supported by ISOC's "Fellowship to the IETF" program.

フェルナンドゴントのIETF会議への出席は、ISOCの「IETFへのフェローシップ」プログラムによってサポートされました。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.

[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。

[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.

[RFC1323] Jacobson、V.、Braden、B。、およびD. Borman、「TCP Extensions for High Performance」、RFC 1323、1992年5月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.

[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。

[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.

[RFC6056] Larsen、M。およびF. Gont、「Recommendations for Transport-Protocol Port Randomization」、BCP 156、RFC 6056、2011年1月。

6.2. Informative References

6.2. 参考引用

[Bellovin1989] Morris, R., "Security Problems in the TCP/IP Protocol Suite", Computer Communications Review, vol. 19, no. 2, pp. 32-48, 1989.

[Bellovin1989] Morris、R。、「TCP / IPプロトコルスイートのセキュリティ問題」、Computer Communications Review、vol。 19、いいえ。 2、pp。32-48、1989。

[CERT2001] CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in TCP/IP Initial Sequence Numbers", http://www.cert.org/advisories/CA-2001-09.html, 2001.

[CERT2001] CERT、「CERT Advisory CA-2001-09：Statistical Weaknesses in TCP / IP Initial Sequence Numbers」、http：//www.cert.org/advisories/CA-2001-09.html、2001。

[CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", http://www.gont.com.ar/ papers/tn-03-09-security-assessment-TCP.pdf, 2009.

[CPNI-TCP] CPNI、「TCP（Transmission Control Protocol）のセキュリティ評価」、http：//www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf、2009年。

[Gont2009] Gont, F. and P. Srisuresh, "Security implications of Network Address Translators (NATs)", Work in Progress, October 2009.

[Gont2009] Gont、F。およびP. Srisuresh、「ネットワークアドレス変換器（NAT）のセキュリティへの影響」、Work in Progress、2009年10月。

[Joncheray1995] Joncheray, L., "A Simple Active Attack Against TCP", Proc. Fifth Usenix UNIX Security Symposium, 1995.

[Joncheray1995] Joncheray、L。、「TCPに対する単純なアクティブ攻撃」、Proc。第5回Usenix UNIXセキュリティシンポジウム、1995年。

[Morris1985] Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, NJ, 1985.

[Morris1985] Morris、R.、 "4.2 Weakness in the 4.2BSD UNIX TCP / IP Software"、CSTR 117、AT＆T Bell Laboratories、Murray Hill、NJ、1985。

[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.

[RFC0854] Postel、J。およびJ. Reynolds、「Telnet Protocol Specification」、STD 8、RFC 854、1983年5月。

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。

[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.

[RFC1948] Bellovin、S。、「シーケンス番号攻撃に対する防御」、RFC 1948、1996年5月。

[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.

[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、2001年1月。

[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.

[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、2005年7月。

[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.

[RFC4251] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）Protocol Architecture」、RFC 4251、2006年1月。

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。

[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.

[RFC4954] Siemborski、R。およびA. Melnikov、「認証用のSMTPサービス拡張」、RFC 4954、2007年7月。

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。

[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.

[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。

[RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol (AXFR)", RFC 5936, June 2010.

[RFC5936] Lewis、E。およびA. Hoenes、「DNS Zone Transfer Protocol（AXFR）」、RFC 5936、2010年6月。

[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.

[RFC6151]ターナーS.およびL.チェン、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムの更新されたセキュリティに関する考慮事項」、RFC 6151、2011年3月。

[Shimomura1995] Shimomura, T., "Technical details of the attack described by Markoff in NYT", http://www.gont.com.ar/docs/post-shimomura-usenet.txt, Message posted in USENET's comp.security.misc newsgroup, Message-ID: <3g5gkl$5j1@ariel.sdsc.edu>, 1995.

[Shimomura1995] Shimomura、T。、「MarkoffがNYTで記述した攻撃の技術的詳細」、http：//www.gont.com.ar/docs/post-shimomura-usenet.txt、USENETのcomp.securityに投稿されたメッセージ.miscニュースグループ、メッセージID：<3g5gkl$5j1@ariel.sdsc.edu>、1995。

[Silbersack2005] Silbersack, M., "Improving TCP/IP security through randomization without sacrificing interoperability", EuroBSDCon 2005 Conference.

[Silbersack2005] Silbersack、M。、「相互運用性を犠牲にすることなくランダム化によりTCP / IPセキュリティを改善する」、EuroBSDCon 2005会議。

[USCERT2001] US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple TCP/IP implementations may use statistically predictable initial sequence numbers", http://www.kb.cert.org/vuls/id/498440, 2001.

[USCERT2001] US-CERT、「US-CERT脆弱性ノートVU＃498440：複数のTCP / IP実装が統計的に予測可能な初期シーケンス番号を使用する可能性がある」、http：//www.kb.cert.org/vuls/id/498440、2001 。

[Wright1994] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The Implementation", Addison-Wesley, 1994.

[Wright1994] Wright、G。およびW. Stevens、「TCP / IP Illustrated、Volume 2：The Implementation」、Addison-Wesley、1994。

[Zalewski2001] Zalewski, M., "Strange Attractors and TCP/IP Sequence Number Analysis", http://lcamtuf.coredump.cx/oldtcp/tcpseq.html, 2001.

[Zalewski2001] Zalewski、M。、「奇妙なアトラクタとTCP / IPシーケンス番号分析」、http：//lcamtuf.coredump.cx/oldtcp/tcpseq.html、2001。

[Zalewski2002] Zalewski, M., "Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later", http://lcamtuf.coredump.cx/newtcp/, 2002.

[Zalewski2002] Zalewski、M。、「奇妙なアトラクタとTCP / IPシーケンス番号分析-1年後」、http：//lcamtuf.coredump.cx/newtcp/、2002。

Appendix A. Address-Based Trust-Relationship Exploitation Attacks

付録A.アドレスベースの信頼関係の悪用攻撃

This section discusses the trust-relationship exploitation attack that originally motivated the publication of RFC 1948 [RFC1948]. It should be noted that while RFC 1948 focused its discussion of address-based trust-relationship exploitation attacks on Telnet [RFC0854] and the various UNIX "r" commands, both Telnet and the various "r" commands have since been largely replaced by secure counterparts (such as SSH [RFC4251]) for the purpose of remote login and remote command execution. Nevertheless, address-based trust relationships are still employed nowadays in some scenarios. For example, some SMTP [RFC5321] deployments still authenticate their users by means of their IP addresses, even when more appropriate authentication mechanisms are available [RFC4954]. Another example is the authentication of DNS secondary servers [RFC1034] by means of their IP addresses for allowing DNS zone transfers [RFC5936], or any other access control mechanism based on IP addresses.

このセクションでは、元々RFC 1948 [RFC1948]の公開を動機とした信頼関係の悪用攻撃について説明します。 RFC 1948は、Telnet [RFC0854]とさまざまなUNIXの "r"コマンドに対するアドレスベースの信頼関係の悪用攻撃についての議論に焦点を当てていましたが、Telnetとさまざまな "r"コマンドの両方は、大部分が安全なものに置き換えられています。リモートログインおよびリモートコマンド実行を目的とした対応物（SSH [RFC4251]など）。それにもかかわらず、現在、いくつかのシナリオでは、アドレスベースの信頼関係が依然として採用されています。たとえば、一部のSMTP [RFC5321]展開では、より適切な認証メカニズムが利用可能な場合でも、IPアドレスを使用してユーザーを認証します[RFC4954]。別の例は、DNSゾーン転送を許可するためのIPアドレス[RFC5936]、またはIPアドレスに基づく他のアクセス制御メカニズムによるDNSセカンダリサーバー[RFC1034]の認証です。

In 1985, Morris [Morris1985] described a form of attack based on guessing what sequence numbers TCP [RFC0793] will use for new connections. Briefly, the attacker gags a host trusted by the target, impersonates the IP address of the trusted host when talking to the target, and completes the three-way handshake based on its guess at the next ISN to be used. An ordinary connection to the target is used to gather sequence number state information. This entire sequence, coupled with address-based authentication, allows the attacker to execute commands on the target host.

1985年に、Morris [Morris1985]は、TCP [RFC0793]が新しい接続に使用するシーケンス番号の推測に基づく攻撃の形式について説明しました。簡単に言うと、攻撃者はターゲットが信頼するホストをギャグし、ターゲットと通信するときに信頼できるホストのIPアドレスを偽装し、次に使用するISNでの推測に基づいて3ウェイハンドシェイクを完了します。ターゲットへの通常の接続は、シーケンス番号の状態情報を収集するために使用されます。このシーケンス全体とアドレスベースの認証を組み合わせることで、攻撃者はターゲットホストでコマンドを実行できます。

Clearly, the proper solution for these attacks is cryptographic authentication [RFC4301] [RFC4120] [RFC4251].

明らかに、これらの攻撃に対する適切なソリューションは、暗号化認証[RFC4301] [RFC4120] [RFC4251]です。

The following subsection provides technical details for the trust-relationship exploitation attack described by Morris [Morris1985].

次のサブセクションでは、Morris [Morris1985]によって説明されている信頼関係の悪用攻撃の技術的な詳細を示します。

A.1. Blind TCP Connection-Spoofing

A.1. ブラインドTCP接続スプーフィング

In order to understand the particular case of sequence number guessing, one must look at the three-way handshake used in the TCP open sequence [RFC0793]. Suppose client machine A wants to talk to rsh server B. It sends the following message:

シーケンス番号の推測の特定のケースを理解するために、TCPオープンシーケンス[RFC0793]で使用される3ウェイハンドシェイクを確認する必要があります。クライアントマシンAがrshサーバーBと通信したいとします。次のメッセージを送信します。

A->B: SYN, ISNa

A-> B：SYN、ISNa

That is, it sends a packet with the SYN ("synchronize sequence number") bit set and an initial sequence number ISNa.

つまり、SYN（「同期シーケンス番号」）ビットセットと初期シーケンス番号ISNaを含むパケットを送信します。

B replies with

Bは、

                         B->A: SYN, ISNb, ACK(ISNa)

In addition to sending its own ISN, it acknowledges A's. Note that the actual numeric value ISNa must appear in the message.

独自のISNを送信することに加えて、Aを確認します。実際の数値ISNaがメッセージに表示される必要があることに注意してください。

A concludes the handshake by sending

送信することでハンドシェイクを終了します

                              A->B: ACK(ISNb)

RFC 793 [RFC0793] specifies that the 32-bit counter be incremented by 1 in the low-order position about every 4 microseconds. Instead, Berkeley-derived kernels traditionally incremented it by a constant every second, and by another constant for each new connection. Thus, if you opened a connection to a machine, you knew to a very high degree of confidence what sequence number it would use for its next connection. And therein lied the vulnerability.

RFC 793 [RFC0793]は、32ビットカウンターが約4マイクロ秒ごとに下位位置で1ずつ増分されることを指定しています。代わりに、バークレーから派生したカーネルは、伝統的に毎秒定数を増やし、新しい接続ごとに別の定数を増やしました。したがって、マシンへの接続を開いた場合、次の接続に使用するシーケンス番号を非常に高い確信度で知っていました。そしてそこに脆弱性を嘘をついた。

The attacker X first opens a real connection to its target B -- say, to the mail port or the TCP echo port. This gives ISNb. It then impersonates A and sends

攻撃者Xは、最初にターゲットBへの実際の接続を開きます。たとえば、メールポートまたはTCPエコーポートへの接続です。これによりISNbが得られます。次に、Aを偽装して送信します

Ax->B: SYN, ISNx

Ax-> B：SYN、ISNx

where "Ax" denotes a packet sent by X pretending to be A.

ここで、「Ax」は、XがAになりすまして送信したパケットを示します。

B's response to X's original SYN (so to speak)

Xの元のSYNに対するBの応答（いわば）

                        B->A: SYN, ISNb', ACK(ISNx)

goes to the legitimate A, about which more anon. X never sees that message but can still send

正当なAに行きます。 Xはそのメッセージを見ることはありませんが、送信することはできます

                             Ax->B: ACK(ISNb')

using the predicted value for ISNb'. If the guess is right -- and usually it will be, if the sequence numbers are weak -- B's rsh server thinks it has a legitimate connection with A, when in fact X is sending the packets. X can't see the output from this session, but it can execute commands as more or less any user -- and in that case, the game is over and X has won.

ISNb 'の予測値を使用します。推測が正しい場合（通常、シーケンス番号が弱い場合は正しい）、Bのrshサーバーは、実際にXがパケットを送信しているときに、Aとの正当な接続があると見なします。 Xはこのセッションからの出力を見ることができませんが、多かれ少なかれ任意のユーザーとしてコマンドを実行できます-その場合、ゲームは終了し、Xは勝利しました。

There is a minor difficulty here. If A sees B's message, it will realize that B is acknowledging something it never sent, and will send a RST packet in response to tear down the connection. However, an attacker could send the TCP segments containing the commands to be executed back-to-back with the segments required to establish the TCP connection, and thus by the time the connection is reset, the attacker has already won.

ここで小さな問題があります。 AはBのメッセージを見ると、Bが送信していないものを確認していることを認識し、接続の切断に応答してRSTパケットを送信します。ただし、攻撃者は、TCP接続を確立するために必要なセグメントと連続して実行されるコマンドを含むTCPセグメントを送信する可能性があるため、接続がリセットされるまでに、攻撃者はすでに勝っています。

In the past, attackers exploited a common TCP implementation bug to prevent the connection from being reset (see subsection "A Common TCP Bug" in [RFC1948]). However, all TCP implementations that used to implement this bug have been fixed for a long time.

以前は、攻撃者は一般的なTCP実装のバグを悪用して、接続がリセットされないようにしていました（[RFC1948]のサブセクション「一般的なTCPバグ」を参照）。ただし、このバグの実装に使用されていたすべてのTCP実装は、長い間修正されています。

Appendix B. Changes from RFC 1948

付録B. RFC 1948からの変更点

o This document is Standards Track (rather than Informational).

o このドキュメントは、標準ではありません（情報提供ではありません）。

o Formal requirements [RFC2119] are specified.

o 正式な要件[RFC2119]が指定されています。

o The discussion of address-based trust-relationship attacks has been updated and moved to an appendix.

o アドレスベースの信頼関係攻撃の説明が更新され、付録に移動しました。

o The subsection entitled "A Common TCP Bug" (describing a common bug in the BSD TCP implementation) has been removed.

o 「一般的なTCPバグ」というタイトルのサブセクション（BSD TCP実装の一般的なバグについて説明）は削除されました。

Authors' Addresses

著者のアドレス

Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina

フェルナンドゴンSI6ネットワーク/ UTN-FRHエヴァリストキャリーゴ2644ブエノスアイレス州ハエド1706アルゼンチン

   Phone: +54 11 4650 8472
   EMail: fgont@si6networks.com
   URI:   http://www.si6networks.com

Steven M. Bellovin Columbia University 1214 Amsterdam Avenue MC 0401 New York, NY 10027 US

スティーブンMベロビンコロンビア大学1214アムステルダムアベニューMC 0401ニューヨーク、ニューヨーク10027米国

   Phone: +1 212 939 7149
   EMail: bellovin@acm.org