[要約] RFC 6056は、トランスポートプロトコルのポートのランダム化に関する推奨事項を提供しています。その目的は、ネットワークセキュリティを向上させ、ポートスキャンや攻撃からの保護を強化することです。
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）など、それらの恩恵を受ける可能性のある輸送プロトコルの仕様に違反しないローカルポリシーです。、Datagramの混雑制御プロトコル（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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アドレスとポート番号は通常、クライアントアプリケーションによって不特定のままにされているため、クライアントネットワークスタックによって自動的に選択されます。ネットワーキングスタックによって自動的に選択されたポートは、短命ポート[Stevens]として知られています。
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}).
このドキュメント全体を通して、「トランスポートプロトコルインスタンス」という用語を一般用語として使用して、トランスポートプロトコルのインスタンス化（接続指向の輸送プロトコルの場合の「接続」と「インスタンス」という用語を参照します。-id "トランスポートプロトコルインスタンスを識別する値のグループを参照する短いハンドルとして（たとえば、TCPの場合、5タプル{プロトコル、IPソースアドレス、TCPソースポート、IP宛先アドレス、IP宛先アドレス、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）は、よく知られているポート[IANA]を含むインターネットエンジニアリングタスクフォース（IETF）が開発したプロトコルで使用される一意のパラメーターと値を割り当てます。IANAは、TCPとUDPの16ビットポート範囲の以下の使用を予約しています。
o The Well-Known Ports, 0 through 1023.
o よく知られているポート、0〜1023。
o The Registered Ports, 1024 through 49151
o 登録ポート、1024〜49151
o The Dynamic and/or Private Ports, 49152 through 65535
o ダイナミックおよび/またはプライベートポート、49152〜65535
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:
一意のインスタンスID（5タプル）を引き起こすように、短命ポートの選択は、以前に選択されたはかないポート1、つまり選択プロセスの選択プロセスに等しいプロトコルごとのグローバルな「next_ephemeral」変数を持つことにより、いくつかの実装によって処理されます。は：
/* 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;
if（check_suitable_port（port））返品ポート;
count--;
カウント - ;
} while (count > 0);
return 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.
このアルゴリズムは、一時的なポート範囲を使い果たすのにかかるよりも長い寿命がある輸送プロトコルインスタンスの数（各輸送プロトコル）の数が少ないため、Instance-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接続（または攻撃者に夢中になるパスを介して）、攻撃者は連続したソースポート値を差し引くことができます。その期間内にターゲットホストによってグローバルに確立された接続（もちろん、ラップアラウンドの問題と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.
一時的なポート選択アルゴリズムが、選択したポート番号が現在そのシステムで使用されていないInstance-IDになることを確認することが可能ですが、結果の5タプルはまだリモートシステムで使用されている可能性があります。たとえば、クライアントがリモートWebサーバーとのTCP接続を確立し、Webサーバーが接続でアクティブなクローズを実行するシナリオを検討します。この接続の状態情報はクライアント側で消えますが（つまり、接続は架空の閉じた状態に移動されます）、Instance-IDは2*MSLのWebサーバーの時間待合状態のままです（最大セグメント寿命）。同じクライアントが以前の接続の新しい化身を作成しようとした場合（つまり、サーバーのtime_wait状態と同じインスタンスIDとの接続）、インスタンスIDの「衝突」が発生します。これらの衝突の効果は、接続確立の障害から状態暗殺の時間待合（データ腐敗の可能性を伴う）にまで及びます[RFC1337]。特定のクライアントがサーバーで特定のサービスとTCP接続を確立するシナリオでは、これらの問題が明らかになります。したがって、一時的なポート選択アルゴリズムは、Instance-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).
Instance-IDの衝突速度を最小化するための単純だが非効率的なアプローチは、たとえば、TCPの場合、TCP接続の両方のエンドポイントが最近の接続について状態を維持することです（たとえば、両方のエンドポイントが時間に終わることになります。 - ウェイト状態）。
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.
o Instance-IDの衝突の最小化。
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で説明されている問題が明らかになります。Instance-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]).
リスニング状態でTCPが現在使用しているポート番号は、はかないポートとして使用することを許可されるべきではありません。このルールが遵守されていない場合、攻撃者は、少なくとも2つの異なる方法でローカルサーバーアプリケーションへの着信接続を「盗む」可能性があります。第一に、攻撃者は、クライアントが被害者サーバーアプリケーション[CPNI-TCP] [TCP-SEC]に接続しようとするのとほぼ同時に、被害者クライアントに接続要求を発行することができます。攻撃者の接続要求に対応するSynセグメントと、被害者クライアントに対応するSynセグメントは「ネットワーク内で互いに交差する」場合、攻撃者がクライアントが使用するはかないポートを知るか推測できる場合、TCP「同時に」オープン」シナリオが行われ、クライアントが送信した着信接続要求は、被害者サーバーアプリケーションのソケットではなく、攻撃者のソケットと一致します。第二に、攻撃者は「被害者」ソケット（例：ローカルIPアドレスとローカルTCPポートの両方を指定する）よりも特定のソケットを指定することができ、したがって、攻撃者のソケットに一致するシンセグメントを着信することは、攻撃者に配信されます。「被害者」ソケットに（[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].
TCP APIの一般的な実装に基づくほとんどのアプリケーション（Sockets APIなど）は、3つのステップで「パッシブオープン」を実行することに注意してください。まず、アプリケーションは、プロセス間通信に使用するファイル記述子を取得します（たとえば、Socket（）呼び出しを発行することにより）。第二に、アプリケーションはファイル記述子をローカルTCPポート番号にバインドします（例：Bind（）呼び出しを発行することにより）。第三に、前述のTCPはリスニング状態に置かれます（たとえば、リスニング（）コールを発行することにより）。その結果、TCP APIのこのような実装により、リスニング状態でTCPに使用されているポート番号が短命ポートとしての使用が許可されていない場合でも、2番目と3番目のステップの間に時間の窓があります。攻撃者は、着信接続を聞くために後で使用されるポート番号を選択できます。したがって、TCP APIのこれらの実装は、ポート番号の割り当てのためのより厳しい要件を強制する必要があります。リッスン状態または閉じた状態でTCPが使用しているポート番号は、はかないポート[CPNI-TCP] [CPNI-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_reuse_port）がソケットで発行されない限り、ほとんどのSCTP実装では同じポート番号にソケットをバインドできないため、前述の問題はSCTPに影響しません。。典型的なSCTPソケットAPIの例は、[SCTP-Socket]にあります。
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で構成されています。ただし、Ephemeral Port選択アルゴリズムは、全範囲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;
do {if（check_suitable_port（port））next_ephemeralを返します。
if (next_ephemeral == max_ephemeral) {
next_ephemeral = min_ephemeral;
} else {
next_ephemeral++;
}
count--;
} while (count > 0);
return 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]、およびその他のミドルボックスは、複数のピアを同じポートスペースに集約し、使用済みのはかないポートの母集団を増加させ、したがってInstance-IDの衝突の可能性を増加させます。ただし、[Allman]は、少なくともこのドキュメントで説明されているアルゴリズムの衝突特性の測定に使用されるネットワークシナリオで、前述のミドルボックスの使用に起因する衝突率が非常に低いことを示しています。
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).
このアルゴリズムは、以前に選択されたポート番号を考慮せずにポート選択を実行するため、ポート番号を速すぎる可能性があるため、Instance-IDの衝突につながる可能性があります。特定のInstance-IDがポート選択アルゴリズムによって一意であることが検証されている場合でも、Instance-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;
do {if（check_suitable_port（port））next_ephemeralを返します。
next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count--;
} while (count > 0);
return 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.
同じ宛先エンドポイントですでに使用されているポート番号が多数ある場合、このアルゴリズムは、たとえある場合でも、一時的なポートを選択することができない（つまり、「エラー」を返す）ことができない可能性があります。まだユニークな5タプルをもたらす数のポート番号が利用可能です。ただし、[Allman]の結果は、一般的なシナリオでは1つのポート選択で十分であり、ほとんどの場合、複数の選択肢が必要な場合、2つの選択肢で十分であることが示されています。したがって、これらのシナリオでは、これは問題ではありません。
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.
従来のBSDポート選択アルゴリズムのポートリューズプロパティ（セクション2.2で説明）を実現したいのですが、同時にアルゴリズム1とアルゴリズム2の予測不可能性の特性を達成します。
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」変数のそれぞれは、はかないポート範囲内のランダム値で初期化する必要があります。したがって、これらは輸送プロトコルインスタンスのはかないポートスペースを「照明ごとのエンドポイント」ベースで分離します（この「分離」Ephemeral Port Space」とは、異なるリモートエンドポイントを持つトランスポートプロトコルインスタンスがポート番号の異なるシーケンスを持たないことを意味します。つまり、従来の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;
next_ephemeral++;
if(check_suitable_port(port)) return port;
if（check_suitable_port（port））返品ポート;
count--;
カウント - ;
} while (count > 0);
return 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（）は、グローバルな一時的なポート範囲内で「輝くエンドポイント」固定オフセットを提供します。「オフセット」と「next_ephemeral」変数の両方は、アルゴリズム1（セクション3.3.1で説明）と同様の方法で結果のポートを制限しているため、ストレージタイプの範囲内で任意の値を取ることができます。これにより、「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).
アルゴリズム3は単なる一時的なポートの選択の難読化の手法であるため、例えばMD5よりも強い暗号化アルゴリズムは必要ありません。秘密は、可能な限りランダムになるように選択されるべきです（秘密の選択に関する推奨事項については[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().
Multiuserシステムでは、関数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（）の結果の幅）を次のように達成できます。システムは、table_lengthの短い整数の配列を保持し、「next_ephemeral」変数の増分の分離を提供します。この改善は、次のようにアルゴリズム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;
if（check_suitable_port（port））返品ポート;
count--;
カウント - ;
} while (count > 0);
return 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]のような暗号化ハッシュ関数である必要があります。IPアドレス、リモートポート、およびシークレットキー値の両方を使用して、0〜（table_length-1）の値を計算する必要があります。または、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 []」は、同じリモートエンドポイントを持つ連続したトランスポートプロトコルインスタンスが、短縮ポート番号の増加を使用することを保証します。ただし、ポート番号の増加は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 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.
「テーブル[]」のサイズは、異なるポートシーケンスの数を制限するのではなく、 *増分 *をテーブル_Lengthの異なるスペースに分離することに注意してください。ポートシーケンスは、実際のポートシーケンスを選択する変数「オフセット」に「テーブル[]」の対応するエントリを追加することから生じます（アルゴリズム3のように）。[Allman]は、10のTable_lengthがアルゴリズム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).
攻撃者は、攻撃者が「可視性」を持っている「増分スペース」のトラフィック分析を実行できます。つまり、攻撃者は、ターゲット（オフセット）がターゲット「増分スペース」を識別するトランスポートプロトコールインスタンスをクライアントに強制することができます。ただし、従来のBSDアルゴリズム（セクション2.2で説明）およびアルゴリズム3と比較すると、トラフィック分析を実行する攻撃者の能力は非常に削減されます。さらに、実装により、攻撃者のトラフィック分析を実行する能力がさらに制限され、増分スペースを分離することでトラフィック分析を実行できます（つまり、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).
[Allman]は別のポート選択アルゴリズムを導入しました。これは、ランダムに一時的なポート（セクション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;
count = num_ephemeral;
do {
next_ephemeral = next_ephemeral + (random() % N) + 1;
port = min_ephemeral + (next_ephemeral % num_ephemeral);
if(check_suitable_port(port)) return port;
if（check_suitable_port（port））返品ポート;
count--;
} while (count > 0);
return 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.
このアルゴリズムは、単調に増加するシーケンスを生成して、Instance-IDの衝突を防ぐことを目的とし、固定増分の使用を回避し、些細な予測可能なシーケンスにつながります。値「n」は、予測不可能性のレベルとポートリューズ周波数の間のトレードオフを直接制御できるようにします。「n」の値が小さいほど、このアルゴリズムは従来のBSDポート選択アルゴリズムに類似しています（セクション2.2で説明）。「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:
ポート番号がラップすると、Instance-IDの衝突のリスクがあります。したがって、「n」は次の基準に従って選択する必要があります。
o It should maximize the wrapping time of the ephemeral port space.
o 一時的なポートスペースのラッピング時間を最大化する必要があります。
o It should minimize collisions of instance-ids.
o Instance-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のような）は、入力値よりも安全ではなく、はかないポートの場合はシークレットキーです。攻撃者が、どの暗号化ハッシュ関数が被害者によって使用されているかを認識している場合（予想すべき）、攻撃者は十分な資料を取得できます（たとえば、被害者によって選択されたはかないポート）、攻撃者は秘密全体を検索することができます - マッチを見つけるための重要なスペース。
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 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.
秘密を変更すると、選択された一時的な港の突然のシフトが発生し、その結果、衝突が発生する可能性があります。つまり、秘密を変更すると、各宛先エンドポイントで使用される「オフセット」値（セクション3.3.3および3.3.4を参照）は、以前の秘密で計算された値とは異なり、最近ポート番号の選択につながります。同じエンドポイントに接続するために使用されます。
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.
[Allman]は、このドキュメントで説明されているアルゴリズムの特性の経験的研究であり、このドキュメントで説明されているすべてのアルゴリズムが低い衝突率を提供していることがわかりました。つまり、[Allman]によって評価されたネットワークシナリオでは、このドキュメントで説明されているすべてのアルゴリズムがInstance-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には、一時的なポートの実際のランダム化を提供するという利点があります。ただし、ポート番号の衝突の可能性を高める可能性があり、接続確立の試みの失敗につながる可能性があります。[Allman]は、これらの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は、ローカルおよびリモートIPアドレスとリモートポートスペースで完全な分離を提供し、他の寸法では限られた分離のみを提供します（セクション3.4を参照）。ただし、実装では、オフセットに使用される暗号化ハッシュを計算することのパフォーマンスへの影響を考慮する必要があります。
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はアルゴリズム3を改善し、通常はg（）を計算するために使用されるより多くのプロセッササイクルと、配列「テーブル[]」を保存するための追加のカーネルメモリを犠牲にして、より低いポートリューズ周波数につながります。
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由来システムでは、Bind（）への呼び出しにより、はかないポート番号が選択されます。ただし、リモートIPアドレスもリモートポートも短命ポート選択関数に使用できないため、アルゴリズム3とアルゴリズム4で使用されるハッシュ関数F（）には、必要なすべての引数がありません。機能を計算することは不可能です。アルゴリズム3またはアルゴリズム4を実装するトランスポートプロトコル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].
この動作に代わるものは、bind（）コールに応じて「怠zyなバインディング」を実装することです。つまり、一時的なポートの選択は、たとえば、connect（）またはsend（）が呼び出されるまで遅延します。したがって、その時点では、短命ポートが実際に選択され、ハッシュ関数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.
トランスポートプロトコルインスタンスの2つのエンドポイントの間にNAPTが存在するシナリオでは、一時的なポート選択の難読化（外部ネットワークの観点から）は、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.
ポート保存を実装しないNAPT [RFC4787] [RFC5382]は、パケットの翻訳中に変更されたときにパケットの一時的なポートの選択を難読化する必要があります。
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は、このドキュメントのアルゴリズム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は、接続を確立する広大なサービスとトラフィックの全体的なレート[Allman]のために、単に短命ポートの選択を自然に曖昧にする可能性があることに注意する必要があります。
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を含むことを推奨し、実装が一時的なポート選択に利用できるようにすべきではないポート番号のリストを維持することを示唆しています。利用できないポート番号のリストが重要である場合、セクション3.3.1に記載されているように、アルゴリズム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]のSteven 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.
著者は、（アルファベット順の順序で）マーク・オールマン、ジャリ・アークコ、マティアス・ベスケ、ステファン・ボルツマイヤー、ブライアン・カーペンター、ヴィンセント・デフォンテインズ、ラルフ・ドロム、ラース・エッガート、パシ・エレン、ゴーリー・フェアハースト、アドリア・ファーレルアルフレッド・ホーネス、アヴシャローム・ホイ、チャーリー・カウフマン、アミット・クライン、スブラマニアン・ムーネミー、カルロス・ピダタロ、ティム・ポーク、カチョン・プーン、パシ・サロラティ、ロバート・スパークス、ランドール・スチュワート、ジョー・タッチ、マイケル・チュークセン、マグナス・ウェストルンド、ダン・ウィングは、マグナス・ウェストバック、このドキュメントのドラフトバージョン。
The authors would like to thank Alfred Hoenes for his admirable effort in improving the quality of this document.
著者は、この文書の品質を向上させるための彼の見事な努力について、Alfred Hoenesに感謝したいと思います。
The authors would like to thank FreeBSD's Mike Silbersack for a very fruitful discussion about ephemeral port selection techniques.
著者は、FreeBSDのMike Silbersackに、はかないポート選択技術についての非常に実り多い議論をしてくれたことに感謝します。
Fernando Gont's attendance to IETF meetings was supported by ISOC's "Fellowship to the IETF" program.
Fernando GontのIETF会議への出席は、ISOCの「IETFへのフェローシップ」プログラムによってサポートされていました。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[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月。
[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.、Frederick、R。、およびV. Jacobson、「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。、「セッション説明プロトコル（SDP）のリアルタイムコントロールプロトコル（RTCP）属性」、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.、Pink、S.、Jonsson、L-E。、およびG. Fairhurst、「The Lightweight User Datagram Protocol（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] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[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月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram混雑制御プロトコル（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. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、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] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、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.
[Allman] Allman、M。、「Ephemeral Portsの選択に関するコメント」、ACM Computer Communication Review、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テクニカルノート3/2009：送信制御プロトコル（TCP）のセキュリティ評価"、2009、<http://www.cpni.gov.uk/docs/ tn-03-09-security-assessment-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.
[RFC1337] Braden、B。、「TCPにおける時間待ち暗殺の危険」、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. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953] Touch、J。、「スプーフィング攻撃に対するTCPの防御」、RFC 4953、2007年7月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、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-Socket] Stewart、R.、Poon、K.、Tuexen、M.、Lei、P。、およびV. Yasevich、V。、「Sockets API拡張機能のSockets API拡張（SCTP）」、進行中の作業、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：Socket and XTI」、1998年Prentice Hall。
[TCP-SEC] Gont, F., "Security Assessment of the Transmission Control Protocol (TCP)", Work in Progress, February 2010.
[TCP-SEC] Gont、F。、「送信制御プロトコル（TCP）のセキュリティ評価」、2010年2月の作業。
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", CanSecWest 2004 Conference.
[ワトソン]ワトソン、P。、「窓の滑り：TCPリセット攻撃」、Cansecwest 2004 Conference。
Appendix A. Survey of the Algorithms in Use by Some Popular Implementations
付録A. いくつかの一般的な実装で使用されているアルゴリズムの調査
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」と65535の「max_port」[FreeBSD]を使用するようになりました。
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は、アルゴリズム3を実装し、MD5をハッシュアルゴリズムとして実装します。アルゴリズムがセクション3.5で説明されているコーナーケースシナリオに直面している場合、代わりにアルゴリズム1が使用されます[Linux]。
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]を選択した各一時的なポート番号のポート番号を減少させます。
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]
OpenSolaris 2009.06 implements Algorithm 1, with a "min_port" of 32768 and a "max_port" of 65535 [OpenSolaris].
Opensolaris 2009.06は、32768の「min_port」と65535 [Opensolaris]の「max_port」を備えたアルゴリズム1を実装しています。
Authors' Addresses
著者のアドレス
Michael Vittrup Larsen Tieto Skanderborgvej 232 Aarhus DK-8260 Denmark
マイケル・ヴィトルトップ・ラーセン・ティエト・スカンダーボルグベジ232アーフスDK-8260デンマーク
Phone: +45 8938 5100
EMail: michael.larsen@tieto.com
Fernando Gont Universidad Tecnologica Nacional / Facultad Regional Haedo Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont Universidad Tecnologica Nacional / Fancultad Regional Haedo Evaristo Carriego 2644 Haedo、Provincia de Buenos Aires 1706 Argentina
Phone: +54 11 4650 8472
EMail: fernando@gont.com.ar