Internet Engineering Task Force (IETF) M. Larsen
Request for Comments: 6056 Tieto
BCP: 156 F. Gont
Category: Best Current Practice UTN/FRH
ISSN: 2070-1721 January 2011
Recommendations for Transport-Protocol Port Randomization
Abstract
抽象
During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers).
過去数年の間に、意識が伝送制御プロトコル（TCP）と同様のプロトコルに対して実行することができ、「ブラインド」攻撃の数について提起されてきました。これらの攻撃の結果は、接続またはデータの破損を壊れたために、スループット低下の範囲です。これらの攻撃は、攻撃されるトランスポートプロトコルインスタンスを識別する5タプル（プロトコル、送信元アドレス、宛先アドレス、送信元ポート、宛先ポート）を推測するか知っている攻撃者の能力に依存します。この文書は、クライアントポート番号を選択するための単純かつ効率的な方法の数を記載し、正確な値を推測攻撃の可能性が低減されるようになっています。これは、トランスポートプロトコルインスタンスを保護するための暗号化方法の代替ではないが、前述のポート選択アルゴリズムは、非常に少ない労力で、任意の鍵管理オーバーヘッドなしで改善されたセキュリティを提供します。この文書で説明したアルゴリズムは、インクリメンタルに展開することができる、そのようなTCP、UDP、UDP-LITE、ストリーム制御伝送プロトコル（SCTP）、それらから利益を得ることができるトランスポートプロトコルのいずれかの仕様を違反していないローカルポリシーですデータグラム輻輳制御プロトコル（DCCP）、およびRTP（RTPアプリケーションが明示的にRTPとRTCPポート番号を通知することを条件とします）。
Status of This Memo
このメモのステータス
This memo documents an Internet Best Current Practice.
このメモはインターネット最も良い現在の練習を説明します。
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 BCPs is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 BCPの詳細については、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/rfc6056.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6056で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 5
2.2. Ephemeral Port Selection . . . . . . . . . . . . . . . . . 6
2.3. Collision of instance-ids . . . . . . . . . . . . . . . . 7
3. Obfuscating the Ephemeral Port Selection . . . . . . . . . . . 8
3.1. Characteristics of a Good Algorithm for the
Obfuscation of the Ephemeral Port Selection . . . . . . . 8
3.2. Ephemeral Port Number Range . . . . . . . . . . . . . . . 10
3.3. Algorithms for the Obfuscation of the Ephemeral Port
Selection . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Algorithm 1: Simple Port Randomization Algorithm . . . 11
3.3.2. Algorithm 2: Another Simple Port Randomization
Algorithm . . . . . . . . . . . . . . . . . . . . . . 13
3.3.3. Algorithm 3: Simple Hash-Based Port Selection
Algorithm . . . . . . . . . . . . . . . . . . . . . . 14
3.3.4. Algorithm 4: Double-Hash Port Selection Algorithm . . 16
3.3.5. Algorithm 5: Random-Increments Port Selection
Algorithm . . . . . . . . . . . . . . . . . . . . . . 18
3.4. Secret-Key Considerations for Hash-Based Port
Selection Algorithms . . . . . . . . . . . . . . . . . . . 19
3.5. Choosing an Ephemeral Port Selection Algorithm . . . . . . 20
4. Interaction with Network Address Port Translation (NAPT) . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Survey of the Algorithms in Use by Some Popular
Implementations . . . . . . . . . . . . . . . . . . . 28
A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 28
Recently, awareness has been raised about a number of "blind" attacks (i.e., attacks that can be performed without the need to sniff the packets that correspond to the transport protocol instance to be attacked) that can be performed against the Transmission Control Protocol (TCP) [RFC0793] and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption [RFC5927] [RFC4953] [Watson].
最近、意識は「ブラインド」攻撃の数について提起されている（すなわち、攻撃されるトランスポートプロトコルインスタンスに対応するパケット盗聴することなく行うことができます攻撃）、伝送制御プロトコルに対して実行することができます（ TCP）[RFC0793]と同様のプロトコル。これらの攻撃の影響は、接続またはデータの破損を破断するスループットの低下[RFC5927]、[RFC4953] [ワトソン]の範囲です。
All these attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Source port, Destination Address, Destination Port) that identifies the transport protocol instance to be attacked.
すべてのこれらの攻撃は、攻撃対象のトランスポートプロトコルインスタンスを識別する攻撃者の5タプルを推測か知っている能力（プロトコル、送信元アドレス、送信元ポート、宛先アドレス、宛先ポート）に依存しています。
Services are usually located at fixed, "well-known" ports [IANA] at the host supplying the service (the server). Client applications connecting to any such service will contact the server by specifying the server IP address and service port number. The IP address and port number of the client are normally left unspecified by the client application and thus are chosen automatically by the client networking stack. Ports chosen automatically by the networking stack are known as ephemeral ports [Stevens].
サービスは、通常、[IANA]ホストにサービス（サーバ）を供給する固定、「既知の」ポートに配置されています。どのようなサービスに接続するクライアントアプリケーションは、サーバーのIPアドレスとサービスポート番号を指定して、サーバーに連絡します。クライアントのIPアドレスとポート番号は、通常、クライアントアプリケーションによって未指定されているので、クライアントのネットワークスタックによって自動的に選択されています。ネットワークスタックにより自動的に選択されたポートは、エフェメラルポート[スティーブンス]として知られています。
While the server IP address, the well-known port, and the client IP address may be known by an attacker, the ephemeral port of the client is usually unknown and must be guessed.
サーバーのIPアドレスは、よく知られたポート、およびクライアントのIPアドレスが攻撃者によって知られているかもしれないが、クライアントの一時的なポートは、通常は不明であると推測されなければなりません。
This document describes a number of algorithms for the selection of ephemeral port numbers, such that the possibility of an off-path attacker guessing the exact value is reduced. They are not a replacement for cryptographic methods of protecting a transport-protocol instance such as IPsec [RFC4301], the TCP MD5 signature option [RFC2385], or the TCP Authentication Option [RFC5925]. For example, they do not provide any mitigation in those scenarios in which the attacker is able to sniff the packets that correspond to the transport protocol instance to be attacked. However, the proposed algorithms provide improved resistance to off-path attacks with very little effort and without any key management overhead.
この文書では、正確な値を推測オフパス攻撃の可能性が低減されるように、エフェメラルポート番号を選択するためのアルゴリズムの数を記述する。それらは、IPsecの[RFC4301]、TCP MD5署名オプション[RFC2385]、またはTCP認証オプション[RFC5925]としてトランスポートプロトコルインスタンスを保護する暗号方式に代わるものではありません。例えば、それらは、攻撃者が攻撃されるトランスポートプロトコルインスタンスに対応するパケットを傍受することが可能である、これらのシナリオのいずれかの緩和を提供しません。しかし、提案されたアルゴリズムは、非常に少ない労力で、任意の鍵管理オーバーヘッドなしオフパス攻撃に対する改善された耐性を提供します。
The mechanisms described in this document are local modifications that may be incrementally deployed, and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550] (provided the RTP application explicitly signals the RTP and RTCP port numbers with, e.g., [RFC3605]).
本書で説明されたメカニズムは、増分的に展開することができるローカルの変更があり、それは、TCP [RFC0793]、UDP [RFC0768]、SCTP [RFC4960]としてそれらから利益を得ることができるトランスポートプロトコルのいずれかの仕様を、違反していません、DCCP [RFC4340]、UDP-Liteは[RFC3828]、およびRTP [RFC3550]（とRTPアプリケーションが明示的にRTPとRTCPポート番号を通知設け、例えば、[RFC3605]）。
Since these mechanisms are obfuscation techniques, focus has been on a reasonable compromise between the level of obfuscation and the ease of implementation. Thus, the algorithms must be computationally efficient and not require substantial state.
これらのメカニズムは、難読化技術であるため、焦点は難読化のレベルと実装の容易さとの間の合理的な妥協になっています。このように、アルゴリズムは、計算上効率的かつ実質的な状態を要求してはなりません。
We note that while the technique of mitigating "blind" attacks by obfuscating the ephemeral port selection is well-known as "port randomization", the goal of the algorithms described in this document is to reduce the chances of an attacker guessing the ephemeral ports selected for new transport protocol instances, rather than to actually produce mathematically random sequences of ephemeral ports.
我々は一時的なポートの選択を難読化により「ブラインド」攻撃を軽減する手法は「ポートのランダム化」としてよく知られているが、この文書で説明したアルゴリズムの目標は、選択されたエフェメラルポートを推測する攻撃の可能性を減らすためであることに注意してください新しいトランスポートプロトコルインスタンスのためではなく、実際にエフェメラルポートの数学的にランダムな配列を生成します。
Throughout this document, we will use the term "transport-protocol instance" as a general term to refer to an instantiation of a transport protocol (e.g., a "connection" in the case of connection-oriented transport protocols) and the term "instance-id" as a short-handle to refer to the group of values that identify a transport-protocol instance (e.g., in the case of TCP, the five-tuple {Protocol, IP Source Address, TCP Source Port, IP Destination Address, TCP Destination Port}).
このドキュメントでは、我々はトランスポートプロトコル（例えば、接続指向のトランスポートプロトコルの場合は、「接続」）という用語は、「インスタンスのインスタンス化を参照するために、一般的な用語として、用語「トランスポートプロトコルインスタンス」を使用します、TCP、5タプル{プロトコル、送信元IPアドレス、TCP送信元ポート、IP宛先アドレスの場合には、例えば（トランスポートプロトコルインスタンスを識別する値のグループを参照するために、短いハンドルとして「-id TCP宛先ポート}）。
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]に記載されているように解釈されます。
The Internet Assigned Numbers Authority (IANA) assigns the unique parameters and values used in protocols developed by the Internet Engineering Task Force (IETF), including well-known ports [IANA]. IANA has reserved the following use of the 16-bit port range of TCP and UDP:
IANA（Internet Assigned Numbers Authority）は、周知のポート[IANA]を含むインターネット・エンジニアリング・タスク・フォース（IETF）によって開発されたプロトコルで使用される固有のパラメータと値を割り当てます。 IANAはTCPとUDPの16ビットのポート範囲の以下の使用を予約しています：
o The Well-Known Ports, 0 through 1023.
Oウェルノウンポート、0〜1023。
o The Registered Ports, 1024 through 49151
49151で登録ポート1024 O
o The Dynamic and/or Private Ports, 49152 through 65535
動的および/またはプライベートポートO、65535 49152
The dynamic port range defined by IANA consists of the 49152-65535 range, and is meant for the selection of ephemeral ports.
IANAによって定義された動的ポートの範囲は、49152〜65535の範囲で構成され、エフェメラルポートの選択を意味します。
As each communication instance is identified by the five-tuple {protocol, local IP address, local port, remote IP address, remote port}, the selection of ephemeral port numbers must result in a unique five-tuple.
各通信インスタンスは5タプル{プロトコル、ローカルIPアドレス、ローカルポート、リモートIPアドレス、リモートポート}によって識別されるように、エフェメラルポート番号の選択は、ユニークな5タプルを生じなければなりません。
Selection of ephemeral ports such that they result in unique instance-ids (five-tuples) is handled by some implementations by having a per-protocol global "next_ephemeral" variable that is equal to the previously chosen ephemeral port + 1, i.e., the selection process is:
それらは以前に選択されたエフェメラルポート+ 1、すなわち、選択に等しいプロトコルごとのグローバル「next_ephemeral」変数を持つことによっていくつかの実装によって処理される固有のインスタンス・IDS（5タプル）をもたらすようなエフェメラルポートの選択このプロセスは次のとおりです。
/* Initialization at system boot time. Could be random */
next_ephemeral = min_ephemeral;
/* Ephemeral port selection function */
count = max_ephemeral - min_ephemeral + 1;
do {
port = next_ephemeral;
if (next_ephemeral == max_ephemeral) {
next_ephemeral = min_ephemeral;
} else {
next_ephemeral++;
}
if (check_suitable_port(port))
return port;
count--;
カウント - ;
} while (count > 0);
ながら}（> 0のカウント）。
return ERROR;
ERRORを返します。
Traditional BSD Port Selection Algorithm
伝統的なBSDポート選択アルゴリズム
Note: check_suitable_port() is a function that checks whether the resulting port number is acceptable as an ephemeral port. That is, it checks whether the resulting port number is unique and may, in addition, check that the port number is not in use for a connection in the LISTEN or CLOSED states and that the port number is not in the list of port numbers that should not be allocated as ephemeral ports. In BSD-derived systems, the check_suitable_port() would correspond to the in_pcblookup_local() function, where all the necessary checks would be performed.
注：check_suitable_port（）得られたポート番号がエフェメラルポートとして許容可能であるかどうかをチェックする機能です。すなわち、得られたポート番号が一意であるかどうかをチェックし、加えて、ポート番号が聴いたり、閉状態で接続するために使用されていないことを確認できると、ポート番号は、ポート番号のリストにないことをそのエフェメラルポートとして割り当てられるべきではありません。 BSD由来のシステムにおいて、check_suitable_port（）すべての必要なチェックが実行されるin_pcblookup_local（）関数に対応します。
This algorithm works adequately provided that the number of transport-protocol instances (for each transport protocol) that have a lifetime longer than it takes to exhaust the total ephemeral port range is small, so that collisions of instance-ids are rare.
このアルゴリズムは十分にそれが総エフェメラルポート範囲を排出するのにかかるよりも長い寿命を有する（各トランスポートプロトコルの）トランスポートプロトコルのインスタンスの数は、インスタンスIDの衝突がまれであるように、小さいことを条件とする作品。
However, this method has the drawback that the "next_ephemeral" variable and thus the ephemeral port range is shared between all transport-protocol instances, and the next ports chosen by the client are easy to predict. If an attacker operates an "innocent" server to which the client connects, it is easy to obtain a reference point for the current value of the "next_ephemeral" variable. Additionally, if an attacker could force a client to periodically establish, e.g., a new TCP connection to an attacker-controlled machine (or through an attacker-observable path), the attacker could subtract consecutive source port values to obtain the number of outgoing TCP connections established globally by the target host within that time period (up to wrap-around issues and instance-id collisions, of course).
しかし、この方法は、「next_ephemeral」可変したがってエフェメラルポートの範囲は、すべてのトランスポートプロトコルのインスタンス間で共有されるという欠点を有しており、クライアントによって選択された次のポートは、予測するのが容易です。攻撃者は、クライアントが接続する「無実」サーバを操作する場合、「next_ephemeral」変数の現在の値のための基準点を得ることが容易です。攻撃者は、例えば、定期的に確立するために、攻撃者が制御マシンへ（または攻撃者が観察可能なパスを介して）新しいTCPコネクションをクライアントを強制することができればさらに、攻撃者は、発信TCPの数を得るために、連続した送信元ポートの値を引くことができその期間内に対象のホストによって世界的に確立された接続（もちろんのラップアラウンドする問題とinstance-idに衝突、アップ）。
While it is possible for the ephemeral port selection algorithm to verify that the selected port number results in a instance-id that is not currently in use by that system, the resulting five-tuple may still be in use at a remote system. For example, consider a scenario in which a client establishes a TCP connection with a remote web server, and the web server performs the active close on the connection. While the state information for this connection will disappear at the client side (that is, the connection will be moved to the fictional CLOSED state), the instance-id will remain in the TIME-WAIT state at the web server for 2*MSL (Maximum Segment Lifetime). If the same client tried to create a new incarnation of the previous connection (that is, a connection with the same instance-id as the one in the TIME_WAIT state at the server), an instance-id "collision" would occur. The effect of these collisions range from connection-establishment failures to TIME-WAIT state assassination (with the potential of data corruption) [RFC1337]. In scenarios in which a specific client establishes TCP connections with a specific service at a server, these problems become evident. Therefore, an ephemeral port selection algorithm should ideally minimize the rate of instance-id collisions.
エフェメラルポート選択アルゴリズムが選択されたポート番号は、そのシステムによって現在使用されていないインスタンスIDになることを確認することが可能であるが、得られる5タプルは、依然として、遠隔システムでの使用であってもよいです。たとえば、クライアントがリモートWebサーバとのTCPコネクションを確立し、Webサーバーが接続でアクティブクローズを実行するシナリオを検討してください。この接続の状態情報（つまり、接続が架空CLOSED状態に移行する）クライアント側で表示されなくなりますが、インスタンスIDは、（2 * MSLのWebサーバにTIME-WAIT状態にとどまります最大セグメントライフタイム）。同じクライアントが前の接続の新しいインカネーションを作成しようとした場合（つまり、サーバーでのTIME_WAIT状態にあるものと同じインスタンスIDとの接続）、instance-idに「衝突」が発生します。これらの衝突の影響は、接続確立の失敗から（データ破損の可能性を有する）TIME-WAIT状態暗殺[RFC1337]の範囲です。特定のクライアントがサーバの特定のサービスとのTCP接続を確立するシナリオでは、これらの問題が顕在化。したがって、エフェメラルポート選択アルゴリズムは、理想的には、インスタンスIDの衝突速度を最小にしなければなりません。
A simple approach to minimize the rate of these collisions would be to choose port numbers incrementally, so that a given port number would not be reused until the rest of the port numbers in the ephemeral port range have been used for a transport protocol instance. However, if a single global variable were used to keep track of the last ephemeral port selected, ephemeral port numbers would be trivially predictable, thus making it easier for an off-path attacker to "guess" the instance-id in use by a target transport-protocol instance. Sections 3.3.3 and 3.3.4 describe algorithms that select port numbers incrementally, while still making it difficult for an off-path attacker to predict the ephemeral ports used for future transport-protocol instances.
これらの衝突速度を最小にする簡単な方法は、エフェメラルポートの範囲内のポート番号の残りの部分は、トランスポートプロトコルインスタンスのために使用されるまで、指定されたポート番号が再使用されないように、増分ポート番号を選択することであろう。単一のグローバル変数を選択し、最後の一時的なポートを追跡するために使用された場合は、一時的なポート番号は、このようにターゲットによって使用されているインスタンスIDを「推測」して、オフパス攻撃者にとって、それは容易になり、自明予測可能になりますトランスポートプロトコルインスタンス。まだそれが難しいオフパス攻撃者が将来のトランスポートプロトコルのインスタンスに使用されるエフェメラルポートを予測するためながらセクション3.3.3および3.3.4は、増分ポート番号を選択するアルゴリズムを記述する。
A simple but inefficient approach to minimize the rate of collisions of instance-ids would be, e.g., in the case of TCP, for both endpoints of a TCP connection to keep state about recent connections (e.g., have both endpoints end up in the TIME-WAIT state).
最近の接続（例えば、約状態を維持するためにTCP接続の両方のエンドポイントが両方のエンドポイントが時間内に終わる持っているため、インスタンスIDの衝突率を最小にするために単純だが非効率的なアプローチは、TCPの場合には、例えば、だろう-WAIT状態）。
3.1. Characteristics of a Good Algorithm for the Obfuscation of the Ephemeral Port Selection
3.1. エフェメラルポート選択の難読化のための良いアルゴリズムの特性
There are several factors to consider when designing an algorithm for selecting ephemeral ports, which include:
含まエフェメラルポートを選択するためのアルゴリズムを設計する際に考慮すべきいくつかの要因があります。
o Minimizing the predictability of the ephemeral port numbers used for future transport-protocol instances.
将来のトランスポートプロトコルインスタンスのために使用さエフェメラルポート番号の予測可能性を最小限に抑えるO。
o Minimizing collisions of instance-ids.
インスタンスIDの衝突を最小限に抑えるO。
o Avoiding conflict with applications that depend on the use of specific port numbers.
特定のポート番号の使用に依存するアプリケーションとの競合を避けるO。
Given the goal of improving the transport protocol's resistance to attack by obfuscation of the instance-id selection, it is key to minimize the predictability of the ephemeral ports that will be selected for new transport-protocol instances. While the obvious approach to address this requirement would be to select the ephemeral ports by simply picking a random value within the chosen port number range, this straightforward policy may lead to collisions of instance-ids, which could lead to the interoperability problems (e.g., delays in the establishment of new connections, failures in connection establishment, or data corruption) discussed in Section 2.3. As discussed in Section 1, it is worth noting that while the technique of mitigating "blind" attacks by obfuscating the ephemeral port selection is well-known as "port randomization", the goal of the algorithms described in this document is to reduce the chances that an attacker will guess the ephemeral ports selected for new transport-protocol instances, rather than to actually produce sequences of mathematically random ephemeral port numbers.
instance-idに選択の難読化による攻撃するトランスポートプロトコルの耐性を向上させるという目的を考えると、新しいトランスポートプロトコルインスタンスのために選択されますエフェメラルポートの予測可能性を最小化するための鍵です。この要件に対処するための明白なアプローチは、単に選択したポート番号の範囲内でランダムな値を選ぶことにより、エフェメラルポートを選択することであろうが、この単純なポリシーは、例えば、相互運用性の問題につながる可能性があるインスタンスIDの衝突、（につながる可能性があり、新しい接続、接続の確立の失敗、またはデータの破損）の確立の遅れは、2.3節で述べました。第1節で述べたように、それは、この文書で説明したアルゴリズムの目標は、可能性を低くすることで、一時的なポートの選択を難読化することにより、「ブラインド」攻撃を軽減する技術がある一方で、「ポートのランダム化」としてよく知られていることは注目に値します攻撃者は、実際には数学的にランダムな一時ポート番号のシーケンスを生成するのではなく、新しいトランスポートプロトコルインスタンスのために選択されたエフェメラルポートを推測すること。
It is also worth noting that, provided adequate algorithms are in use, the larger the range from which ephemeral ports are selected, the smaller the chances of an attacker are to guess the selected port number.
それはまた、提供十分なアルゴリズムはエフェメラルポートが選択される範囲が大きいほど、より小さな攻撃の可能性は、選択されたポート番号を推測することであり、使用中である、ということは注目に値します。
In scenarios in which a specific client establishes transport-protocol instances with a specific service at a server, the problems described in Section 2.3 become evident. A good algorithm to minimize the collisions of instance-ids would consider the time a given five-tuple was last used, and would avoid reusing the last recently used five-tuples. A simple approach to minimize the rate of collisions would be to choose port numbers incrementally, so that a given port number would not be reused until the rest of the port numbers in the ephemeral port range have been used for a transport-protocol instance. However, if a single global variable were used to keep track of the last ephemeral port selected, ephemeral port numbers would be trivially predictable.
特定のクライアントがサーバーに特定のサービスとトランスポートプロトコルインスタンスを確立するシナリオでは、2.3節に記載問題が明らかになる。インスタンスIDの衝突を最小限に抑えるための良いアルゴリズムが与えられた5タプルが最後に使用された、と最近5タプルを使用した最後の再利用を回避する時間を検討します。衝突速度を最小にする簡単な方法は、エフェメラルポートの範囲内のポート番号の残りの部分は、トランスポートプロトコルインスタンスのために使用されるまで、指定されたポート番号が再使用されないように、増分ポート番号を選択することであろう。単一のグローバル変数を選択し、最後の一時的なポートを追跡するために使用された場合は、一時的なポート番号は自明予測可能になります。
It is important to note that a number of applications rely on binding specific port numbers that may be within the ephemeral port range. If such an application were run while the corresponding port number were in use, the application would fail. Therefore, ephemeral port selection algorithms avoid using those port numbers.
アプリケーションの数が一時ポート範囲内とすることができる特定のポート番号を結合に依存していることに注意することが重要です。対応するポート番号が使用中であったが、そのようなアプリケーションが実行された場合、アプリケーションが失敗します。そのため、一時的なポート選択アルゴリズムは、これらのポート番号を使用しないでください。
Port numbers that are currently in use by a TCP in the LISTEN state should not be allowed for use as ephemeral ports. If this rule is not complied with, an attacker could potentially "steal" an incoming connection to a local server application in at least two different ways. Firstly, an attacker could issue a connection request to the victim client at roughly the same time the client tries to connect to the victim server application [CPNI-TCP] [TCP-SEC]. If the SYN segment corresponding to the attacker's connection request and the SYN segment corresponding to the victim client "cross each other in the network", and provided the attacker is able to know or guess the ephemeral port used by the client, a TCP "simultaneous open" scenario would take place, and the incoming connection request sent by the client would be matched with the attacker's socket rather than with the victim server application's socket. Secondly, an attacker could specify a more specific socket than the "victim" socket (e.g., specify both the local IP address and the local TCP port), and thus incoming SYN segments matching the attacker's socket would be delivered to the attacker, rather than to the "victim" socket (see Section 10.1 of [CPNI-TCP]).
LISTEN状態でのTCPによって現在使用されているポート番号は、エフェメラルポートとして使用するために許されるべきではありません。このルールが遵守されていない場合、攻撃者は、少なくとも2つの異なる方法でローカルサーバーアプリケーションへの着信接続を「盗む」ことができます。まず、攻撃者は被害者のクライアントクライアントは、被害者のサーバアプリケーション[CPNI-TCP]、[TCP-SEC]に接続しようとほぼ同時にへの接続要求を発行することができます。 SYNセグメントは、攻撃者の接続要求と被害者のクライアントに対応するSYNセグメントに対応する場合は、「ネットワークで互いに交差」、および提供、攻撃者が知ることができるか、「同時クライアントが使用する一時的なポート、TCPを推測オープン」シナリオが場所を取るだろうし、クライアントから送信された着信接続要求は、攻撃者のソケットではなく、被害者のサーバーアプリケーションのソケットにマッチすることでしょう。第二に、攻撃者は、「被害者」のソケット（例えば、ローカルIPアドレスとローカルのTCPポートの両方を指定する）よりも、特定のソケットを指定することができ、これにより攻撃者のソケットにマッチする、着信SYNセグメントは、攻撃者に配信されるだろう、というより"被害者" ソケット（[CPNI-TCP]のセクション10.1を参照）。
It should be noted that most applications based on popular implementations of the TCP API (such as the Sockets API) perform "passive opens" in three steps. Firstly, the application obtains a file descriptor to be used for inter-process communication (e.g., by issuing a socket() call). Secondly, the application binds the file descriptor to a local TCP port number (e.g., by issuing a bind() call), thus creating a TCP in the fictional CLOSED state. Thirdly, the aforementioned TCP is put in the LISTEN state (e.g., by issuing a listen() call). As a result, with such an implementation of the TCP API, even if port numbers in use for TCPs in the LISTEN state were not allowed for use as ephemeral ports, there is a window of time between the second and the third steps in which an attacker could be allowed to select a port number that would be later used for listening to incoming connections. Therefore, these implementations of the TCP API should enforce a stricter requirement for the allocation of port numbers: port numbers that are in use by a TCP in the LISTEN or CLOSED states should not be allowed for allocation as ephemeral ports [CPNI-TCP] [TCP-SEC].
（ソケットAPIなど）のTCP APIの人気の実装に基づいて、ほとんどのアプリケーションは、三の段階で「受動的に開く」を行うことに留意すべきです。まず、アプリケーション（例えば、ソケット（）コールを発行することにより）プロセス間通信に使用するファイル記述子を取得します。第二に、アプリケーションは、ローカルTCPポート番号にファイル記述子を結合する（例えば、結合（）コールを発行することによって）こうして架空CLOSED状態でTCPを作成。第三に、前述のTCP（例えば、聞く（）の呼び出しを発行することにより）LISTEN状態に置かれています。 LISTEN状態でのTCPのために使用されているポート番号がエフェメラルポートとしての使用のために許可されなかった場合でも結果として、TCPのAPIのような実装で、第二及び第三段階の間の時間の窓があります攻撃者は、後に着信接続を聴くために使用されるポート番号を選択することが許可される可能性があります。したがって、TCPのAPIのこれらの実装は、ポート番号の割り当てのための厳格な要件を適用すべきである：LISTENまたは閉状態におけるTCPによって使用されているポート番号は、エフェメラルポート[CPNI-TCP]として割り当てのために許されるべきではありません[ TCP-SEC]。
The aforementioned issue does not affect SCTP, since most SCTP implementations do not allow a socket to be bound to the same port number unless a specific socket option (SCTP_REUSE_PORT) is issued on the socket (i.e., this behavior needs to be explicitly allowed beforehand). An example of a typical SCTP socket API can be found in [SCTP-SOCKET].
ほとんどのSCTPの実装は、特定のソケットオプション（SCTP_REUSE_PORT）はソケットで発行されていない限り、ソケットが同じポート番号にバインドすることはできませんので、上記の問題は、SCTPには影響しません（つまりは、この動作を明示的に事前に許可する必要があります） 。代表的なSCTPソケットAPIの例は、[SCTPソケット]に見出すことができます。
DCCP is not affected by the exploitation of "simultaneous opens" to "steal" incoming connections, as the server and the client state machines are different [RFC4340]. However, it may be affected by the vector involving binding a more specific socket. As a result, those tuples {local IP address, local port, Service Code} that are in use by a local socket should not be allowed for allocation as ephemeral ports.
DCCPはの搾取に影響されない、サーバーとクライアントの状態マシンが異なる[RFC4340]あるとして、着信接続を「盗む」こと「同時オープンします」。しかし、それはより具体的なソケットをバインド含むベクトルによって影響を受ける可能性があります。結果として、ローカルソケットによって使用されているものタプル{ローカルIPアドレス、ローカルポート、サービスコードは}エフェメラルポートとして割り当てのために許されるべきではありません。
As mentioned in Section 2.1, the dynamic ports consist of the range 49152-65535. However, ephemeral port selection algorithms should use the whole range 1024-65535.
セクション2.1で述べたように、動的ポートは、49152から65535の範囲から成ります。しかし、一時的なポート選択アルゴリズムは、全範囲1024〜65535を使用する必要があります。
This range includes the IANA Registered Ports; thus, some of these port numbers may be needed for providing a particular service at the local host, which could result in the problems discussed in Section 3.1. As a result, port numbers that may be needed for providing a particular service at the local host SHOULD NOT be included in the pool of port numbers available for ephemeral port randomization. If the host does not provide a particular service, the port can be safely allocated to ordinary processes.
この範囲は、IANA登録ポートを含みます。したがって、これらのポート番号の一部は、3.1節で述べた問題が発生する可能性があり、ローカルホスト、で特定のサービスを提供するために必要とすることができます。その結果、ローカルホストで特定のサービスを提供するために必要とされるポート番号は、一時的なポートのランダム化のために使用可能なポート番号のプールに含めるべきではありません。ホストが特定のサービスを提供していない場合、ポートは安全に通常のプロセスに割り当てることができます。
A possible workaround for this potential problem would be to maintain a local list of the port numbers that should not be allocated as ephemeral ports. Thus, before allocating a port number, the ephemeral port selection function would check this list, avoiding the allocation of ports that may be needed for specific applications. Rather than naively excluding all the registered ports, administrators should identify services that may be offered by the local host and SHOULD exclude only the corresponding registered ports.
この潜在的な問題のための可能な回避策は、エフェメラルポートとして割り当てられるべきではないポート番号のローカルリストを維持することです。したがって、ポート番号を割り当てる前に、エフェメラルポート選択機能は、特定の用途のために必要とされるかもしれないポートの割り当てを回避する、このリストをチェックします。むしろ単純に登録されているすべてのポートを除くよりも、管理者はローカルホストによって提供されるのみ対応する登録のポートを除外する必要がサービスを特定すべきです。
Ephemeral port selection algorithms SHOULD use the largest possible port range, since this reduces the chances of an off-path attacker of guessing the selected port numbers.
これは選択されたポート番号を推測するのオフパス攻撃の可能性を減少させるためエフェメラルポート選択アルゴリズムは、最大の可能なポート範囲を使用すべきです。
Ephemeral port selection algorithms SHOULD obfuscate the selection of their ephemeral ports, since this helps to mitigate a number of attacks that depend on the attacker's ability to guess or know the five-tuple that identifies the transport-protocol instance to be attacked.
これが攻撃されるトランスポートプロトコルインスタンスを識別する5タプルを推測か知っている攻撃者の能力に依存した攻撃の数を軽減するのに役立ちますので、エフェメラルポート選択アルゴリズムは、彼らのエフェメラルポートの選択を難読化すべきです。
The following subsections describe a number of algorithms that could be implemented in order to obfuscate the selection of ephemeral port numbers.
以下のサブセクションでは、エフェメラルポート番号の選択を難読化するために実装することができるアルゴリズムの数を記述する。
In order to address the security issues discussed in Sections 1 and 2.2, a number of systems have implemented simple ephemeral port number randomization, as follows:
次のようにセクション1および2.2で説明したセキュリティ問題に対処するために、多くのシステムは、単純なエフェメラルポート番号のランダム化を実装しています。
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count = num_ephemeral;
do { if(check_suitable_port(port)) return next_ephemeral;
{場合（check_suitable_port（ポート））next_ephemeral返すん。
if (next_ephemeral == max_ephemeral) {
next_ephemeral = min_ephemeral;
} else {
next_ephemeral++;
}
count--;
} while (count > 0);
return ERROR;
ERRORを返します。
Algorithm 1
アルゴリズム1
Note: random() is a function that returns a 32-bit pseudo-random unsigned integer number. Note that the output needs to be unpredictable, and typical implementations of POSIX random() function do not necessarily meet this requirement. See [RFC4086] for randomness requirements for security.
注意：ランダム（）は32ビットの擬似ランダム符号なし整数を返す関数です。出力は予測不可能である必要があることに注意してください、そしてPOSIXランダム（）関数の典型的な実装は、必ずしも、この要件を満たしていません。セキュリティのためのランダム性の要件については、[RFC4086]を参照してください。
All the variables (in this and all the algorithms discussed in this document) are unsigned integers.
（これで、この文書で説明するすべてのアルゴリズム）すべての変数は符号なし整数です。
Since the initially chosen port may already be in use with IP addresses and server port that are identical to the ones being used for the socket for which the ephemeral port is to be selected, the resulting five-tuple might not be unique. Therefore, multiple ports may have to be tried and verified against all existing transport-protocol instances before a port can be chosen.
最初に選択されたポートが既にエフェメラルポートが選択されるべきソケットに使用されるものと同一であるIPアドレス及びサーバポートでの使用であってもよいので、結果として得られる5タプルは一意ではないかもしれません。したがって、複数のポートは、ポートが選択される前に試み、すべての既存のトランスポートプロトコルインスタンスと照合しなければならないかもしれません。
Web proxy servers, Network Address Port Translators (NAPTs) [RFC2663], and other middleboxes aggregate multiple peers into the same port space and thus increase the population of used ephemeral ports, and hence the chances of collisions of instance-ids. However, [Allman] has shown that at least in the network scenarios used for measuring the collision properties of the algorithms described in this document, the collision rate resulting from the use of the aforementioned middleboxes is nevertheless very low.
Webプロキシサーバ、ネットワークアドレスポート翻訳（NAPTs）[RFC2663]、および他の中間装置は、同一のポート空間に複数のピアを集約し、従って使用されるエフェメラルポートの人口を増加させ、およびインスタンスIDの衝突従ってチャンス。しかし、[オールマン]は少なくとも、この文書に記載されたアルゴリズムの衝突特性を測定するために使用されるネットワークのシナリオでは、上記中間装置の使用に起因する衝突速度はそれにもかかわらず非常に低いことを示しています。
Since this algorithm performs port selection without taking into account the port numbers previously chosen, it has the potential of reusing port numbers too quickly, thus possibly leading to collisions of instance-ids. Even if a given instance-id is verified to be unique by the port selection algorithm, the instance-id might still be in use at the remote system. In such a scenario, a connection request could possibly fail ([Silbersack] describes this problem for the TCP case).
このアルゴリズムは、ポート番号が以前に選択さを考慮せずに、ポート選択を行うので、おそらくこのように、あまりにも迅速にポート番号を再利用するインスタンスIDの衝突をもたらす可能性を有します。所与のインスタンスIDはポート選択アルゴリズムにより一意であることが確認された場合でも、インスタンスIDは、依然として、リモート・システムでの使用にあるかもしれません。そのようなシナリオでは、接続要求は、おそらく（[Silbersack]はTCPの場合、この問題を記載している）失敗する可能性があります。
However, this algorithm is biased towards the first available port after a sequence of unavailable port numbers. If the local list of registered port numbers that should not be allocated as ephemeral ports (as described in Section 3.2) is significant, an attacker may actually have a significantly better chance of guessing a port number.
しかし、このアルゴリズムは使用できないポート番号のシーケンスの後に最初に使用可能なポートに偏っています。 （3.2節で説明したように）エフェメラルポートとして割り当てられるべきではない登録済みのポート番号のローカルリストが大きい場合、攻撃者は、実際のポート番号を推測するの著しく良好な機会を有することができます。
This algorithm selects ephemeral port numbers randomly and thus reduces the chances that an attacker will guess the ephemeral port selected for a target transport-protocol instance. Additionally, it prevents attackers from obtaining the number of outgoing transport-protocol instances (e.g., TCP connections) established by the client in some period of time.
このアルゴリズムは、ランダムにエフェメラルポート番号を選択し、したがって、攻撃者がターゲットトランスポートプロトコルインスタンスのために選択さエフェメラルポートを推測するであろう可能性を減少させます。また、それは、ある期間内にクライアントによって確立された送信トランスポート・プロトコルのインスタンス（例えば、TCP接続）の数を取得する攻撃者を防ぎます。
The following pseudo-code illustrates another algorithm for selecting a random port number, in which in the event a local instance-id collision is detected, another port number is selected randomly:
次の擬似コードは、イベントにローカルインスタンスIDの衝突が検出され、別のポート番号がランダムに選択されたランダムなポート番号を選択するための別のアルゴリズムを示す図です。
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count = num_ephemeral;
do { if(check_suitable_port(port)) return next_ephemeral;
{場合（check_suitable_port（ポート））next_ephemeral返すん。
next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count--;
} while (count > 0);
return ERROR;
ERRORを返します。
Algorithm 2
アルゴリズム2
When there are a large number of port numbers already in use for the same destination endpoint, this algorithm might be unable (with a very small remaining probability) to select an ephemeral port (i.e., it would return "ERROR"), even if there are still a few port numbers available that would result in unique five-tuples. However, the results in [Allman] have shown that in common scenarios, one port choice is enough, and in most cases where more than one choice is needed, two choices suffice. Therefore, in those scenarios this would not be problem.
同じ宛先エンドポイントのためにすでに使用中のポート番号の数が多い場合には、このアルゴリズムはあっても、（すなわち、それは「ERROR」を返します）一時的なポートを選択する（非常に小さな残りの確率で）できないことがありますがユニークな5タプルにつながる可能ないくつかのポート番号が残っています。ただし、[オールマン]の結果は、一般的なシナリオでは、1つのポート選択は十分にあり、かつ複数の選択が必要とされているほとんどの場合、二つの選択肢が十分であることを示しました。したがって、これらのシナリオでは、これは問題にはならないでしょう。
We would like to achieve the port-reuse properties of the traditional BSD port selection algorithm (described in Section 2.2), while at the same time achieve the unpredictability properties of Algorithm 1 and Algorithm 2.
同時に、アルゴリズム1とアルゴリズム2の予測不可能性を達成しながら、我々は、（セクション2.2を参照）従来のBSDポート選択アルゴリズムのポート再利用特性を達成したいと思います。
Ideally, we would like a "next_ephemeral" value for each set of (local IP address, remote IP addresses, remote port), so that the port-reuse frequency is the lowest possible. Each of these "next_ephemeral" variables should be initialized with random values within the ephemeral port range and, together, these would thus separate the ephemeral port space of the transport-protocol instances on a "per-destination endpoint" basis (this "separation of the ephemeral port space" means that transport-protocol instances with different remote endpoints will not have different sequences of port numbers, i.e., will not be part of the same ephemeral port sequence as in the case of the traditional BSD ephemeral port selection algorithm). Since we do not want to maintain in memory all these "next_ephemeral" values, we propose an offset function F() that can be computed from the local IP address, remote IP address, remote port, and a secret key. F() will yield (practically) different values for each set of arguments, i.e.:
ポートの再利用頻度が最も低い可能なように、理想的には、我々は、（ローカルIPアドレス、リモートIPアドレス、リモートポート）の各セットのための「next_ephemeral」値をしたいと思います。 （この」分離をこれらの「next_ephemeral」変数のそれぞれは、エフェメラルポートの範囲内のランダムな値で初期化されるべきであり、一緒になって、これらは、このように「毎宛先エンドポイント」に基づいて、トランスポートプロトコルインスタンスのエフェメラルポート空間を分離することになりますエフェメラルポート空間」は、異なるリモートエンドポイントとのトランスポートプロトコルのインスタンス）は、すなわち、ポート番号の異なる配列を持っていない伝統的なBSDエフェメラルポート選択アルゴリズムの場合と同様のエフェメラルポートの配列の一部でないことを意味します。私たちは、メモリ内のすべてのこれらの「next_ephemeral」の値を維持したくないので、私たちは、ローカルIPアドレス、リモートIPアドレス、リモートポート、および秘密鍵から計算することができるオフセット関数F（）を提案します。 F（）すなわち、（実質的に）引数のセットごとに異なる値が得られます：
/* Initialization at system boot time. Could be random. */
next_ephemeral = 0;
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
offset = F(local_IP, remote_IP, remote_port, secret_key);
count = num_ephemeral;
do { port = min_ephemeral + (next_ephemeral + offset) % num_ephemeral;
実行{ポート= min_ephemeral +（next_ephemeral +オフセット）％num_ephemeral。
next_ephemeral++;
++ next_ephemeral;
if(check_suitable_port(port)) return port;
（check_suitable_port（ポート））リターンポートであれば、
count--;
カウント - ;
} while (count > 0);
ながら}（> 0のカウント）。
return ERROR;
ERRORを返します。
Algorithm 3
アルゴリズム3
In other words, the function F() provides a "per-destination endpoint" fixed offset within the global ephemeral port range. Both the "offset" and "next_ephemeral" variables may take any value within the storage type range since we are restricting the resulting port in a similar way as in Algorithm 1 (described in Section 3.3.1). This allows us to simply increment the "next_ephemeral" variable and rely on the unsigned integer to wrap around.
換言すれば、関数F（）は、グローバルなエフェメラルポートの範囲内のオフセット固定「ごとの宛先エンドポイント」を提供します。両方の「オフセット」と我々は（セクション3.3.1を参照）アルゴリズム1と同様の方法で得られたポートを制限しているので、「next_ephemeral」変数は、ストレージタイプの範囲内の任意の値をとることができます。これは、私たちは単に「next_ephemeral」変数をインクリメントし、周りにラップする符号なし整数に頼ることができます。
The function F() should be a cryptographic hash function like MD5 [RFC1321]. The function should use both IP addresses, the remote port, and a secret key value to compute the offset. The remote IP address is the primary separator and must be included in the offset calculation. The local IP address and remote port may in some cases be constant and thus not improve the ephemeral port space separation; however, they should also be included in the offset calculation.
関数F（）はMD5 [RFC1321]のような暗号ハッシュ関数であるべきです。この関数はオフセットを計算するために、両方のIPアドレス、リモートポート、および秘密鍵の値を使用する必要があります。リモートIPアドレスは、プライマリセパレータであり、オフセット計算に含まれなければなりません。ローカルIPアドレスとリモート・ポートがある場合には一定であるので、エフェメラルポート空間分離を改善しないかもしれません。しかし、彼らはまた、オフセット計算に含まれるべきです。
Cryptographic algorithms stronger than, e.g., MD5 should not be necessary, given that Algorithm 3 is simply a technique for the obfuscation of the selection of ephemeral ports. The secret should be chosen to be as random as possible (see [RFC4086] for recommendations on choosing secrets).
より強い暗号化アルゴリズムは、例えば、MD5アルゴリズム3は、単にエフェメラルポートの選択を難読化するための技術であることを考えると、必要であってはなりません。秘密は（秘密を選択する上での推奨事項については、[RFC4086]を参照）できるだけランダムに選択する必要があります。
Note that on multiuser systems, the function F() could include user-specific information, thereby providing protection not only on a host-to-host basis, but on a user to service basis. In fact, any identifier of the remote entity could be used, depending on availability and the granularity requested. With SCTP, both hostnames and alternative IP addresses may be included in the association negotiation, and either of these could be used in the offset function F().
これにより、ホスト間基づいが、サービス毎にユーザだけでなく保護を提供し、ユーザ固有の情報を含むことができるマルチユーザシステム、関数F（）にことに留意されたいです。実際には、リモートエンティティの任意の識別子を入手し、要求された粒度に応じて、使用することができます。 SCTPで、ホスト名および代替IPアドレスの両方が結合ネゴシエーションに含まれていてもよい、及びこれらのいずれかは、オフセット関数F（）で使用することができます。
When multiple unique identifiers are available, any of these can be chosen as input to the offset function F() since they all uniquely identify the remote entity. However, in cases like SCTP where the ephemeral port must be unique across all IP address permutations, we should ideally always use the same IP address to get a single starting offset for each association negotiation with a given remote entity to minimize the possibility of collisions. A simple numerical sorting of the IP addresses and always using the numerically lowest could achieve this. However, since most protocols will generally report the same IP addresses in the same order in each association setup, this sorting is most likely not necessary and the "first one" can simply be used.
複数のユニークな識別子が利用可能である場合、それらすべてが一意リモートエンティティを識別するため、これらのいずれかは、オフセット関数F（）への入力として選択することができます。しかし、一時的なポートがすべてのIPアドレスの順列で一意である必要がありますSCTPのようなケースでは、我々は、理想的には常に衝突の可能性を最小限にするために与えられたリモートエンティティと各アソシエーションのネゴシエーションのために単一のオフセットの開始を取得するために、同じIPアドレスを使用する必要があります。数値的に最低を使用して、常にIPアドレスとの簡単な数値ソートはこれを達成することができました。ほとんどのプロトコルは、一般的に各組合のセットアップ中に同じ順序で同じIPアドレスを報告しますので、このソートが最も可能性が高い必要はなく、「最初のものは、」単純に使用することができます。
The ability of hostnames to uniquely define hosts can be discussed, and since SCTP always includes at least one IP address, we recommend using this as input to the offset function F() and ignoring hostname chunks when searching for ephemeral ports.
一意のホストを定義するホスト名の能力を議論することができ、SCTPは、常に少なくとも1つのIPアドレスを含んでいるので、我々は、オフセット関数F（への入力としてこれを使用することをお勧めします）とエフェメラルポートを検索する際にホスト名のチャンクを無視します。
It should be noted that, as this algorithm uses a global counter ("next_ephemeral") for selecting ephemeral ports, if an attacker could, e.g., force a client to periodically establish a new TCP connection to an attacker-controlled machine (or through an attacker-observable path), the attacker could subtract consecutive source port values to obtain the number of outgoing TCP connections established globally by the target host within that time period (up to wrap-around issues and five-tuple collisions, of course).
攻撃者は、例えば、定期的に攻撃者が制御マシン（または貫通への新しいTCP接続を確立するためにクライアントを強制することができれば、このアルゴリズムは、エフェメラルポートを選択するためのグローバルカウンタ（「next_ephemeral」）を使用して、ことに留意すべきです攻撃者が観察可能なパス）、攻撃者がその期間内にターゲットホスト（で世界的に確立された発信TCP接続の数を得るために、連続した送信元ポートの値を引く可能性がラップアラウンドする問題、そしてもちろんの5タプルの衝突、）まで。
A trade-off between maintaining a single global "next_ephemeral" variable and maintaining 2**N "next_ephemeral" variables (where N is the width of the result of F()) could be achieved as follows. The system would keep an array of TABLE_LENGTH short integers, which would provide a separation of the increment of the "next_ephemeral" variable. This improvement could be incorporated into Algorithm 3 as follows:
次のようにトレードオフの単一のグローバル「next_ephemeral」変数を維持し、2 ** N「next_ephemeral」変数維持する間（Nは、Fの結果の幅（））を実現することができます。システムは、「next_ephemeral」変数の増分の分離を提供するTABLE_LENGTH短整数のアレイを維持するであろう。次のようにこの改善は、アルゴリズム3に組み込むことができます。
/* Initialization at system boot time */
for(i = 0; i < TABLE_LENGTH; i++)
table[i] = random() % 65536;
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
offset = F(local_IP, remote_IP, remote_port, secret_key1);
index = G(local_IP, remote_IP, remote_port, secret_key2);
count = num_ephemeral;
do {
port = min_ephemeral + (offset + table[index]) % num_ephemeral;
table[index]++;
if(check_suitable_port(port))
return port;
count--;
カウント - ;
} while (count > 0);
ながら}（> 0のカウント）。
return ERROR;
ERRORを返します。
Algorithm 4
アルゴリズム4
"table[]" could be initialized with mathematically random values, as indicated by the initialization code in pseudo-code above. The function G() should be a cryptographic hash function like MD5 [RFC1321]. It should use both IP addresses, the remote port, and a secret key value to compute a value between 0 and (TABLE_LENGTH-1). Alternatively, G() could take an "offset" as input, and perform the exclusive-or (XOR) operation between all the bytes in "offset".
上記の擬似コードで初期化コードによって示されるように、「テーブル[]」、数学的にランダムな値で初期化することができます。関数G（）は、MD5 [RFC1321]のような暗号ハッシュ関数であるべきです。これは、0と（TABLE_LENGTH-1）の間の値を計算するために、両方のIPアドレス、リモートポート、および秘密鍵の値を使用する必要があります。あるいは、G（）は、入力として「オフセット」および「オフセット」のすべてのバイトの間の排他的論理和（XOR）演算を実行を取ることができます。
The array "table[]" assures that successive transport-protocol instances with the same remote endpoint will use increasing ephemeral port numbers. However, incrementation of the port numbers is separated into TABLE_LENGTH different spaces, and thus the port-reuse frequency will be (probabilistically) lower than that of Algorithm 3. That is, a new transport-protocol instance with some remote endpoint will not necessarily cause the "next_ephemeral" variable corresponding to other endpoints to be incremented.
アレイ「表は、[]」は、同じリモートエンドポイントと連続するトランスポートプロトコルインスタンスがエフェメラルポート番号を増加させることに使用することを保証します。ただし、ポート番号のインクリメントはTABLE_LENGTH異なる空間に分離され、したがって、ポートの再利用周波数（確率）であるアルゴリズム3のそれよりも低く、一部のリモートエンドポイントと新しいトランスポートプロトコルインスタンスは必ずしも引き起こさないであろう他のエンドポイントに対応する「next_ephemeral」変数をインクリメントします。
It is interesting to note that the size of "table[]" does not limit the number of different port sequences, but rather separates the *increments* into TABLE_LENGTH different spaces. The port sequence will result from adding the corresponding entry of "table[]" to the variable "offset", which selects the actual port sequence (as in Algorithm 3). [Allman] has found that a TABLE_LENGTH of 10 can
のサイズ「の表は、[]」は、異なるポート配列の数を限定するものではなく、むしろTABLE_LENGTH異なる空間に*増分を分離することは興味深いです。ポート配列は、対応するエントリを追加することからもたらされる「テーブル[]」（アルゴリズム3のように）実際のポートシーケンスを選択、「オフセット」変数に関する。 【オールマン】人は、10缶のTABLE_LENGTH
result in an improvement over Algorithm 3. Further increasing the TABLE_LENGTH will increase the unpredictability of the resulting port number, and possibly further decrease the collision rate.
アルゴリズム3を超える改善をもたらすまた、得られたポート番号の予測不可能性を増加させ、おそらくさらなる衝突速度を低下させるTABLE_LENGTHを増加させます。
An attacker can perform traffic analysis for any "increment space" into which the attacker has "visibility" -- namely, the attacker can force the client to establish a transport-protocol instance whose G(offset) identifies the target "increment space". However, the attacker's ability to perform traffic analysis is very reduced when compared to the traditional BSD algorithm (described in Section 2.2) and Algorithm 3. Additionally, an implementation can further limit the attacker's ability to perform traffic analysis by further separating the increment space (that is, using a larger value for TABLE_LENGTH).
つまり、攻撃者はそのG（オフセット）標的「インクリメント空間」を特定トランスポートプロトコルインスタンスを確立するためにクライアントを強制することができ - 攻撃者は、攻撃者が「可視性」を有するその中に任意の「増分空間」のトラフィック分析を行うことができます。そしてさらに、アルゴリズム3（2.2節を参照）従来のBSDアルゴリズムと比較した場合しかし、トラフィック分析を実行する攻撃者の能力が非常に低減され、さらに（さらに増分空間を分離することにより、トラフィック分析を実行する攻撃者の能力を制限することができ実装それは）TABLE_LENGTHためのより大きな値を使用して、です。
[Allman] introduced another port selection algorithm, which offers a middle ground between the algorithms that select ephemeral ports independently at random (such as those described in Sections 3.3.1 and 3.3.2), and those that offer obfuscation with less randomization (such as those described in Sections 3.3.3 and 3.3.4).
【オールマンは、（例えばセクション3.3.1および3.3.2に記載されているもののように）独立してランダムにエフェメラルポートを選択アルゴリズム間で妥協点を提供する別のポート選択アルゴリズムを導入し、より少ないランダムで難読化を提供するもの（例えばセクション3.3.3と3.3.4）に記載されているものなど。
/* Initialization code at system boot time. */
next_ephemeral = random() % 65536; /* Initialization value */
N = 500; /* Determines the trade-off */
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
count = num_ephemeral;
num_ephemeral =数えます。
do {
next_ephemeral = next_ephemeral + (random() % N) + 1;
port = min_ephemeral + (next_ephemeral % num_ephemeral);
if(check_suitable_port(port))
return port;
count--;
} while (count > 0);
return ERROR;
ERRORを返します。
Algorithm 5
アルゴリズム5
This algorithm aims at producing a monotonically increasing sequence to prevent the collision of instance-ids, while avoiding the use of fixed increments, which would lead to trivially predictable sequences. The value "N" allows for direct control of the trade-off between the level of unpredictability and the port-reuse frequency. The smaller the value of "N", the more similar this algorithm is to the traditional BSD port selection algorithm (described in Section 2.2). The larger the value of "N", the more similar this algorithm is to the algorithm described in Section 3.3.1 of this document.
このアルゴリズムは自明予測可能シーケンスにつながる固定インクリメントの使用を回避しながら、インスタンスIDの衝突を防止するために単調に増加するシーケンスを生成することを目的とします。値「N」は、予測不可能性のレベルとポートの再利用周波数との間のトレードオフを直接制御することができます。 「N」の値が小さいほど、より類似このアルゴリズムは、（セクション2.2を参照）従来のBSDポート選択アルゴリズムです。 「N」の値が大きいほど、より多くの同様の、このアルゴリズムは、この文書のセクション3.3.1で説明したアルゴリズムです。
When the port numbers wrap, there is the risk of collisions of instance-ids. Therefore, "N" should be selected according to the following criteria:
ポート番号がラップすると、インスタンスIDの衝突の危険性があります。したがって、「N」は、以下の基準に従って選択されるべきです。
o It should maximize the wrapping time of the ephemeral port space.
Oそれは一時ポート空間のラッピング時間を最大化すべきです。
o It should minimize collisions of instance-ids.
Oそれは、インスタンスIDの衝突を最小限に抑える必要があります。
o It should maximize the unpredictability of selected port numbers.
Oこれは、選択したポート番号の予測不可能性を最大化すべきです。
Clearly, these are competing goals, and the decision of which value of "N" to use is a trade-off. Therefore, the value of "N" should be configurable so that system administrators can make the trade-off for themselves.
明らかに、これらは相反する目標であり、使用する「N」の値の決定はトレードオフです。システム管理者は、自分自身のためのトレードオフを行うことができるように、したがって、「N」の値が設定可能でなければなりません。
Every complex manipulation (like MD5) is no more secure than the input values, and in the case of ephemeral ports, 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 (e.g., ephemeral ports chosen by the victim), the attacker may simply search the entire secret-key space to find matches.
（MD5のような）すべての複雑な操作は一切より安全な入力値よりも、およびエフェメラルポートの場合、秘密鍵ではありません。攻撃者は（私たちが期待するべき）被害者によって使用されている、および攻撃者が十分な材料を得ることができ、暗号化されたハッシュ関数を認識している場合（例えば、被害者が選択したエフェメラルポート）は、攻撃者は単に全体secret-を検索することができマッチを見つけるための鍵空間。
To protect against this, the secret key should be of a reasonable length. Key lengths of 128 bits should be adequate.
これを防ぐために、秘密鍵は、合理的な長さであるべきです。 128ビットの鍵長さは適切でなければなりません。
Another possible mechanism for protecting the secret key is to change it after some time. If the host platform is capable of producing reasonably good random data, the secret key can be changed automatically.
秘密鍵を保護するための別の可能なメカニズムは、いくつかの時間後にそれを変更することです。ホストプラットフォームは、適度に良好なランダムデータを生成することが可能である場合には、秘密鍵を自動的に変更することができます。
Changing the secret will cause abrupt shifts in the chosen ephemeral ports, and consequently collisions may occur. That is, upon changing the secret, the "offset" value (see Sections 3.3.3 and 3.3.4) used
秘密を変更すると、選択したエフェメラルポートの急激なシフトを引き起こします、その結果、衝突が発生する可能性があります。それは使用される秘密を変更すると、「オフセット」値は（セクション3.3.3と3.3.4を参照）であり、
for each destination endpoint will be different from that computed with the previous secret, thus leading to the selection of a port number recently used for connecting to the same endpoint.
各宛先エンドポイントのためにこのように、最近、同じエンドポイントへの接続に使用するポート番号の選択をもたらす、以前秘密で計算とは異なるであろう。
Thus, the change in secret key should be done with consideration and could be performed whenever one of the following events occur:
このように、秘密鍵の変化を考慮して行わなければならないし、次のいずれかのイベントが発生するたびに実行することができます。
o The system is being bootstrapped.
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 now.
O秘密鍵は、それが今、安全でないと見なされるべきであることを十分に頻繁に使用されてきました。
o There are few active transport-protocol instances (i.e., possibility of a collision is low).
O数アクティブトランスポートプロトコルインスタンス（すなわち、衝突の可能性が低い）があります。
o System load is low (i.e., the performance overhead of local collisions is tolerated).
Oシステム負荷が低い（すなわち、ローカル衝突の性能オーバーヘッドが許容されています）。
o There is enough random data available to change the secret key (pseudo-random changes should not be done).
O秘密鍵（擬似ランダム変更は行うべきではありません）を変更するために利用できる十分なランダムなデータがあります。
[Allman] is an empirical study of the properties of the algorithms described in this document, which has found that all the algorithms described in this document offer low collision rates -- at most 0.3%. That is, in those network scenarios assessed by [Allman], all of the algorithms described in this document perform well in terms of collisions of instance-ids. However, these results may vary depending on the characteristics of network traffic and the specific network setup.
ほとんどの0.3％に - [オールマンは、この文書に記載されているすべてのアルゴリズムは、低衝突率を提供することを発見したこの文書で説明したアルゴリズムの性質の実証的研究です。すなわち、この文書に記載されたアルゴリズムのすべては、インスタンスIDの衝突の点で良好に機能する、[オールマン]によって評価し、それらのネットワークのシナリオでは、あります。しかしながら、これらの結果は、ネットワークトラフィック及び特定のネットワーク設定の特性に応じて変えることができます。
The algorithm described in Section 2.2 is the traditional ephemeral port selection algorithm implemented in BSD-derived systems. It generates a global sequence of ephemeral port numbers, which makes it trivial for an attacker to predict the port number that will be used for a future transport protocol instance. However, it is very simple and leads to a low port-reuse frequency.
セクション2.2で説明されたアルゴリズムは、BSD由来のシステムで実装さ伝統的なエフェメラルポート選択アルゴリズムです。それは些細な攻撃者が、将来のトランスポートプロトコルインスタンスのために使用されるポート番号を予測することができるエフェメラルポート番号のグローバル・シーケンスを生成します。しかし、それは非常に簡単で、低ポート・再利用頻度につながります。
Algorithm 1 and Algorithm 2 have the advantage that they provide actual randomization of the ephemeral ports. However, they may increase the chances of port number collisions, which could lead to the failure of a connection establishment attempt. [Allman] found that these two algorithms show the largest collision rates (among all the algorithms described in this document).
アルゴリズム1とアルゴリズム2は、それらがエフェメラルポートの実際のランダム化を提供するという利点を有します。しかし、彼らは、接続確立の試みの失敗につながる可能性があるポート番号の衝突の可能性を高めることがあります。 【オールマンは、これら2つのアルゴリズム（この文書に記載されているすべてのアルゴリズムの中で）最大衝突速度を示すことを見出しました。
Algorithm 3 provides complete separation in local and remote IP addresses and remote port space, and only limited separation in other dimensions (see Section 3.4). However, implementations should consider the performance impact of computing the cryptographic hash used for the offset.
アルゴリズム3は、（3.4節を参照）は、ローカルとリモートのIPアドレスとリモートポート空間で完全に分離し、他の次元でのみ制限された分離を提供します。しかし、実装は、オフセットのために使用される暗号ハッシュを計算のパフォーマンスへの影響を考慮すべきです。
Algorithm 4 improves Algorithm 3, usually leading to a lower port-reuse frequency, at the expense of more processor cycles used for computing G(), and additional kernel memory for storing the array "table[]".
アルゴリズム4は、配列「テーブル[]」を格納するためのGを計算するために使用される複数のプロセッサ・サイクル（）、及び追加のカーネルメモリを犠牲にし、通常より低いポート再利用周波数につながる、アルゴリズム3を向上させることができます。
Algorithm 5 offers middle ground between the simple randomization algorithms (Algorithm 1 and Algorithm 2) and the hash-based algorithms (Algorithm 3 and Algorithm 4). The upper limit on the random increments (the value "N" in the pseudo-code included in Section 3.3.5) controls the trade-off between randomization and port-reuse frequency.
アルゴリズム5は、単純なランダムアルゴリズム（アルゴリズム1とアルゴリズム2）とハッシュベースのアルゴリズム（アルゴリズム3およびアルゴリズム4）との間で妥協点を提供します。ランダムインクリメントの上限（セクション3.3.5に含まれる擬似コードの値「N」）はトレードオフのランダム化およびポートの再使用周波数とを制御します。
Finally, a special case that may preclude the utilization of Algorithm 3 and Algorithm 4 should be analyzed. There exist some applications that contain the following code sequence:
最後に、アルゴリズム3およびアルゴリズム4の利用を排除することができる特殊なケースは、分析されるべきです。次のコード配列を含むいくつかのアプリケーションが存在します：
s = socket();
bind(s, IP_address, port = *);
In some BSD-derived systems, the call to bind() will result in the selection of an ephemeral port number. However, as neither the remote IP address nor the remote port will be available to the ephemeral port selection function, the hash function F() used in Algorithm 3 and Algorithm 4 will not have all the required arguments, and thus the result of the hash function will be impossible to compute. Transport protocols implementing Algorithm 3 or Algorithm 4 should consider using Algorithm 2 when facing the scenario just described.
いくつかのBSD由来のシステムでは、呼が結合すること（）エフェメラルポート番号の選択をもたらすであろう。リモートIPアドレスやリモートポートのいずれもエフェメラルポート選択機能に使用できるようになりますしかし、アルゴリズム3およびアルゴリズム4で使用されるハッシュ関数F（）は、必要なすべての引数を有し、したがって、ハッシュの結果ではないであろう関数は、計算することができなくなります。アルゴリズム3またはアルゴリズム4を実装するトランスポートプロトコルは、今説明したシナリオに直面したときにアルゴリズム2を使用することを検討すべきです。
An alternative to this behavior would be to implement "lazy binding" in response to the bind() call. That is, selection of an ephemeral port would be delayed until, e.g., connect() or send() are called. Thus, at that point the ephemeral port is actually selected, all the necessary arguments for the hash function F() are available, and therefore Algorithm 3 and Algorithm 4 could still be used in this scenario. This algorithm has been implemented by Linux [Linux].
この動作の代わりに、バインド（）の呼び出しに応じて、「遅延結合」を実装することです。すなわち、エフェメラルポートの選択がされるまで遅延されるであろう、ある例えば、（接続）または（送信）と呼ばれます。その時点でエフェメラルポートが実際に選択されているこのように、ハッシュ関数F（）のために必要なすべての引数が使用可能であり、したがって、アルゴリズム3およびアルゴリズム4は、まだこのシナリオで使用することができます。このアルゴリズムは、Linux [Linuxの]によって実装されています。
Network Address Port Translation (NAPT) translates both the network address and transport-protocol port number, thus allowing the transport identifiers of a number of private hosts to be multiplexed into the transport identifiers of a single external address [RFC2663].
ネットワークアドレスポート変換（NAPT）は、したがって、プライベートホストの数のトランスポート識別子は、単一の外部アドレス[RFC2663]のトランスポート識別子に多重化されることを可能にする、ネットワークアドレス及びトランスポートプロトコルのポート番号の両方を変換します。
In those scenarios in which a NAPT is present between the two endpoints of a transport-protocol instance, the obfuscation of the ephemeral port selection (from the point of view of the external network) will depend on the ephemeral port selection function at the NAPT. Therefore, NAPTs should consider obfuscating the selection of ephemeral ports by means of any of the algorithms discussed in this document.
NAPTは、トランスポートプロトコルのインスタンスの2つのエンドポイントの間で存在するこれらのシナリオでは、（外部ネットワークの観点から）エフェメラルポート選択の難読化は、NAPTでエフェメラルポート選択機能に依存するであろう。したがって、NAPTsは、本書で説明したアルゴリズムのいずれかによって、エフェメラルポートの選択を難読化を検討すべきです。
A NAPT that does not implement port preservation [RFC4787] [RFC5382] SHOULD obfuscate selection of the ephemeral port of a packet when it is changed during translation of that packet.
それは、そのパケットの翻訳中に変更された場合に、ポート維持[RFC4787]、[RFC5382]を実装していないNAPTは、パケットのエフェメラルポートの選択を難読化すべきです。
A NAPT that does implement port preservation SHOULD obfuscate the ephemeral port of a packet only if the port must be changed as a result of the port being already in use for some other session.
ポート保存を実装しないNAPTは、ポートが他のセッションのためにすでに使用されているポートの結果として変更しなければならない場合にのみ、パケットの一時的なポートを難読化すべきです。
A NAPT that performs parity preservation and that must change the ephemeral port during translation of a packet SHOULD obfuscate the ephemeral ports. The algorithms described in this document could be easily adapted such that the parity is preserved (i.e., force the lowest order bit of the resulting port number to 0 or 1 according to whether even or odd parity is desired).
パリティ保存を実行し、そのパケットの翻訳中に一時的なポートを変更する必要がありますNAPTは、エフェメラルポートを難読化すべきです。この文書に記載されたアルゴリズムを簡単パリティ（即ち、偶数または奇数パリティが望まれるかどうかに応じて0または1に、得られたポート番号の最下位ビットを強制的に）保存されるように適合させることができます。
Some applications allocate contiguous ports and expect to see contiguous ports in use at their peers. Clearly, this expectation might be difficult to accommodate at a NAPT, since some port numbers might already be in use by other sessions, and thus an alternative port might need to be selected, thus resulting in a non-contiguous port number sequence (see Section 4.2.3 of [RFC4787]). A NAPT that implements a simple port randomization algorithm (such as Algorithm 1, Algorithm 2, or Algorithm 5) is likely to break this assumption, even if the endpoint selecting an ephemeral port does select ephemeral ports that are contiguous. However, since a number of different ephemeral port selection algorithms have been implemented by deployed NAPTs, any application that relies on any specific ephemeral port selection algorithm at the NAPT is likely to suffer interoperability problems when a NAPT is present between the two endpoints of a transport-protocol instance. Nevertheless, some of the algorithms described in this document (namely Algorithm 3 and Algorithm 4) select consecutive ephemeral ports such that they are contiguous (except when one of the port numbers needed to produce a contiguous sequence is already in use by some other NAPT session). Therefore, a NAPT willing to produce sequences of contiguous port numbers should consider implementing Algorithm 3 or Algorithm 4 of this document. Section 3.5 provides further guidance in choosing a port selection algorithm.
一部のアプリケーションでは、隣接するポートを割り当て、仲間で使用中の隣接するポートを見ることを期待します。明らかに、この期待は、いくつかのポート番号が既に他のセッションで使用中であるかもしれないので、別のポートは、このように非連続ポート番号の配列が得られ、選択される必要があるかもしれないので、NAPTに対応することは困難かもしれない（セクションを参照[RFC4787]の4.2.3）。 （このようなアルゴリズム1、アルゴリズム2、アルゴリズム又は5のような）単純なポートのランダム化アルゴリズムを実装NAPTは、エフェメラルポートを選択し、エンドポイントが連続しているエフェメラルポートを選択しない場合でも、この仮定を破る可能性があります。異なるエフェメラルポート選択アルゴリズムの数が展開NAPTsによって実現されているので、NAPTで特定のエフェメラルポート選択アルゴリズムに依存して任意のアプリケーションは、NAPTは、輸送の2つのエンドポイント間に存在するときに相互運用性の問題を被る可能性があります-protocolインスタンス。それにもかかわらず、このドキュメント（すなわちアルゴリズム3およびアルゴリズム4）に記載のアルゴリズムのいくつかは、それらが連続するシーケンスを生成するために必要なポート番号の1つが他のNAPTセッションによって既に使用されている場合を除いて（連続しているように、連続エフェメラルポートを選択します）。したがって、連続したポート番号のシーケンスを生成するために喜んNAPTは、アルゴリズム3、またはこの文書のアルゴリズム4の実装を検討すべきです。 3.5節では、ポート選択アルゴリズムを選択する際に更なるガイダンスを提供します。
It should be noted that in some network scenarios, a NAPT may naturally obscure ephemeral port selections simply due to the vast range of services with which it establishes connections and to the overall rate of the traffic [Allman].
なお、いくつかのネットワークシナリオにおいて、NAPTよい単に起因し、それは接続を確立するとサービスの広大な範囲に及びトラフィック[オールマン]の全体的な速度に自然に不明瞭エフェメラルポートの選択。
Obfuscating the ephemeral port selection is no replacement for cryptographic mechanisms, such as IPsec [RFC4301], in terms of protecting transport-protocol instances against blind attacks.
エフェメラルポートの選択を難読化すると、ブラインド攻撃からトランスポートプロトコルインスタンスを保護する点でIPsecなどの暗号メカニズムのための置換[RFC4301]、ではありません。
An eavesdropper that can monitor the packets that correspond to the transport-protocol instance to be attacked could learn the IP addresses and port numbers in use (and also sequence numbers, etc.) and easily perform an attack. Obfuscation of the ephemeral port selection does not provide any additional protection against this kind of attack. In such situations, proper authentication mechanisms such as those described in [RFC4301] should be used.
（また、シーケンス番号、等）のIPアドレスとポート番号の使用中を学び、簡単な攻撃を行う可能性が攻撃されるトランスポートプロトコルのインスタンスに対応するパケットを監視することができる盗聴者。一時ポート選択の難読化は、この種の攻撃に対する追加の保護を提供しません。そのような状況では、このような[RFC4301]に記載されているような適切な認証機構が使用されるべきです。
This specification recommends including the whole range 1024-65535 for the selection of ephemeral ports, and suggests that an implementation maintains a list of those port numbers that should not be made available for ephemeral port selection. If the list of port numbers that are not available is significant, Algorithm 1 may be highly biased and generate predictable ports, as noted in Section 3.3.1. In particular, if the list of IANA Registered Ports is accepted as the local list of port numbers that should not be made available, certain ports may result with 500 times the probability of other ports. Systems that support numerous applications resulting in large lists of unavailable ports, or that use the IANA Registered Ports without modification, MUST NOT use Algorithm 1.
この仕様は、エフェメラルポートの選択のための全範囲1024〜65535を含むお勧めします、そして実装はエフェメラルポート選択のために利用可能にされるべきではないそれらのポート番号のリストを維持することを示唆しています。利用可能でないポート番号のリストが大きい場合、アルゴリズム1は、セクション3.3.1で述べたように、高度にバイアスされかつ予測可能なポートを生成してもよいです。 IANAに登録ポートのリストが利用可能にされるべきではないポート番号のローカルリストとして受け入れられた場合、特に、特定のポートが他のポートの500倍の確率で生じ得ます。使用できないポートの大きなリストにその結果、多数のアプリケーションをサポートするシステム、またはそれは修正なしでIANA登録ポートを使用するには、アルゴリズム1を使用してはなりません。
If the local offset function F() (in Algorithm 3 and Algorithm 4) results in identical offsets for different inputs at greater frequency than would be expected by chance, the port-offset mechanism proposed in this document would have a reduced effect.
場合、ローカルオフセット関数F（）（アルゴリズム3およびアルゴリズム4）偶然によって予想されるよりも高い頻度で異なる入力に対して同じオフセットをもたらす、本文書で提案されているポート・オフセット機構は、低減効果を有するであろう。
If random numbers are used as the only source of the secret key, they should be chosen in accordance with the recommendations given in [RFC4086].
乱数が秘密鍵の唯一のソースとして使用されている場合、それらは[RFC4086]で与えられた勧告に応じて選択する必要があります。
If an attacker uses dynamically assigned IP addresses, the current ephemeral port offset (Algorithm 3 and Algorithm 4) for a given five-tuple can be sampled and subsequently used to attack an innocent peer reusing this address. However, this is only possible until a re-keying happens as described above. Also, since ephemeral ports are only used on the client side (e.g., the one initiating the transport-protocol communication), both the attacker and the new peer need to act as servers in the scenario just described. While servers using dynamic IP addresses exist, they are not very common, and with an appropriate re-keying mechanism the effect of this attack is limited.
攻撃者が動的にIPアドレスを割り当てられて使用されている場合、与えられた5タプルのためのオフセット電流エフェメラルポート（アルゴリズム3およびアルゴリズム4）をサンプリングし、その後、このアドレスを再利用無実のピアを攻撃するために使用することができます。しかしながら、これは、上記のように再入力が発生するまでにのみ可能です。また、エフェメラルポートのためにのみ、攻撃者とだけ説明したシナリオでは、サーバとして機能する新しいピア必要性の両方（例えば、トランスポートプロトコルの通信を開始するもの）クライアント側で使用されています。動的IPアドレスを使用してサーバが存在するが、彼らは非常に一般的ではない、と適切な再キーイング機構がこの攻撃の影響は限られています。
The offset function used in Algorithm 3 and Algorithm 4 was inspired by the mechanism proposed by Steven Bellovin in [RFC1948] for defending against TCP sequence number attacks.
アルゴリズム3およびアルゴリズム4で使用されるオフセット関数は、TCPシーケンス番号攻撃から防御するために[RFC1948]でスティーブンBellovin氏によって提案されたメカニズムに触発されました。
The authors would like to thank (in alphabetical order) Mark Allman, Jari Arkko, Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter, Vincent Deffontaines, Ralph Droms, Lars Eggert, Pasi Eronen, Gorry Fairhurst, Adrian Farrel, Guillermo Gont, David Harrington, Alfred Hoenes, Avshalom Houri, Charlie Kaufman, Amit Klein, Subramanian Moonesamy, Carlos Pignataro, Tim Polk, Kacheong Poon, Pasi Sarolahti, Robert Sparks, Randall Stewart, Joe Touch, Michael Tuexen, Magnus Westerlund, and Dan Wing for their valuable feedback on draft versions of this document.
著者は、（アルファベット順）マーク・オールマン、ヤリArkko、マティアスBethke、ステファンBortzmeyer、ブライアン・カーペンター、ヴィンセントDeffontaines、ラルフDroms、ラースEggertの、パシEronen、Gorry Fairhurst、エードリアンファレル、ギジェルモGont、デヴィッド・ハリントンを、感謝したいと思いますアルフレッドHoenes、上の貴重なフィードバックのためのAvshalomフーリー、チャーリー・カウフマン、アミット・クライン、サブラマニアンMoonesamy、カルロスPignataro、ティムポーク、Kacheongプーン、パシSarolahti、ロバート・スパークス、ランドール・スチュワート、ジョー・タッチ、マイケルTuexen、マグヌスウェスター、そしてダン・ウイングこの文書の草案。
The authors would like to thank Alfred Hoenes for his admirable effort in improving the quality of this document.
作者はこのドキュメントの品質を向上させることで、彼の立派な努力のためのアルフレッドHoenesに感謝したいと思います。
The authors would like to thank FreeBSD's Mike Silbersack for a very fruitful discussion about ephemeral port selection techniques.
著者は、一時的なポート選択技術について非常に実りある議論のためのFreeBSDのマイクSilbersackに感謝したいと思います。
Fernando Gont's attendance to IETF meetings was supported by ISOC's "Fellowship to the IETF" program.
IETFミーティングにフェルナンドGontの出席は、ISOCのプログラム「フェローシップIETFへ」によってサポートされていました。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、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月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3605]のHuitema、C.、 "リアルタイム制御プロトコル（RTCP）セッション記述プロトコル（SDP）内の属性"、RFC 3605、2003年10月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828] Larzon、L-A。、Degermark、M.、ピンク、S.、ヨンソン、L-E。、およびG. Fairhurst、 "軽量ユーザーデータグラムプロトコル（UDP-Liteの）"、RFC 3828、2004年7月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.とC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]グハ、S.、ビスワス、K.、フォード、B.、シバクマー、S.、およびP. Srisuresh、 "TCPのためのNAT行動要件"、BCP 142、RFC 5382、2008年10月。
[Allman] Allman, M., "Comments On Selecting Ephemeral Ports", ACM Computer Communication Review, 39(2), 2009.
[オールマン]オールマン、M.、 "エフェメラルポートの選択に関するコメント"、ACMコンピュータコミュニケーションレビュー、39（2）、2009。
[CPNI-TCP] Gont, F., "CPNI Technical Note 3/2009: Security Assessment of the Transmission Control Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/ tn-03-09-security-assessment-TCP.pdf>.
[CPNI-TCP] Gont、F.、 "CPNIテクニカルノート2009分の3：伝送制御プロトコル（TCP）のセキュリティ評価"、2009年、<http://www.cpni.gov.uk/Docs/ TN-03 -09-セキュリティ・アセスメント・TCP.pdf>。
[FreeBSD] The FreeBSD Project, <http://www.freebsd.org>.
[FreeBSDの] FreeBSDプロジェクト、<http://www.freebsd.org>。
[IANA] "IANA Port Numbers", <http://www.iana.org/assignments/port-numbers>.
[IANA] "IANAポート番号"、<http://www.iana.org/assignments/port-numbers>。
[Linux] The Linux Project, <http://www.kernel.org>.
[Linuxの] Linuxプロジェクト、<http://www.kernel.org>。
[NetBSD] The NetBSD Project, <http://www.netbsd.org>.
[NetBSDの] NetBSDプロジェクト、<http://www.netbsd.org>。
[OpenBSD] The OpenBSD Project, <http://www.openbsd.org>.
[OpenBSDの]のOpenBSDプロジェクト、<http://www.openbsd.org>。
[OpenSolaris] OpenSolaris, <http://www.opensolaris.org>.
【のOpenSolaris] OpenSolarisの、<http://www.opensolaris.org>。
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.
"TCPでのTIME-WAITの暗殺の危険" [RFC1337]ブレーデン、B.、RFC 1337、1992年5月。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948] Bellovin氏、S.、 "シーケンス番号攻撃からの保護"、RFC 1948、1996年5月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953]タッチ、J.、RFC 4953、2007年7月 "なりすまし攻撃に対するTCPを防衛"。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]をタッチし、J.、マンキン、A.、およびR. Bonica、 "TCP認証オプション"、RFC 5925、2010年6月。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5927] Gont、F.、 "TCPに対するICMP攻撃"、RFC 5927、2010年7月。
[SCTP-SOCKET] Stewart, R., Poon, K., Tuexen, M., Lei, P., and V. Yasevich, V., "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Work in Progress, January 2011.
[SCTPソケット]スチュワート、R.、プーン、K.、Tuexen、M.、レイ、P.、およびV. Yasevich、V.、進行中の作業 "ストリーム制御伝送プロトコル（SCTP）のためのソケットAPIの拡張機能" 、2011年1月。
[Silbersack] Silbersack, M., "Improving TCP/IP security through randomization without sacrificing interoperability", EuroBSDCon 2005 Conference.
[Silbersack] Silbersack、M.、 "相互運用性を犠牲にすることなく、ランダム化を通じてTCP / IPは、セキュリティの改善"、EuroBSDCon 2005会議。
[Stevens] Stevens, W., "Unix Network Programming, Volume 1: Networking APIs: Socket and XTI", Prentice Hall, 1998.
[スティーブンス]スティーブンス、W.、 "UNIXネットワークプログラミング第1巻：ネットワークAPI：ソケットとXTI"、プレンティス・ホール、1998。
[TCP-SEC] Gont, F., "Security Assessment of the Transmission Control Protocol (TCP)", Work in Progress, February 2010.
[TCP-SEC] Gont、F.、進歩、2010年2月の作業 "伝送制御プロトコル（TCP）のセキュリティ評価"。
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", CanSecWest 2004 Conference.
[ワトソン]ワトソン、P.、 "ウィンドウに滑り：TCPリセット攻撃"、たCanSecWest 2004会議が。
Appendix A. Survey of the Algorithms in Use by Some Popular Implementations
いくつかの人気の実装で使用されているアルゴリズムの付録A.調査
A.1. FreeBSD
A.1。 FreeBSDの
FreeBSD 8.0 implements Algorithm 1, and in response to this document now uses a "min_port" of 10000 and a "max_port" of 65535 [FreeBSD].
FreeBSDの8.0は、アルゴリズム1を実装、および本文書に対応して、今10000の「min_port」と[FreeBSDの] 65535の「MAX_PORT」を使用しています。
A.2. Linux
あ。２。 ぃぬｘ
Linux 2.6.15-53-386 implements Algorithm 3, with MD5 as the hash algorithm. If the algorithm is faced with the corner-case scenario described in Section 3.5, Algorithm 1 is used instead [Linux].
Linuxの2.6.15-53-386は、ハッシュアルゴリズムとしてMD5とアルゴリズム3を実装します。アルゴリズムは、セクション3.5に記載のコーナーケースのシナリオに直面している場合、アルゴリズム1の代わりに[Linuxの]使用されています。
A.3. NetBSD
A.3。 NetBSDの
NetBSD 5.0.1 does not obfuscate its ephemeral port numbers. It selects ephemeral port numbers from the range 49152-65535, starting from port 65535, and decreasing the port number for each ephemeral port number selected [NetBSD].
NetBSDの5.0.1は、その一時的なポート番号を難読化しません。これは、ポート65535から開始し、49152〜65535の範囲からエフェメラルポート番号を選択し、[NetBSDの】選択された各エフェメラルポート番号のポート数を減少させます。
A.4. OpenBSD
A.4。 OpenBSDの
OpenBSD 4.2 implements Algorithm 1, with a "min_port" of 1024 and a "max_port" of 49151. [OpenBSD]
OpenBSDの4.2 1024の「min_port」と49151の「MAX_PORT」とアルゴリズム1を実装[OpenBSDの】
A.5. OpenSolaris
A.5。 OpenSolarisの
OpenSolaris 2009.06 implements Algorithm 1, with a "min_port" of 32768 and a "max_port" of 65535 [OpenSolaris].
OpenSolarisの2009.06は[OpenSolarisの】32768の "min_port" と65535の "MAX_PORT" と、アルゴリズム1を実装します。
Authors' Addresses
著者のアドレス
Michael Vittrup Larsen Tieto Skanderborgvej 232 Aarhus DK-8260 Denmark
マイケルVittrupラーセンTieto Skanderborgvej 232オーフスDK-8260デンマーク
Phone: +45 8938 5100 EMail: michael.larsen@tieto.com
電話：+45 8938 5100 Eメール：michael.larsen@tieto.com
Fernando Gont Universidad Tecnologica Nacional / Facultad Regional Haedo Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
フェルナンドGont大学Tecnologicaナシオナル/ Facultad地域Haedoエバリスト・キャリエゴ2644 Haedo、1706ブエノスアイレス州アルゼンチン
Phone: +54 11 4650 8472 EMail: fernando@gont.com.ar
電話：+54 11 4650 8472 Eメール：fernando@gont.com.ar