RFC5382 日本語訳
5382 NAT Behavioral Requirements for TCP. S. Guha, Ed., K. Biswas, B.Ford, S. Sivakumar, P. Srisuresh. October 2008. (Format: TXT=50306 bytes) (Also BCP0142) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Guha, Ed.
Request for Comments: 5382 Cornell U.
BCP: 142 K. Biswas
Category: Best Current Practice Cisco Systems
B. Ford
MPI-SWS
S. Sivakumar
Cisco Systems
P. Srisuresh
Kazeon Systems
October 2008
ワーキンググループのS.グーハ、エドをネットワークでつないでください。コメントのために以下を要求してください。 5382コーネルU.BCP: 142K.ビスワスカテゴリ: 最も良い現在の練習のSivakumarシスコシステムズP.Srisuresh KazeonシステムシスコシステムズB.フォードMPI-SWS S.2008年10月
NAT Behavioral Requirements for TCP
TCPのためのNATの行動の要件
Status of This Memo
このメモの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Abstract
要約
This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.
このドキュメントは多くのアプリケーションを許容するTCPを扱うNATsのための1セットの要件を定義します、ピアツーピアアプリケーションや一貫して扱うオンラインゲームのように。 このセットの必要条件を満たす展開しているNATsがこれらのアプリケーションが適切に機能する可能性を大いに広げるでしょう。
Guha, et al. Best Current Practice [Page 1] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[1ページ]RFC5382NAT TCP要件2008年10月
Table of Contents
目次
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. TCP Connection Initiation . . . . . . . . . . . . . . . . . . 4
4.1. Address and Port Mapping Behavior . . . . . . . . . . . . 5
4.2. Internally Initiated Connections . . . . . . . . . . . . . 5
4.3. Externally Initiated Connections . . . . . . . . . . . . . 7
5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . 10
6. Application Level Gateways . . . . . . . . . . . . . . . . . . 12
7. Other Requirements Applicable to TCP . . . . . . . . . . . . . 12
7.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 12
7.2. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . 13
7.3. ICMP Responses to TCP Packets . . . . . . . . . . . . . . 13
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informational References . . . . . . . . . . . . . . . . . 18
1. 適用性証明. . . . . . . . . . . . . . . . . . . 3 2。 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 4。 TCP接続開始. . . . . . . . . . . . . . . . . . 4 4.1。 マッピングの振舞い. . . . . . . . . . . . 5 4.2を記述して、移植してください。 内部的に開始しているコネクションズ. . . . . . . . . . . . . 5 4.3。 外部的に開始しているコネクションズ. . . . . . . . . . . . . 7 5。 NATセッションは.106をリフレッシュします。 アプリケーションレベルゲートウェイ. . . . . . . . . . . . . . . . . . 12 7。 TCP. . . . . . . . . . . . . 12 7.1に適切な他の要件。 課題. . . . . . . . . . . . . . . . . . . . . 12 7.2を移植してください。 振舞い. . . . . . . . . . . . . . . . . . . 13 7.3をHairpinningします。 TCPパケット. . . . . . . . . . . . . . 13 8へのICMP応答。 要件. . . . . . . . . . . . . . . . . . . . . . . . . 14 9。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 16 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 17 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 18 11.2。 情報の参照. . . . . . . . . . . . . . . . . 18
Guha, et al. Best Current Practice [Page 2] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[2ページ]RFC5382NAT TCP要件2008年10月
1. Applicability Statement
1. 適用性証明
This document is adjunct to [BEHAVE-UDP], which defines many terms relating to NATs, lays out general requirements for all NATs, and sets requirements for NATs that handle IP and unicast UDP traffic. The purpose of this document is to set requirements for NATs that handle TCP traffic.
このドキュメントは[BEHAVE-UDP]への付属物です。(それは、NATsに関連しながら多くの用語を定義して、すべてのNATsのために一般的な要件を広げて、IPを扱うNATsとユニキャストUDP交通に必要条件を定めます)。 このドキュメントの目的はTCP交通を扱うNATsのために必要条件を定めることです。
The requirements of this specification apply to traditional NATs as described in [RFC2663].
この仕様の要件は[RFC2663]で説明されるように伝統的なNATsに適用されます。
This document only covers the TCP aspects of NAT traversal. Middlebox behavior that is not necessary for network address translation of TCP is out of scope. Packet inspection above the TCP layer and firewalls are out of scope except for Application Level Gateway (ALG) behavior that may interfere with NAT traversal. Application and OS aspects of TCP NAT traversal are out of scope. Signaling-based approaches to NAT traversal, such as Middlebox Communication (MIDCOM) and Universal Plug and Play (UPnP), that directly control the NAT are out of scope. Finally, TCP connections intended for the NAT (e.g., an HTTP or Secure Shell Protocol (SSH) management interface) and TCP connections initiated by the NAT (e.g., reliable syslog client) are out of scope.
このドキュメントはNAT縦断のTCP局面をカバーするだけです。 範囲の外にTCPのネットワークアドレス変換に必要でないMiddleboxの振舞いがあります。 NAT縦断を妨げるかもしれないApplication Levelゲートウェイ(ALG)の振舞い以外の範囲の外にTCP層とファイアウォールの上のパケット点検があります。 範囲の外にTCP NAT縦断の利用とOS局面があります。 範囲の外に直接NATを制御するMiddlebox CommunicationなどのNAT縦断(MIDCOM)とUniversal Plug and Play(UPnP)へのシグナリングベースのアプローチがあります。 最終的に、範囲の外にNATのために意図するTCP接続(例えば、HTTPかSecureシェルプロトコル(SSH)管理インタフェース)とNATによって開始されたTCP接続(例えば、頼もしいsyslogクライアント)があります。
2. Introduction
2. 序論
Network Address Translators (NATs) hinder connectivity in applications where sessions may be initiated to internal hosts. Readers may refer to [RFC3022] for detailed information on traditional NATs. [BEHAVE-UDP] lays out the terminology and requirements for NATs in the context of IP and UDP. This document supplements these by setting requirements for NATs that handle TCP traffic. All definitions and requirements in [BEHAVE-UDP] are inherited here.
ネットワークAddress Translators(NATs)はセッションが内部のホストに開始されるかもしれないアプリケーションにおける接続性を妨げます。 読者は伝統的なNATsの詳細な情報について[RFC3022]を参照するかもしれません。 [BEHAVE-UDP]はIPとUDPの文脈のNATsのための用語と要件を広げます。 このドキュメントは、TCP交通を扱うNATsのために必要条件を定めることによって、これらを補います。 [BEHAVE-UDP]のすべての定義と要件はここで引き継がれます。
[RFC4614] chronicles the evolution of TCP from the original definition [RFC0793] to present-day implementations. While much has changed in TCP with regards to congestion control and flow control, security, and support for high-bandwidth networks, the process of initiating a connection (i.e., the 3-way handshake or simultaneous- open) has changed little. It is the process of connection initiation that NATs affect the most. Experimental approaches such as T/TCP [RFC1644] have proposed alternate connection initiation approaches, but have been found to be complex and susceptible to denial-of- service attacks. Modern operating systems and NATs consequently primarily support the 3-way handshake and simultaneous-open modes of connection initiation as described in [RFC0793].
[RFC4614]はTCPのオリジナルの定義[RFC0793]から現代の実現までの発展を記録にとどめます。 あいさつに応じて多くがTCPで高帯域ネットワークの輻輳制御、フロー制御、セキュリティ、およびサポートに変化する間、接続(すなわち、3ウェイ握手か同時の戸外)を開始する過程は少ししか変えていません。 それはNATsが最も影響する接続開始の過程です。 T/TCP[RFC1644]などの実験的なアプローチが交互の接続開始アプローチを提案しましたが、否定に複雑であって、影響されやすいと確かめられてください、そうした、-、サービス攻撃について。 その結果、近代的なオペレーティングシステムとNATsは[RFC0793]で説明されるように主として接続開始の3ウェイ握手と同時のオープン形式を支持します。
Guha, et al. Best Current Practice [Page 3] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[3ページ]RFC5382NAT TCP要件2008年10月
Recently, many techniques have been devised to make peer-to-peer TCP applications work across NATs. [STUNT], [NATBLASTER], and [P2PNAT] describe Unilateral Self-Address Fixing (UNSAF) mechanisms that allow peer-to-peer applications to establish TCP through NATs. These approaches require only endpoint applications to be modified and work with standards compliant OS stacks. The approaches, however, depend on specific NAT behavior that is usually, but not always, supported by NATs (see [TCPTRAV] and [P2PNAT] for details). Consequently, a complete TCP NAT traversal solution is sometimes forced to rely on public TCP relays to traverse NATs that do not cooperate. This document defines requirements that ensure that TCP NAT traversal approaches are not forced to use data relays.
最近、多くのテクニックが、ピアツーピアTCPアプリケーションをNATsの向こう側に働かせるように工夫されました。 [STUNT]、[NATBLASTER]、および[P2PNAT]はピアツーピアアプリケーションがNATsを通してTCPを設立できるUnilateral Self-アドレスFixing(UNSAF)メカニズムについて説明します。 これらのアプローチは、終点アプリケーションだけが変更されるのを必要とします、そして、規格対応することのOSとの仕事は積み重ねられます。 しかしながら、通常、そうである特定のNATの振舞いによりますが、アプローチはいつもよるというわけではありません、NATsによって支持されて(詳細に関して[TCPTRAV]と[P2PNAT]を見てください)。 その結果、完全なTCP NAT縦断対策は、協力しないNATsを横断するために時々やむを得ず公共のTCPリレーに依存します。 このドキュメントはTCP NAT縦断アプローチがやむを得ずデータリレーを使用しないのを確実にする要件を定義します。
3. Terminology
3. 用語
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
"NAT" in this specification includes both "Basic NAT" and "Network Address/Port Translator (NAPT)" [RFC2663]. The term "NAT Session" is adapted from [NAT-MIB] and is defined as follows.
この仕様による「NAT」は「基本的なNAT」と「ネットワーク・アドレス/ポート翻訳者(NAPT)」[RFC2663]の両方を含んでいます。 「NATセッション」という用語は、[NAT-MIB]から適合させられて、以下の通り定義されます。
NAT Session - A NAT session is an association between a TCP session as seen in the internal realm and a TCP session as seen in the external realm, by virtue of NAT translation. The NAT session will provide the translation glue between the two session representations.
NAT Session--NATセッションはNAT翻訳によって外部の分野で見られるように内部の分野で見られるTCPセッションとTCPセッションとの協会です。 NATセッションは2つのセッション表現の間に翻訳接着剤を提供するでしょう。
This document uses the term "TCP connection" (or just "connection") to refer to individual TCP flows identified by the 4-tuple (source and destination IP address and TCP port) and the initial sequence numbers (ISN).
このドキュメントは、4-tuple(ソース、送付先IPアドレス、およびTCPポート)と初期シーケンス番号(ISN)によって特定された個々のTCP流れについて言及するのに「TCP接続」(または、まさしく「接続」)という用語を使用します。
This document uses the term "address and port mapping" (or just "mapping") as defined in [BEHAVE-UDP] to refer to state at the NAT necessary for network address and port translation of TCP connections. This document also uses the terms "Endpoint-Independent Mapping", "Address-Dependent Mapping", "Address and Port-Dependent Mapping", "filtering behavior", "Endpoint-Independent Filtering", "Address-Dependent Filtering", "Address and Port-Dependent Filtering", "Port assignment", "Port overloading", "hairpinning", and "External source IP address and port" as defined in [BEHAVE-UDP].
このドキュメントはネットワーク・アドレスに必要なNATで状態について言及して、TCP接続に関する翻訳を移植するために[BEHAVE-UDP]で定義されるように「アドレスとポートマッピング」(または、まさしく「マッピング」)という用語を使用します。 また、このドキュメントは[BEHAVE-UDP]で定義されるように「振舞いをフィルターにかけ」て、「ポート課題」という「終点から独立しているフィルタリング」と、「アドレス依存するフィルタリング」と、「アドレスとポート依存するフィルタリング」が「積みすぎを移植する」という「終点から独立しているマッピング」と、「アドレス依存するマッピング」と、「アドレスとポート依存するマッピング」という用語「hairpinning」、および「外部電源IPアドレスとポート」を使用します。
4. TCP Connection Initiation
4. TCP接続開始
This section describes various NAT behaviors applicable to TCP connection initiation.
このセクションはTCP接続開始に適切な様々なNATの振舞いについて説明します。
Guha, et al. Best Current Practice [Page 4] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[4ページ]RFC5382NAT TCP要件2008年10月
4.1. Address and Port Mapping Behavior
4.1. 振舞いを写像するアドレスとポート
A NAT uses a mapping to translate packets for each TCP connection. A mapping is dynamically allocated for connections initiated from the internal side, and potentially reused for certain subsequent connections. NAT behavior regarding when a mapping can be reused differs for different NATs as described in [BEHAVE-UDP].
NATは、それぞれのTCP接続のためにパケットを翻訳するのにマッピングを使用します。 マッピングは、内部側から開始された接続のためにダイナミックに割り当てられて、確信しているその後の接続のために潜在的に再利用されます。 マッピングを再利用できる時に関するNATの振舞いは異なったNATsのために[BEHAVE-UDP]で説明されるように異なります。
Consider an internal IP address and TCP port (X:x) that initiates a TCP connection to an external (Y1:y1) tuple. Let the mapping allocated by the NAT for this connection be (X1':x1'). Shortly thereafter, the endpoint initiates a connection from the same (X:x) to an external address (Y2:y2) and gets the mapping (X2':x2') on the NAT. As per [BEHAVE-UDP], if (X1':x1') equals (X2':x2') for all values of (Y2:y2), then the NAT is defined to have "Endpoint- Independent Mapping" behavior. If (X1':x1') equals (X2':x2') only when Y2 equals Y1, then the NAT is defined to have "Address-Dependent Mapping" behavior. If (X1':x1') equals (X2':x2') only when (Y2:y2) equals (Y1:y1), possible only for consecutive connections to the same external address shortly after the first is terminated and if the NAT retains state for connections in TIME_WAIT state, then the NAT is defined to have "Address and Port-Dependent Mapping" behavior. This document introduces one additional behavior where (X1':x1') never equals (X2':x2'), that is, for each connection a new mapping is allocated; in such a case, the NAT is defined to have "Connection- Dependent Mapping" behavior.
内部のIPアドレスとTCPが外部(Y1: y1)のtupleにTCP接続を開始する(X: x)を移植すると考えてください。 'この接続のためにNATによって割り当てられたマッピングをさせてください、(X1、': x1'、) '終点がその後まもなく同じくらい(X: x)から外部アドレス(Y2: y2)までの接続を開始して、マッピングを得る、(X2、': x2'、)、NATで。 '[BEHAVE-UDP]のように(X1、': x1'、)、同輩、(X2、': x2'、)、そして、(Y2: y2)のすべての値において、NATは、「終点の独立しているマッピング」の振舞いを持つために定義されます。 '、(X1、': x1'、)、同輩、(X2、': x2'、)、Y2がY1と等しい場合にだけ、NATは、「アドレス依存するマッピング」の振舞いを持つために定義されます。 '、(X1、': x1'、)、同輩、(X2、いつだけの(Y2: y2)同輩(Y1: y1)の、そして、連続した接続だけに、すぐ1日以降同じ外部アドレスに可能な': x2'は終えられるか、そして、NATが中のタイム誌_WAITが述べる接続のための状態を保有するなら、NATは、「アドレスとポート依存するマッピング」の振舞いを持つために定義されます。 'このドキュメントが、ある追加振舞いを導入する、どこ、(X1、': x1'、)、決して同輩でない、(X2、': x2'、)、すなわち、各接続において、新しいマッピングを割り当てます。 このような場合には、NATは、「接続の依存するマッピング」の振舞いを持つために定義されます。
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior
for TCP.
REQ-1: NATには、TCPのための「終点から独立しているマッピング」の振舞いがなければなりません。
Justification: REQ-1 is necessary for UNSAF methods to work.
Endpoint-Independent Mapping behavior allows peer-to-peer
applications to learn and advertise the external IP address and
port allocated to an internal endpoint such that external peers
can contact it (subject to the NAT's security policy). The
security policy of a NAT is independent of its mapping behavior
and is discussed later in Section 4.3. Having Endpoint-
Independent Mapping behavior allows peer-to-peer applications to
work consistently without compromising the security benefits of
the NAT.
正当化: REQ-1が働くUNSAF方法に必要です。 終点から独立しているMappingの振舞いで、ピアツーピアアプリケーションは、外部の同輩がそれ(NATの安全保障政策を条件とした)に連絡できるように内部の終点に割り当てられた外部のIPアドレスとポートの、学んで、広告を出します。 NATの安全保障政策について、振舞いを写像するのから独立していて、後でセクション4.3で議論します。 Endpointの独立しているMappingの振舞いを持っているのに、NATのセキュリティ利益で妥協しないで、ピアツーピアアプリケーションは一貫して動作します。
4.2. Internally Initiated Connections
4.2. 内部的に開始しているコネクションズ
An internal endpoint initiates a TCP connection through a NAT by sending a SYN packet. The NAT allocates (or reuses) a mapping for the connection, as described in the previous section. The mapping defines the external IP address and port used for translation of all packets for that connection. In particular, for client-server
内部の終点は、NATを通してSYNパケットを送ることによって、TCP接続を開始します。 NATは接続のために前項で説明されるようにマッピングを割り当てます(または、再利用)。 マッピングはその接続のためにすべてのパケットに関する翻訳に使用される外部のIPアドレスとポートを定義します。 クライアント/サーバのための事項で
Guha, et al. Best Current Practice [Page 5] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[5ページ]RFC5382NAT TCP要件2008年10月
applications where an internal client initiates the connection to an external server, the mapping is used to translate the outbound SYN, the resulting inbound SYN-ACK response, the subsequent outbound ACK, and other packets for the connection. This method of connection initiation corresponds to the 3-way handshake (defined in [RFC0793]) and is supported by all NATs.
内部のクライアントが外部のサーバに接続を開始するアプリケーション、マッピングは外国行きのSYNを翻訳するのに使用されます、結果として起こる本国行きのSYN-ACK応答、接続のためのその後の外国行きのACKの、そして、他のパケット。 接続開始のこの方法は、3ウェイ握手([RFC0793]では、定義される)に対応している、すべてのNATsによって支持されます。
Peer-to-peer applications use an alternate method of connection initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse NATs. In the simultaneous-open mode of operation, both peers send SYN packets for the same TCP connection. The SYN packets cross in the network. Upon receiving the other end's SYN packet, each end responds with a SYN-ACK packet, which also cross in the network. The connection is considered established once the SYN-ACKs are received. From the perspective of the NAT, the internal host's SYN packet is met by an inbound SYN packet for the same connection (as opposed to a SYN-ACK packet during a 3-way handshake). Subsequent to this exchange, both an outbound and an inbound SYN-ACK are seen for the connection. Some NATs erroneously block the inbound SYN for the connection in progress. Some NATs block or incorrectly translate the outbound SYN-ACK. Such behavior breaks TCP simultaneous-open and prevents peer-to-peer applications from functioning correctly behind a NAT.
ピアツーピアアプリケーションは横断するために同時、開いている(図8、[RFC0793])NATsと呼ばれた接続開始の代替方法を使用します。 操作の同時のオープン形式で、両方の同輩は同じTCP接続のためにパケットをSYNに送ります。 SYNパケットはネットワークで交差しています。 もう一方の端のSYNパケットを受けると、各端はSYN-ACKパケットで応じます(また、ネットワークで交差しています)。 SYN-ACKsがいったん受け取られているようになると、接続は確立していると考えられます。 NATの見解から、内部のホストのSYNパケットは同じ接続(3ウェイ握手の間のSYN-ACKパケットと対照的に)のために本国行きのSYNパケットによって触れられます。 この交換にその後の、そして、外国行きの、そして、本国行きの両方のSYN-ACKは接続に関して見られます。 いくつかのNATsが進行中の接続のために誤って本国行きのSYNを妨げます。 何らかのNATsブロックか不当に外国行きのSYN-ACKを翻訳してください。 そのような振舞いは、TCPを壊して、同時、開いて、ピアツーピアアプリケーションがNATの後ろで正しく機能するのを防ぎます。
In order to provide network address translation service for TCP, it is necessary for a NAT to correctly receive, translate, and forward all packets for a connection that conform to valid transitions of the TCP State-Machine (Fig. 6, [RFC0793]).
ネットワーク・アドレス翻訳サービスをTCPに供給するために、NATが正しく接続のためのTCP州-マシン(図6、[RFC0793])の有効な変遷に従うすべてのパケットを受けて、翻訳して、進めるのが必要です。
REQ-2: A NAT MUST support all valid sequences of TCP packets
(defined in [RFC0793]) for connections initiated both internally
as well as externally when the connection is permitted by the NAT.
In particular:
a) In addition to handling the TCP 3-way handshake mode of
connection initiation, A NAT MUST handle the TCP simultaneous-
open mode of connection initiation.
REQ-2: NATは接続がNATによって受入れられるとき内部的に外部的に開始された接続のためにTCPパケット([RFC0793]では、定義される)のすべての有効な系列をサポートしなければなりません。 特に: a) 接続開始のTCP3ウェイ握手モードを扱うことに加えて、A NATは接続開始のTCPの同時のオープン形式を扱わなければなりません。
Justification: The intent of this requirement is to allow standards
compliant TCP stacks to traverse NATs no matter what path the
stacks take through the TCP state-machine and no matter which end
initiates the connection as long as the connection is permitted by
the filtering policy of the NAT (filtering policy is described in
the following section).
a) In addition to TCP packets for a 3-way handshake, A NAT must be
prepared to accept an inbound SYN and an outbound SYN-ACK for
an internally initiated connection in order to support
simultaneous-open.
正当化: この要件の意図はスタックがTCP州マシンを通してどんな経路を取るか、そして、接続がNATのフィルタリング方針で受入れられる限り、どの終わりが接続を開始しても言いなりになっているTCPがNATsを横断するために積み重ねる規格に. (方針をフィルターにかけるのは以下のセクションで説明されます)a)を許容することです。 3ウェイ握手のためのTCPパケットに加えて、同時の戸外を支持して、内部的に開始している接続のために本国行きのSYNと外国行きのSYN-ACKを受け入れるようにA NATを準備しなければなりません。
Guha, et al. Best Current Practice [Page 6] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[6ページ]RFC5382NAT TCP要件2008年10月
4.3. Externally Initiated Connections
4.3. 外部的に開始しているコネクションズ
The NAT allocates a mapping for the first connection initiated by an internal endpoint to an external endpoint. In some scenarios, the NAT's policy may allow this mapping to be reused for connections initiated from the external side to the internal endpoint. Consider as before an internal IP address and port (X:x) that is assigned (or reuses) a mapping (X1':x1') when it initiates a connection to an external (Y1:y1). An external endpoint (Y2:y2) attempts to initiate a connection with the internal endpoint by sending a SYN to (X1':x1'). A NAT can choose to either allow the connection to be established, or to disallow the connection. If the NAT chooses to allow the connection, it translates the inbound SYN and routes it to (X:x) as per the existing mapping. It also translates the SYN-ACK generated by (X:x) in response and routes it to (Y2:y2), and so on. Alternately, the NAT can disallow the connection by filtering the inbound SYN.
NATは内部の終点によって開始された最初の接続のために外部の終点にマッピングを割り当てます。 いくつかのシナリオでは、NATの方針は、このマッピングが外部側から内部の終点まで開始された接続のために再利用されるのを許容するかもしれません。 '従来と同様内部のIPがアドレスとマッピングが割り当てられる(または、再利用)ポート(X: x)であると考えてください、(X1、': x1'、)、外部(Y1: y1)に接続を開始するとき。 SYNを送る内部の終点との接続を開始する、'外部の終点(Y2: y2)が、試みる(X1、': x1'、) NATは、接続が設立されるか、または接続を禁じるのを許容するのを選ぶことができます。 NATが、接続を許すのを選ぶなら、それは、既存のマッピングに従って本国行きのSYNを翻訳して、(X: x)にそれを発送します。 それは、また、応答で(X: x)で発生するSYN-ACKを翻訳して、(Y2: y2)などにそれを発送します。 交互に、NATは、本国行きのSYNをフィルターにかけることによって、接続を禁じることができます。
A NAT may allow an existing mapping to be reused by an externally initiated connection if its security policy permits. Several different policies are possible as described in [BEHAVE-UDP]. If a NAT allows the connection initiation from all (Y2:y2), then it is defined to have "Endpoint-Independent Filtering" behavior. If the NAT allows connection initiations only when Y2 equals Y1, then the NAT is defined to have "Address-Dependent Filtering" behavior. If the NAT allows connection initiations only when (Y2:y2) equals (Y1:y1), then the NAT is defined to have "Address and Port-Dependent Filtering" behavior (possible only shortly after the first connection has been terminated but the mapping is still active). One additional filtering behavior defined in this document is when the NAT does not allow any connection initiations from the external side; in such cases, the NAT is defined to have "Connection-Dependent Filtering" behavior. The difference between "Address and Port-Dependent Filtering" and "Connection-Dependent Filtering" behavior is that the former permits an inbound SYN during the TIME_WAIT state of the first connection to initiate a new connection while the latter does not.
安全保障政策が可能にするなら、NATは、既存のマッピングが外部的に開始している接続によって再利用されるのを許容するかもしれません。 いくつかの異なった方針が[BEHAVE-UDP]で説明されるように可能です。 NATがすべて(Y2: y2)から接続開始を許容するなら、それは、「終点から独立しているフィルタリング」の振舞いを持つために定義されます。 Y2がY1と等しいときにだけ、NATが接続開始を許容するなら、NATは、「アドレス依存するフィルタリング」の振舞いを持つために定義されます。 (Y2: y2)が(Y1: y1)と等しいときにだけ、NATが接続開始を許容するなら、NATは、(まもなくだけ、可能最初の接続が終えられた後にマッピングだけがまだアクティブであることを)であるのに「アドレスとポート依存するフィルタリング」の振舞いを持つために定義されます。 振舞いが定義した1つの追加フィルタリングが本書ではNATが外部側から少しの接続開始も許容しない時です。 そのような場合、NATは、「接続依存するフィルタリング」の振舞いを持つために定義されます。 「アドレスとポート依存するフィルタリング」の違いと「接続依存するフィルタリング」の振舞いは後者が可能にしませんが、前者が新しい接続を開始する最初の接続のタイム誌_WAIT状態の間本国行きのSYNを可能にするということです。
REQ-3: If application transparency is most important, it is
RECOMMENDED that a NAT have an "Endpoint-Independent Filtering"
behavior for TCP. If a more stringent filtering behavior is most
important, it is RECOMMENDED that a NAT have an "Address-Dependent
Filtering" behavior.
a) The filtering behavior MAY be an option configurable by the
administrator of the NAT.
b) The filtering behavior for TCP MAY be independent of the
filtering behavior for UDP.
REQ-3: アプリケーション透明が最も重要であるなら、NATにはTCPのための「終点から独立しているフィルタリング」の振舞いがあるのは、RECOMMENDEDです。 より厳しいフィルタリングの振舞いが最も重要であるなら、NATには「アドレス依存するフィルタリング」振舞いa)があるのは、RECOMMENDEDです。 フィルタリングの振舞いは. NATの管理者が構成可能なオプションがb)であったならそうするかもしれません。 TCP MAYのためのフィルタリングの振舞いはUDPのためのフィルタリングの振舞いの如何にかかわらずそうです。
Guha, et al. Best Current Practice [Page 7] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[7ページ]RFC5382NAT TCP要件2008年10月
Justification: The intent of this requirement is to allow peer-to-
peer applications that do not always initiate connections from the
internal side of the NAT to continue to work in the presence of
NATs. This behavior also allows applications behind a BEHAVE
compliant NAT to inter-operate with remote endpoints that are
behind non-BEHAVE compliant (legacy) NATs. If the remote
endpoint's NAT does not have Endpoint-Independent Mapping behavior
but has only one external IP address, then an application can
still traverse the combination of the two NATs if the local NAT
has Address-Dependent Filtering. Section 9 contains a detailed
discussion on the security implications of this requirement.
正当化: この要件の意図は同輩から同輩へのNAT内部側から接続をいつも開始するというわけではないアプリケーションが、NATsの面前で働き続けているのを許容することです。 また、この振舞いで、BEHAVE対応することのNATの後ろのアプリケーションは非BEHAVEの言いなりになっている(遺産)NATsの後ろにある遠く離れた終点で共同利用します。 遠く離れた終点のNATでは、Endpointから独立しているMappingの振舞いを持っていませんが、1つの外部のIPアドレスしかないなら、地方のNATにAddress依存するFilteringがあるなら、アプリケーションはまだ2NATsの組み合わせを横断できます。 セクション9はこの要件のセキュリティ含意の詳細な論議を含みます。
If the inbound SYN packet is filtered, either because a corresponding mapping does not exist or because of the NAT's filtering behavior, a NAT has two basic choices: to ignore the packet silently, or to signal an error to the sender. Signaling an error through ICMP messages allows the sender to quickly detect that the SYN did not reach the intended destination. Silently dropping the packet, on the other hand, allows applications to perform simultaneous-open more reliably.
本国行きのSYNパケットが対応するマッピングが存在していないためかNATが振舞いをフィルターにかけることのでフィルターにかけられるなら、NATには、2つの基本的な選択があります: 静かにパケットを無視するか、または送付者に誤りに合図するために。 ICMPメッセージを通した誤りに合図すると、意図している目的地はすぐに検出するSYNが届かなかった送付者に許容されます。 他方では、静かにパケットを落とすのに、アプリケーションは同時の戸外をより確かに実行できます。
Silently dropping the SYN aids simultaneous-open as follows. Consider that the application is attempting a simultaneous-open and the outbound SYN from the internal endpoint has not yet crossed the NAT (due to network congestion or clock skew between the two endpoints); this outbound SYN would otherwise have created the necessary mapping at the NAT to allow translation of the inbound SYN. Since the outbound SYN did not reach the NAT in time, the inbound SYN cannot be processed. If a NAT responds to the premature inbound SYN with an error message that forces the external endpoint to abandon the connection attempt, it hinders applications performing a TCP simultaneous-open. If instead the NAT silently ignores the inbound SYN, the external endpoint retransmits the SYN after a TCP timeout. In the meantime, the NAT creates the mapping in response to the (delayed) outbound SYN such that the retransmitted inbound SYN can be routed and simultaneous-open can succeed. The downside to this behavior is that in the event the inbound SYN is erroneous, the remote side does not learn of the error until after several TCP timeouts.
静かに低下して、SYNは以下の同時の戸外を支援します。 アプリケーションが同時の戸外を試みていて、内部の終点からの外国行きのSYNがまだ、NAT(2つの終点の間のネットワークの混雑か時計斜行による)に交差していないと考えてください。 そうでなければ、この外国行きのSYNは、本国行きのSYNに関する翻訳を許容するためにNATで必要なマッピングを作成したでしょう。 外国行きのSYNが時間内にNATに達しないで以来、本国行きのSYNを処理できません。 NATが外部の終点がやむを得ず接続試みを捨てるエラーメッセージで時期尚早な本国行きのSYNに応じるなら、それは同時、開いているTCPを実行するアプリケーションを妨げます。 NATが代わりに静かに本国行きのSYNを無視するなら、外部の終点はTCPタイムアウトの後にSYNを再送します。 差し当たり、NATは、再送された本国行きのSYNを発送できて、同時の戸外が成功できるように、(延着します)外国行きのSYNに対応してマッピングを作成します。 この振舞いへの下落傾向が出来事では、本国行きのSYNが誤るということである、遠隔地側は数回のTCPタイムアウトの後まで誤りを知りません。
NAT support for simultaneous-open as well as quickly signaling errors are both important for applications. Unfortunately, there is no way for a NAT to signal an error without forcing the endpoint to abort a potential simultaneous-open: TCP RST and ICMP Port Unreachable packets require the endpoint to abort the attempt while the ICMP Host and Network Unreachable errors may adversely affect other connections to the same host or network [RFC1122].
アプリケーションには、同時、開いていてすぐに合図している誤りのNATサポートはともに重要です。 残念ながら、NATが同時、開いている可能性に中止になるように終点を強制することのない誤りに示す方法が全くありません: TCP RSTとICMP Port Unreachableパケットは、ICMP HostとNetwork Unreachable誤りが同じホストかネットワーク[RFC1122]に他の接続に悪影響を与えているかもしれない間、試みを中止するために終点を必要とします。
Guha, et al. Best Current Practice [Page 8] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[8ページ]RFC5382NAT TCP要件2008年10月
In addition, when an unsolicited SYN is received by the NAT, the NAT may not know whether the application is attempting a simultaneous- open (and that it should therefore silently drop the SYN) or whether the SYN is in error (and that it should notify the sender).
NATで求められていないSYNを受け取るとき、さらに、NATが、アプリケーションが同時の戸外を試みているかどうかを知らないかもしれない、(そして、したがって、それは静かにSYNを落とすべきです)、SYNが間違っている、(そして、それは送付者に通知するべきです)
REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet
for at least 6 seconds after the packet is received. If during
this interval the NAT receives and translates an outbound SYN for
the connection the NAT MUST silently drop the original unsolicited
inbound SYN packet. Otherwise, the NAT SHOULD send an ICMP Port
Unreachable error (Type 3, Code 3) for the original SYN, unless
REQ-4a applies.
a) The NAT MUST silently drop the original SYN packet if sending a
response violates the security policy of the NAT.
REQ-4: パケットが受け取られていた後にNATは少なくとも6秒間、求められていない本国行きのSYNパケットに応じてはいけません。 NATが接続のためにこの間隔の間、外国行きのSYNを受けて、翻訳するなら、NATは静かにオリジナルの求められていない本国行きのSYNパケットを落とさなければなりません。 さもなければ、NAT SHOULDはオリジナルのSYNのために、ICMP Port Unreachable誤り(3をタイプしてください、Code3)を送ります、REQ-4aが. a)を適用しない場合 応答を送るとNATの安全保障政策が違反されるなら、NATは静かにオリジナルのSYNパケットを落とさなければなりません。
Justification: The intent of this requirement is to allow
simultaneous-open to work reliably in the presence of NATs as well
as to quickly signal an error in case the unsolicited SYN is in
error. As of writing this memo, it is not possible to achieve
both; the requirement therefore represents a compromise. The NAT
should tolerate some delay in the outbound SYN for a TCP
simultaneous-open, which may be due to network congestion or loose
synchronization between the endpoints. If the unsolicited SYN is
not part of a simultaneous-open attempt and is in error, the NAT
should endeavor to signal the error in accordance with [RFC1122].
a) There may, however, be reasons for the NAT to rate-limit or
omit such error notifications, for example, in the case of an
attack. Silently dropping the SYN packet when under attack
allows simultaneous-open to work without consuming any extra
network bandwidth or revealing the presence of the NAT to
attackers. Section 9 mentions the security considerations for
this requirement.
正当化: この要件の意図は求められていないSYNが間違っているといけないので同時の戸外がNATsの面前で確かに働いて、すぐに誤りに合図するのを許容することです。 このメモを書く現在、両方を達成するのは可能ではありません。 したがって、要件は妥協を表します。 NATは同時、開いているTCPのために外国行きのSYNの何らかの遅れを許容するべきです。(TCPは終点の間のネットワークの混雑かゆるい同期のためであるかもしれません)。 求められていないSYNが同時、開いている試みの一部でなく、間違っているなら、NATは、[RFC1122] a)によると、誤りに合図するよう努力するべきです。 そこでは、しかしながら、レート限界へのNATの理由であるか例えば、攻撃の場合でそのようなエラー通知を省略するかもしれません。 攻撃で静かにSYNパケットを落とすのにどんな余分なネットワークも消費しないで扱うために同時、開いている帯域幅かNATの存在を攻撃者に明らかにすること。 セクション9はこの要件のためにセキュリティ問題について言及します。
For NATs that combine NAT functionality with end-host functionality (e.g., an end-host that also serves as a NAT for other hosts behind it), REQ-4 above applies only to SYNs intended for the NAT'ed hosts and not to SYNs intended for the NAT itself. One way to determine whether the inbound SYN is intended for a NAT'ed host is to allocate NAT mappings from one port range, and allocate ports for local endpoints from a different non-overlapping port range. More dynamic implementations can be imagined.
終わりホストの機能性(例えば、また、他のホストのためのNATとしてそれの後ろに勤める終わりホスト)にNATの機能性を結合するNATsに関しては、上のREQ-4はNAT自体のために意図するSYNsではなく、NAT'edホストのために意図するSYNsだけに適用します。 本国行きのSYNがNAT'edホストのために意図するかどうか決定する1つの方法は、1つのポート範囲からNATマッピングを割り当てて、ポートを異なった非重なっているポート範囲から地方の終点に割り当てることです。 よりダイナミックな実現を想像できます。
Guha, et al. Best Current Practice [Page 9] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[9ページ]RFC5382NAT TCP要件2008年10月
5. NAT Session Refresh
5. NATセッションはリフレッシュします。
A NAT maintains state associated with in-progress and established connections. Because of this, a NAT is susceptible to a resource- exhaustion attack whereby an attacker (or virus) on the internal side attempts to cause the NAT to create more state than for which it has resources. To prevent such an attack, a NAT needs to abandon sessions in order to free the state resources.
NATは進行中の、そして、確立した接続に関連しているのに状態を維持します。 これのために、NATは内部側の上の攻撃者(または、ウイルス)がNATがそれが持っているものより多くの状態を創設することを引き起こすのを試みるリソース疲労困憊攻撃に影響されやすいです。リソース。 そのような攻撃を防ぐために、NATは、州のリソースを解放するためにセッションを捨てる必要があります。
A common method that is applicable only to TCP is to preferentially abandon sessions for crashed endpoints, followed by closed TCP connections and partially open connections. A NAT can check if an endpoint for a session has crashed by sending a TCP keep-alive packet and receiving a TCP RST packet in response. If the NAT cannot determine whether the endpoint is active, it should not abandon the session until the TCP connection has been idle for some time. Note that an established TCP connection can stay idle (but live) indefinitely; hence, there is no fixed value for an idle-timeout that accommodates all applications. However, a large idle-timeout motivated by recommendations in [RFC1122] can reduce the chances of abandoning a live session.
TCPだけに適切な共通方法は、優先的に墜落している終点にセッションを捨てて、閉じているTCP接続で続いて、接続を部分的に開くことです。 NATは、セッションのための終点がTCPキープアライブパケットを送って、応答でTCP RSTパケットを受けることによってクラッシュしたかどうかチェックできます。 NATが、終点がアクティブであるかどうか決定できないなら、TCP接続がしばらく無駄になるまで、それはセッションを捨てるべきではありません。 確立したTCP接続が無期限に活動していないままであることができることに(生きてください)注意してください。 したがって、すべてのアプリケーションを収容するアイドルタイムアウトのための一定の価値が全くありません。 しかしながら、[RFC1122]で推薦で動機づけられた大きいアイドルタイムアウトはライブセッションを捨てるという可能性を小さくすることができます。
A TCP connection passes through three phases: partially open, established, and closing. During the partially open phase, endpoints synchronize initial sequence numbers. The phase is initiated by the first SYN for the connection and extends until both endpoints have sent a packet with the ACK flag set (TCP states: SYN_SENT and SYN_RCVD). ACKs in both directions mark the beginning of the established phase where application data can be exchanged indefinitely (TCP states: ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, and CLOSE_WAIT). The closing phase begins when both endpoints have terminated their half of the connection by sending a FIN packet. Once FIN packets are seen in both directions, application data can no longer be exchanged, but the stacks still need to ensure that the FIN packets are received (TCP states: CLOSING and LAST_ACK).
TCP接続は三相を通り抜けます: 設立されて、閉じて、部分的に開いてください。 部分的に開いている段階の間、終点は初期シーケンス番号を同期させます。 フェーズは、ACK旗のセット(TCP州: SYN_SENTとSYN_RCVD)と共に接続のために最初のSYNによって開始されて、両方の終点がパケットを送るまで、広がっています。 両方の方向へのACKsはアプリケーションデータを無期限に交換できる確立したフェーズ(TCP州: ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、およびCLOSE_WAIT)の始まりを示します。 両方の終点がFINパケットを送ることによって半分の彼らの接続を終えたとき、最終段階は始まります。 FINパケットがいったん両方の方向に見られると、もうアプリケーションデータを交換できませんが、スタックは、まだFINパケットが受け取られているのを(TCP州: CLOSINGとLAST_ACK)保証する必要があります。
TCP connections can stay in established phase indefinitely without exchanging any packets. Some end-hosts can be configured to send keep-alive packets on such idle connections; by default, such keep- alive packets are sent every 2 hours if enabled [RFC1122]. Consequently, a NAT that waits for slightly over 2 hours can detect idle connections with keep-alive packets being sent at the default rate. TCP connections in the partially open or closing phases, on the other hand, can stay idle for at most 4 minutes while waiting for in-flight packets to be delivered [RFC1122].
どんなパケットも交換しないで、TCP接続は確立したフェーズで無期限に滞在できます。 そのような無駄な接続にキープアライブパケットを送るために何人かの終わりホストを構成できます。 デフォルトで、可能にするなら[RFC1122]、2時間毎に生きているそのような生活費パケットを送ります。 その結果、2時間余り待つNATはデフォルトレートで送るキープアライブパケットとの無駄な関係を検出できます。 他方では、部分的に開いているか終わりのフェーズにおけるTCP接続は高々4分間活動していない[RFC1122]が機内のパケットに提供されるのを待っている間のままであることができます。
Guha, et al. Best Current Practice [Page 10] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[10ページ]RFC5382NAT TCP要件2008年10月
The "established connection idle-timeout" for a NAT is defined as the minimum time a TCP connection in the established phase must remain idle before the NAT considers the associated session a candidate for removal. The "transitory connection idle-timeout" for a NAT is defined as the minimum time a TCP connection in the partially open or closing phases must remain idle before the NAT considers the associated session a candidate for removal. TCP connections in the TIME_WAIT state are not affected by the "transitory connection idle- timeout".
NATのための「確立した接続アイドルタイムアウト」はNATが、合同会議が取り外しの候補であると考える前に確立したフェーズにおけるTCP接続が活動していないままでいなければならない最小の時と定義されます。 NATのための「一時的な接続アイドルタイムアウト」はNATが、合同会議が取り外しの候補であると考える前に部分的に開いているか終わりのフェーズにおけるTCP接続が活動していないままでいなければならない最小の時と定義されます。 タイム誌_WAIT状態でのTCP接続は「一時的な接続活動していないタイムアウト」で影響を受けません。
REQ-5: If a NAT cannot determine whether the endpoints of a TCP
connection are active, it MAY abandon the session if it has been
idle for some time. In such cases, the value of the "established
connection idle-timeout" MUST NOT be less than 2 hours 4 minutes.
The value of the "transitory connection idle-timeout" MUST NOT be
less than 4 minutes.
a) The value of the NAT idle-timeouts MAY be configurable.
REQ-5: それがしばらく活動していなく、NATが、TCP接続の終点がアクティブであるかどうか決定できないなら、それはセッションを捨てるかもしれません。 そのような場合では、「確立した接続アイドルタイムアウト」の値は2時間4分より少ないはずがありません。 「一時的な接続アイドルタイムアウト」の値は4分a)以下であるはずがありません。 NATアイドルタイムアウトの値は構成可能であるかもしれません。
Justification: The intent of this requirement is to minimize the
cases where a NAT abandons session state for a live connection.
While some NATs may choose to abandon sessions reactively in
response to new connection initiations (allowing idle connections
to stay up indefinitely in the absence of new initiations), other
NATs may choose to proactively reap idle sessions. In cases where
the NAT cannot actively determine if the connection is alive, this
requirement ensures that applications can send keep-alive packets
at the default rate (every 2 hours) such that the NAT can
passively determine that the connection is alive. The additional
4 minutes allows time for in-flight packets to cross the NAT.
正当化: この要件の意図はNATが活動的な接続のためにセッション状態を捨てるケースを最小にすることです。 いくつかのNATsが、新しい接続開始に対応してセッションを反動的に捨てるのを選んでいるかもしれない間(無駄な接続が新しい開始が不在のとき無期限に寝ずに起きているのを許容して)、他のNATsは、無駄なセッションを予測して獲得するのを選ぶかもしれません。 NATが接続が生きているかどうか活発に決定できない場合では、この要件は、NATが、接続が生きていることを受け身に決定できるようにアプリケーションがデフォルトレート(2時間毎)でキープアライブパケットを送ることができるのを確実にします。 追加4個の議事録が機内のパケットがNATを越える時間を許容します。
NAT behavior for handling RST packets, or connections in TIME_WAIT state is left unspecified. A NAT MAY hold state for a connection in TIME_WAIT state to accommodate retransmissions of the last ACK. However, since the TIME_WAIT state is commonly encountered by internal endpoints properly closing the TCP connection, holding state for a closed connection may limit the throughput of connections through a NAT with limited resources. [RFC1337] describes hazards associated with TIME_WAIT assassination.
NATは不特定のままにされます取り扱いRSTパケットのための振舞い、またはタイム誌_WAITでの接続が、述べる。 タイム誌_WAIT状態での接続が最後のACKの「再-トランスミッション」を収容するように、NATは状態を保持するかもしれません。 しかしながら、タイム誌_WAIT状態が適切にTCP接続を終える内部の終点で一般的に遭遇するので、閉じている接続のための状態を保持すると、接続に関するスループットはNATを通して限りある資源で制限されるかもしれません。 [RFC1337]はタイム誌_WAIT暗殺に関連している危険について説明します。
The handling of non-SYN packets for connections for which there is no active mapping is left unspecified. Such packets may be received if the NAT silently abandons a live connection, or abandons a connection in TIME_WAIT state before the 4 minute TIME_WAIT period expires. The decision to either silently drop such packets or to respond with a TCP RST packet is left up to the implementation.
どんなアクティブなマッピングもない接続のための非SYNパケットの取り扱いは不特定のままにされます。 そのようなパケットは、NATが静かに活動的な接続を捨てるなら受けるかもしれないか、または4分のタイム誌_WAIT授業時間が期限が切れる前にタイム誌_WAIT状態で接続を捨てます。 静かにそのようなパケットを下げるか、またはTCP RSTパケットで応じるという決定は実装に任せられます。
Guha, et al. Best Current Practice [Page 11] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[11ページ]RFC5382NAT TCP要件2008年10月
NAT behavior for notifying endpoints when abandoning live connections is left unspecified. When a NAT abandons a live connection, for example due to a timeout expiring, the NAT MAY either send TCP RST packets to the endpoints or MAY silently abandon the connection.
活動的な接続を捨てるとき終点に通知するためのNATの振舞いは不特定のままにされます。 NATが活動的な接続を捨てるとき、例えばタイムアウトへの支払われるべきものが期限が切れる場合、NATは、終点へのパケットをTCP RSTに送るか、または静かに接続を捨てるかもしれません。
Sending a RST notification allows endpoint applications to recover more quickly; however, notifying the endpoints may not always be possible if, for example, session state is lost due to a power failure.
RST通知を送るのに、終点アプリケーションは、よりはやく回復します。 しかしながら、例えば、セッション状態が停電のため失われているなら、終点に通知するのはいつも可能であるかもしれないというわけではありません。
6. Application Level Gateways
6. アプリケーションレベルゲートウェイ
Application Level Gateways (ALGs) in certain NATs modify IP addresses and TCP ports embedded inside application protocols. Such ALGs may interfere with UNSAF methods or protocols that try to be NAT-aware and must therefore be used with extreme caution.
あるNATsのアプリケーションLevel Gateways(ALGs)はアプリケーション・プロトコルで埋め込まれたIPアドレスとTCPポートを変更します。 そのようなALGsをNAT意識するようになろうとするUNSAFメソッドかプロトコルを妨げるかもしれなくて、したがって、細心の注意を払って使用しなければなりません。
REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED
that all of those ALGs (except for FTP [RFC0959]) be disabled by
default.
REQ-6: NATがTCPに影響するALGsを含んでいるなら、それらのALGs(FTP[RFC0959]を除いた)のすべてがデフォルトで無効にされるのは、RECOMMENDEDです。
Justification: The intent of this requirement is to prevent ALGs
from interfering with UNSAF methods. The default state of an FTP
ALG is left unspecified because of legacy concerns: as of writing
this memo, a large fraction of legacy FTP clients do not enable
passive (PASV) mode by default and require an ALG to traverse
NATs.
正当化: この要件の意図はALGsがUNSAFメソッドを妨げるのを防ぐことです。 FTP ALGのデフォルト州はレガシー関心のために不特定のままにされます: このメモを書く現在、レガシーFTPクライアントの大きい部分は、デフォルトで受け身の(PASV)モードを可能にして、ALGがNATsを横断するのを必要としません。
7. Other Requirements Applicable to TCP
7. TCPに適切な他の要件
A list of general and UDP-specific NAT behavioral requirements are described in [BEHAVE-UDP]. A list of ICMP-specific NAT behavioral requirements are described in [BEHAVE-ICMP]. The requirements listed below reiterate the requirements from these two documents that directly affect TCP. The following requirements do not relax any requirements in [BEHAVE-UDP] or [BEHAVE-ICMP].
行動の要件が説明される一般的でUDP特有のNAT[BEHAVE-UDP]のリスト。 行動の要件が説明されるICMP特有のNAT[BEHAVE-ICMP]のリスト。 以下にリストアップされた要件は直接TCPに影響するこれらの2通のドキュメントからの要件を繰り返します。 以下の要件は[BEHAVE-UDP]か[BEHAVE-ICMP]のどんな要件も弛緩しません。
7.1. Port Assignment
7.1. ポート課題
NATs that allow different internal endpoints to simultaneously use the same mapping are defined in [BEHAVE-UDP] to have a "Port assignment" behavior of "Port overloading". Such behavior is undesirable, as it prevents two internal endpoints sharing the same mapping from establishing simultaneous connections to a common external endpoint.
異なった内部の終点に同時に同じマッピングを使用させるNATsは、「ポート積みすぎ」の「ポート課題」の振舞いを持つために[BEHAVE-UDP]で定義されます。 そのような振舞いは望ましくありません、同じマッピングを共有する2つの内部の終点が一般的な外部の終点に同時接続を確立するのを防ぐとき。
REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port
overloading" for TCP.
REQ-7: NATには、TCPのための「ポート積みすぎ」の「ポート課題」の振舞いがあってはいけません。
Guha, et al. Best Current Practice [Page 12] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[12ページ]RFC5382NAT TCP要件2008年10月
Justification: This requirement allows two applications on the
internal side of the NAT to consistently communicate with the same
destination.
正当化: この要件で、NAT内部側における2つのアプリケーションが同じ目的地で一貫して伝えます。
NAT behavior for preserving the source TCP port range for connections is left unspecified. Some applications expect the source TCP port to be in the well-known range (TCP ports from 0 to 1023). The "r" series of commands (rsh, rcp, rlogin, etc.) are an example. NATs that preserve the range from which the source port is picked allow such applications to function properly through the NAT; however, by doing so the NAT may compromise the security of the application in certain situations; applications that depend only on the IP address and source TCP port range for security (the "r" commands, for example) cannot distinguish between an attacker and a legitimate user behind the same NAT.
接続のためにソースのTCPポート範囲を保持するためのNATの振舞いは不特定のままにされます。 いくつかのアプリケーションが、ソースTCP港がよく知られる範囲(0〜1023年までのTCPポート)にあると予想します。 コマンド(rsh、rcp、rloginなど)の「r」シリーズは例です。 ソースポートが粒選りである範囲を保持するNATsがNATを通してそのようなアプリケーションを適切に機能させます。 しかしながら、そうすることによって、NATはある状況における、アプリケーションのセキュリティに感染するかもしれません。 セキュリティ(例えば、「r」コマンド)のためにIPアドレスとソースのTCPポート範囲だけによるアプリケーションは同じNATの後ろで攻撃者と正統のユーザを見分けることができません。
7.2. Hairpinning Behavior
7.2. 振舞いをHairpinningします。
NATs that forward packets originating from an internal address, destined for an external address that matches the active mapping for an internal address, back to that internal address are defined in [BEHAVE-UDP] as supporting "hairpinning". If the NAT presents the hairpinned packet with an external source IP address and port (i.e., the mapped source address and port of the originating internal endpoint), then it is defined to have "External source IP address and port" for hairpinning. Hairpinning is necessary to allow two internal endpoints (known to each other only by their external mapped addresses) to communicate with each other. "External source IP address and port" behavior for hairpinning avoids confusing implementations that expect the external source IP address and port.
内部のアドレスのためのアクティブなマッピングに合っている外部アドレスのために運命づけられた内部のアドレスから内部のそのアドレスまで起因するパケットを進めるNATsが[BEHAVE-UDP]で「hairpinning」をサポートすると定義されます。 NATが外部電源IPアドレスとポート(すなわち、起因することの内部の終点の写像しているソースアドレスとポート)でhairpinnedパケットを提示するなら、それは、hairpinningするための「外部電源IPアドレスとポート」を持つために定義されます。 Hairpinningが、2つの内部の終点(互いにおいて、単にそれらの外部の写像しているアドレスによって知られている)が互いにコミュニケートするのを許容するのに必要です。 hairpinningするための「外部電源IPアドレスとポート」の振舞いは、外部電源IPアドレスとポートを予想する実装を混乱させるのを避けます。
REQ-8: A NAT MUST support "hairpinning" for TCP.
a) A NAT's hairpinning behavior MUST be of type "External source
IP address and port".
REQ-8: NATはTCP a)のために"hairpinningする"であることをサポートしなければなりません。 振舞いがあるに違いないNATのhairpinningは「外部電源IPアドレスとポート」をタイプします。
Justification: This requirement allows two applications behind the
same NAT that are trying to communicate with each other using
their external addresses.
a) Using the external source address and port for the hairpinned
packet is necessary for applications that do not expect to
receive a packet from a different address than the external
address they are trying to communicate with.
正当化: この要件は. 互いがそれらの外部アドレスを使用しているa)を伝えようとしているのと同じNATの後ろに2つのアプリケーションを許容します。 hairpinnedパケットに外部電源アドレスとポートを使用するのがそれらが交信しようとしている外部アドレスより異なったアドレスからパケットを受けると予想しないアプリケーションに必要です。
7.3. ICMP Responses to TCP Packets
7.3. TCPパケットへのICMP応答
Several TCP mechanisms depend on the reception of ICMP error messages triggered by the transmission of TCP segments. One such mechanism is path MTU discovery [RFC1191], which is required for the correct
数個のTCPメカニズムがTCPセグメントの送信で引き起こされたICMPエラーメッセージのレセプションによります。 そのようなメカニズムの1つは経路MTU探索[RFC1191]です。(その経路MTU探索が正しさに必要です)。
Guha, et al. Best Current Practice [Page 13] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[13ページ]RFC5382NAT TCP要件2008年10月
operation of TCP. The current path MTU discovery mechanism requires the sender of TCP segments to be notified of ICMP "Datagram Too Big" responses.
TCPの操作。 現在の経路MTU探索メカニズムがICMPについて通知されるためにTCPセグメントを送付者に要求する、「データグラム、大き過ぎる、」 応答。
REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination
Unreachable (Type 3) messages.
REQ-9: NATはaであるならTCPを翻訳して、それはSHOULDです。ICMP Destination Unreachable(3をタイプする)メッセージを翻訳してください。
Justification: Translating ICMP Destination Unreachable messages,
particularly the "Fragmentation Needed and Don't Fragment was Set"
(Type 3, Code 4) message avoids communication failures ("black
holes" [RFC2923]). Furthermore, TCP's connection establishment
and maintenance mechanisms also behave much more efficiently when
ICMP Destination Unreachable messages arrive in response to
outgoing TCP segments.
正当化: ICMP Destination Unreachableメッセージを翻訳して、特に「Fragmentではなく、必要である断片化とドンがSet(3をタイプしてください、Code4)であった」メッセージは通信障害(「ブラックホール」[RFC2923])を避けます。 その上、また、ICMP Destination Unreachableメッセージが外向的なTCPセグメントに対応して到着するとき、TCPのコネクション確立とメインテナンスメカニズムははるかに効率的に振る舞います。
REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the
NAT mapping or TCP connection for which the ICMP was generated.
REQ-10: どんな種類に関するICMPメッセージの領収書もICMPが生成されたNATマッピングかTCP接続を終えてはいけません。
Justification: This is necessary for reliably performing TCP
simultaneous-open where a remote NAT may temporarily signal an
ICMP error.
正当化: これがリモートNATが一時ICMP誤りを示すかもしれないTCPの同時の戸外を確かに実行するのに必要です。
8. Requirements
8. 要件
A NAT that supports all of the mandatory requirements of this specification (i.e., the "MUST") and is compliant with [BEHAVE-UDP], is "compliant with this specification". A NAT that supports all of the requirements of this specification (i.e., included the "RECOMMENDED") and is fully compliant with [BEHAVE-UDP] is "fully compliant with all the mandatory and recommended requirements of this specification".
この仕様の義務的な要件のすべてが(すなわち、“MUST")であるとサポートしている、[UDPを反応させます]で対応であるNATは「この仕様で、言いなりになっています」。 この仕様(すなわち、「お勧め」を含んでいる)の要件のすべてをサポートしている、[UDPを反応させます]で完全に対応であるNATは「この仕様のすべての義務的でお勧めの要件で完全に言いなりになっています」。
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior
for TCP.
REQ-1: NATには、TCPのための「終点から独立しているマッピング」の振舞いがなければなりません。
REQ-2: A NAT MUST support all valid sequences of TCP packets
(defined in [RFC0793]) for connections initiated both internally
as well as externally when the connection is permitted by the NAT.
In particular:
a) In addition to handling the TCP 3-way handshake mode of
connection initiation, A NAT MUST handle the TCP simultaneous-
open mode of connection initiation.
REQ-2: NATは接続がNATによって受入れられるとき内部的に外部的に開始された接続のためにTCPパケット([RFC0793]では、定義される)のすべての有効な系列をサポートしなければなりません。 特に: a) 接続開始のTCP3ウェイ握手モードを扱うことに加えて、A NATは接続開始のTCPの同時のオープン形式を扱わなければなりません。
REQ-3: If application transparency is most important, it is
RECOMMENDED that a NAT have an "Endpoint-Independent Filtering"
behavior for TCP. If a more stringent filtering behavior is most
important, it is RECOMMENDED that a NAT have an "Address-Dependent
Filtering" behavior.
REQ-3: アプリケーション透明が最も重要であるなら、NATにはTCPのための「終点から独立しているフィルタリング」の振舞いがあるのは、RECOMMENDEDです。 より厳しいフィルタリングの振舞いが最も重要であるなら、NATには「アドレス依存するフィルタリング」の振舞いがあるのは、RECOMMENDEDです。
Guha, et al. Best Current Practice [Page 14] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[14ページ]RFC5382NAT TCP要件2008年10月
a) The filtering behavior MAY be an option configurable by the
administrator of the NAT.
b) The filtering behavior for TCP MAY be independent of the
filtering behavior for UDP.
a) フィルタリングの振舞いは. NATの管理者が構成可能なオプションがb)であったならそうするかもしれません。 TCP MAYのためのフィルタリングの振舞いはUDPのためのフィルタリングの振舞いの如何にかかわらずそうです。
REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet
for at least 6 seconds after the packet is received. If during
this interval the NAT receives and translates an outbound SYN for
the connection the NAT MUST silently drop the original unsolicited
inbound SYN packet. Otherwise, the NAT SHOULD send an ICMP Port
Unreachable error (Type 3, Code 3) for the original SYN, unless
REQ-4a applies.
a) The NAT MUST silently drop the original SYN packet if sending a
response violates the security policy of the NAT.
REQ-4: パケットが受け取られていた後にNATは少なくとも6秒間、求められていない本国行きのSYNパケットに応じてはいけません。 NATが接続のためにこの間隔の間、外国行きのSYNを受けて、翻訳するなら、NATは静かにオリジナルの求められていない本国行きのSYNパケットを下げなければなりません。 さもなければ、NAT SHOULDはオリジナルのSYNのために、ICMP Port Unreachable誤り(3をタイプしてください、Code3)を送ります、REQ-4aが. a)を適用しない場合 応答を送るとNATの安全保障政策が違反されるなら、NATは静かにオリジナルのSYNパケットを下げなければなりません。
REQ-5: If a NAT cannot determine whether the endpoints of a TCP
connection are active, it MAY abandon the session if it has been
idle for some time. In such cases, the value of the "established
connection idle-timeout" MUST NOT be less than 2 hours 4 minutes.
The value of the "transitory connection idle-timeout" MUST NOT be
less than 4 minutes.
a) The value of the NAT idle-timeouts MAY be configurable.
REQ-5: それがしばらく活動していなく、NATが、TCP接続の終点がアクティブであるかどうか決定できないなら、それはセッションを捨てるかもしれません。 そのような場合では、「確立した接続アイドルタイムアウト」の値は2時間4分より少ないはずがありません。 「一時的な接続アイドルタイムアウト」の値は4分a)以下であるはずがありません。 NATアイドルタイムアウトの値は構成可能であるかもしれません。
REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED
that all of those ALGs (except for FTP [RFC0959]) be disabled by
default.
REQ-6: NATがTCPに影響するALGsを含んでいるなら、それらのALGs(FTP[RFC0959]を除いた)のすべてがデフォルトで無効にされるのは、RECOMMENDEDです。
The following requirements reiterate requirements from [BEHAVE-UDP] or [BEHAVE-ICMP] that directly affect TCP. This document does not relax any requirements in [BEHAVE-UDP] or [BEHAVE-ICMP].
以下の要件は直接TCPに影響する[BEHAVE-UDP]か[BEHAVE-ICMP]からの要件を繰り返します。 このドキュメントは[BEHAVE-UDP]か[BEHAVE-ICMP]のどんな要件も弛緩しません。
REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port
overloading" for TCP.
REQ-7: NATには、TCPのための「ポート積みすぎ」の「ポート課題」の振舞いがあってはいけません。
REQ-8: A NAT MUST support "hairpinning" for TCP.
a) A NAT's hairpinning behavior MUST be of type "External source
IP address and port".
REQ-8: NATはTCP a)のために"hairpinningする"であることをサポートしなければなりません。 振舞いがあるに違いないNATのhairpinningは「外部電源IPアドレスとポート」をタイプします。
REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination
Unreachable (Type 3) messages.
REQ-9: NATはaであるならTCPを翻訳して、それはSHOULDです。ICMP Destination Unreachable(3をタイプする)メッセージを翻訳してください。
REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the
NAT mapping or TCP connection for which the ICMP was generated.
REQ-10: どんな種類に関するICMPメッセージの領収書もICMPが生成されたNATマッピングかTCP接続を終えてはいけません。
Guha, et al. Best Current Practice [Page 15] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[15ページ]RFC5382NAT TCP要件2008年10月
9. Security Considerations
9. セキュリティ問題
[BEHAVE-UDP] discusses security considerations for NATs that handle IP and unicast UDP traffic. Security concerns specific to handling TCP packets are discussed in this section.
[BEHAVE-UDP]はIPを扱うNATsとユニキャストUDPトラフィックのためにセキュリティ問題について議論します。 このセクションで取り扱いTCPパケットに特定の安全上の配慮について議論します。
Security considerations for REQ-1: This requirement does not
introduce any TCP-specific security concerns.
REQ-1のためのセキュリティ問題: この要件はどんなTCP特有の安全上の配慮も導入しません。
Security considerations for REQ-2: This requirement does not
introduce any TCP-specific security concerns. Simultaneous-open
and other transitions in the TCP state machine are by-design and
necessary for TCP to work correctly in all scenarios. Further,
this requirement only affects connections already in progress as
authorized by the NAT in accordance with its policy.
REQ-2のためのセキュリティ問題: この要件はどんなTCP特有の安全上の配慮も導入しません。 TCP州のマシンの同時、開いていて他の変遷は、デザインであって、TCPがすべてのシナリオで正しく扱うように、必要とします。 さらに、この要件は方針によると、NATによって認可されるように既に進行中の接続に影響するだけです。
Security considerations for REQ-3: The security provided by the NAT
is governed by its filtering behavior as addressed in
[BEHAVE-UDP]. Connection-Dependent Filtering behavior is most
secure from a firewall perspective, but severely restricts
connection initiations through a NAT. Endpoint-Independent
Filtering behavior, which is most transparent to applications,
requires an attacker to guess the IP address and port of an active
mapping in order to get his packet to an internal host. Address-
Dependent Filtering, on the other hand, is less transparent than
Endpoint-Independent Filtering but more transparent than
Connection-Dependent Filtering; it is more secure than Endpoint-
Independent Filtering as it requires an attacker to additionally
guess the address of the external endpoint for a NAT session
associated with the mapping and be able to receive packets
addressed to the same. While this protects against most attackers
on the Internet, it does not necessarily protect against attacks
that originate from behind a remote NAT with a single IP address
that is also translating a legitimate connection to the victim.
REQ-3のためのセキュリティ問題: [BEHAVE-UDP]で扱われるように振舞いをフィルターにかけることによって、NATによって提供されたセキュリティは決定されます。 接続依存するFilteringの振舞いは、ファイアウォール見解から最も安全ですが、NATを通して厳しく接続開始を制限します。 終点から独立しているFilteringの振舞い(アプリケーションに最もわかりやすい)は、内部のホストに彼のパケットを届けるために攻撃者がアクティブなマッピングのIPアドレスとポートを推測するのを必要とします。 他方では、アドレスの依存するFilteringは、より透明ではありませんが、Connection依存するFilteringよりEndpointから独立しているFilteringより透明です。 マッピングに関連しているNATセッションのためにさらに、外部の終点のアドレスを推測して、同じくらいに扱われたパケットは受けることができるのが攻撃者を必要とするとき、それがEndpointの独立しているFilteringより安全です。 これがインターネットのほとんどの攻撃者から守っている間、それは必ずまた、正統の接続を翻訳しているただ一つのIPアドレスがあるリモートNATから犠牲者まで起因する攻撃から守るというわけではありません。
Security considerations for REQ-4: This document recommends that a
NAT respond to unsolicited inbound SYN packets with an ICMP error
delayed by a few seconds. Doing so may reveal the presence of a
NAT to an external attacker. Silently dropping the SYN makes it
harder to diagnose network problems and forces applications to
wait for the TCP stack to finish several retransmissions before
reporting an error. An implementer must therefore understand and
carefully weigh the effects of not sending an ICMP error or rate-
limiting such ICMP errors to a very small number.
REQ-4のためのセキュリティ問題: このドキュメントは、ICMP誤りが数秒までに遅れていてNATが求められていない本国行きのSYNパケットに応じることを勧めます。 そうするのは外部の攻撃者にNATの存在を明らかにするかもしれません。 静かにSYNを下げるので、ネットワーク問題を診断するのをより困難にして、アプリケーションは、誤りを報告する前にTCPスタックが数個の「再-トランスミッション」を終えるのをやむを得ず待ちます。 implementerはしたがって、分かって、慎重に、ICMP誤りかレートにそのようなICMP誤りを非常に少ない数に制限させないという効果の重さがなければなりません。
Guha, et al. Best Current Practice [Page 16] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[16ページ]RFC5382NAT TCP要件2008年10月
Security considerations for REQ-5: This document recommends that a
NAT that passively monitors TCP state keep idle sessions alive for
at least 2 hours 4 minutes or 4 minutes depending on the state of
the connection. If a NAT is under attack, it may attempt to
actively determine the liveliness of a TCP connection or let the
NAT administrator configure more conservative timeouts.
REQ-5のためのセキュリティ問題: このドキュメントは、TCP状態を受け身にモニターするNATが少なくとも2時間4分か4分間接続の状態に依存するために無駄なセッションを生かすことを勧めます。 NATは攻撃されているなら、それが、活発にTCP接続の活気を決定するか、またはNAT管理者により保守的なタイムアウトを構成させるのを試みるかもしれません。
Security considerations for REQ-6: This requirement does not
introduce any TCP-specific security concerns.
REQ-6のためのセキュリティ問題: この要件はどんなTCP特有の安全上の配慮も導入しません。
Security considerations for REQ-7: This requirement does not
introduce any TCP-specific security concerns.
REQ-7のためのセキュリティ問題: この要件はどんなTCP特有の安全上の配慮も導入しません。
Security considerations for REQ-8: This requirement does not
introduce any TCP-specific security concerns.
REQ-8のためのセキュリティ問題: この要件はどんなTCP特有の安全上の配慮も導入しません。
Security considerations for REQ-9: This requirement does not
introduce any TCP-specific security concerns.
REQ-9のためのセキュリティ問題: この要件はどんなTCP特有の安全上の配慮も導入しません。
Security considerations for REQ-10: This requirement does not
introduce any TCP-specific security concerns.
REQ-10のためのセキュリティ問題: この要件はどんなTCP特有の安全上の配慮も導入しません。
NAT implementations that modify TCP sequence numbers (e.g., for privacy reasons or for ALG support) must ensure that TCP packets with Selective Acknowledgement (SACK) notifications [RFC2018] are properly handled.
TCP一連番号(例えば、プライバシー理由かALGサポートのための)を変更するNAT実装は、Selective Acknowledgement(SACK)通知[RFC2018]があるTCPパケットが適切に扱われるのを確実にしなければなりません。
NAT implementations that modify local state based on TCP flags in packets must ensure that out-of-window TCP packets are properly handled. [RFC4953] summarizes and discusses a variety of solutions designed to prevent attackers from affecting TCP connections.
パケットでTCP旗に基づく地方の状態を変更するNAT実装は、窓の外では、TCPパケットが適切に扱われるのを確実にしなければなりません。 [RFC4953]は、攻撃者がTCP接続に影響するのを防ぐように設計されたさまざまなソリューションについて、まとめて、議論します。
10. Acknowledgments
10. 承認
Joe Touch contributed the mechanism for handling unsolicited inbound SYNs. Thanks to Mark Allman, Francois Audet, Lars Eggert, Paul Francis, Fernando Gont, Sam Hartman, Paul Hoffman, Dave Hudson, Cullen Jennings, Philip Matthews, Tom Petch, Magnus Westerlund, and Dan Wing for their many contributions, comments, and suggestions.
ジョーTouchは取り扱いの求められていない本国行きのSYNsのためにメカニズムを寄付しました。 彼らの多くの貢献、コメント、および提案をマーク・オールマン、フランソアAudet、ラース・エッゲルト、ポール・フランシス、フェルナンドGont、サム・ハートマン、ポール・ホフマン、デーヴ・ハドソン、Cullenジョニングス、フィリップ・マシューズ、トムPetch、マグヌスWesterlund、およびダンWingをありがとうございます。
Guha, et al. Best Current Practice [Page 17] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[17ページ]RFC5382NAT TCP要件2008年10月
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[BEHAVE-UDP] Audet, F. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, January 2007.
[UDPを反応させます]のAudet(F.とC.ジョニングス)は「ユニキャストUDPのためのアドレス変換(NAT)の行動の要件をネットワークでつなぎます」、BCP127、RFC4787、2007年1月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC0793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[RFC0959] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery",
RFC 1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
11.2. Informational References
11.2. 情報の参照
[BEHAVE-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha,
"NAT Behavioral Requirements for ICMP protocol", Work
in Progress, June 2008.
[BEHAVE-ICMP] SrisureshとP.とフォードとB.とSivakumar、S.とS.グーハ、「ICMPのためのNAT Behavioral Requirementsは議定書を作る」Progress(2008年6月)のWork。
[NAT-MIB] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N.,
and C. Wang, "Definitions of Managed Objects for
Network Address Translators (NAT)", RFC 4008,
March 2005.
[NAT-MIB] Rohit、R.、Srisuresh、P.、Raghunarayan、R.、パイ、N.、およびC.ワング、「ネットワークのための管理オブジェクトの定義は翻訳者(NAT)に演説します」、RFC4008、2005年3月。
[NATBLASTER] Biggadike, A., Ferullo, D., Wilson, G., and A. Perrig,
"NATBLASTER: Establishing TCP connections between
hosts behind NATs", Proceedings of the ACM SIGCOMM
Asia Workshop (Beijing, China), April 2005.
[NATBLASTER] Biggadike、A.、Ferullo、D.、ウィルソン、G.、およびA.Perrig、「NATBLASTER:」 「NATsの後ろでホストの間のTCP接続を確立します」、ACM SIGCOMMアジアWorkshop(北京(中国))、2005年4月のProceedings。
[P2PNAT] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-peer
communication across network address translators",
Proceedings of the USENIX Annual Technical
Conference (Anaheim, CA), April 2005.
USENIX Annual Technicalコンファレンス(アナハイム(カリフォルニア))(2005年4月)の[P2PNAT]フォードとB.とSrisuresh、P.とD.ケーゲル、「ネットワークアドレス変換機構の向こう側のピアツーピアコミュニケーション」Proceedings。
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
RFC 1337, May 1992.
[RFC1337]ブレーデン(B.、「TCPの時間待ち暗殺危険」、RFC1337)は1992がそうするかもしれません。
Guha, et al. Best Current Practice [Page 18] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[18ページ]RFC5382NAT TCP要件2008年10月
[RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions
Functional Specification", RFC 1644, July 1994.
[RFC1644]ブレーデン、B.、「T/TCP--、トランザクションに、機能的なTCP拡張子、仕様、」、RFC1644、7月1994日
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow,
"TCP Selective Acknowledgment Options", RFC 2018,
October 1996.
[RFC2018] マシスとM.とMahdaviとJ.とフロイド、S.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。
[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)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, September 2000.
[RFC2923] レーヒー、K.、「経路MTU発見に関するTCP問題」、RFC2923、2000年9月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3022] SrisureshとP.とK.Egevang、「伝統的なIPネットワークアドレス変換機構(伝統的なNAT)」、RFC3022、2001年1月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A
Roadmap for Transmission Control Protocol (TCP)
Specification Documents", RFC 4614, September 2006.
[RFC4614] デューク、M.、ブレーデン、R.、渦巻、W.、およびE.ブラントン、「通信制御プロトコル(TCP)仕様ドキュメントのための道路地図」、RFC4614(2006年9月)。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007.
[RFC4953] 2007年7月の接触、J.、「スプーフィング攻撃に対する防御しているTCP」RFC4953。
[STUNT] Guha, S. and P. Francis, "NUTSS: A SIP based approach
to UDP and TCP connectivity", Proceedings of the ACM
SIGCOMM Workshop on Future Directions in Network
Architecture (Portland, OR), August 2004.
[妨げます] グーハ、S.、およびP.フランシス、「NUTSS:」 「SIPはUDPへのアプローチとTCPの接続性を基礎づけました」、Network Architecture(ポートランド(OR))のFuture Directionsの上のACM SIGCOMM WorkshopのProceedings、2004年8月。
[TCPTRAV] Guha, S. and P. Francis, "Characterization and
Measurement of TCP Traversal through NATs and
Firewalls", Proceedings of the Internet Measurement
Conference (Berkeley, CA), October 2005.
[TCPTRAV] グーハ、S.、P.フランシス、および「NATsとファイアウォールを通したTCP縦断の特殊化と測定」、インターネット測定コンファレンス(バークレー(カリフォルニア))(2005年10月)の議事
Guha, et al. Best Current Practice [Page 19] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[19ページ]RFC5382NAT TCP要件2008年10月
Authors' Addresses
作者のアドレス
Saikat Guha (editor) Cornell University 331 Upson Hall Ithaca, NY 14853 US Phone: +1 607 255 1008 EMail: saikat@cs.cornell.edu
Saikatグーハ(エディタ)コーネル大学331Upson Hallニューヨーク14853イタケー(米国)は以下に電話をします。 +1 1008年の607 255メール: saikat@cs.cornell.edu
Kaushik Biswas Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 US Phone: +1 408 525 5134 EMail: kbiswas@cisco.com
カウシィクビスワスシスコシステムズInc.170西タスマン博士カリフォルニア95134サンノゼ(米国)は以下に電話をします。 +1 5134年の408 525メール: kbiswas@cisco.com
Bryan Ford Max Planck Institute for Software Systems Campus Building E1 4 D-66123 Saarbruecken Germany Phone: +49-681-9325657 EMail: baford@mpi-sws.org
E1 4D-66123 Saarbrueckenドイツ電話を組立てるソフトウェア・システムキャンパスのブライアンフォードマックスプランク研究所: +49-681-9325657はメールされます: baford@mpi-sws.org
Senthil Sivakumar Cisco Systems, Inc. 7100-8 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709-4987 US Phone: +1 919 392 5158 EMail: ssenthil@cisco.com
Senthil SivakumarシスコシステムズInc.7100-8はクリーク道路私書箱14987リサーチトライアングル公園、NC27709-4987米国電話に装備します: +1 5158年の919 392メール: ssenthil@cisco.com
Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 US Phone: +1 408 836 4773 EMail: srisuresh@yahoo.com
Pyda Srisuresh KazeonシステムInc.1161サンアントニオ、通り カリフォルニア94043マウンテンビュー(米国)は以下に電話をします。 +1 4773年の408 836メール: srisuresh@yahoo.com
Guha, et al. Best Current Practice [Page 20] RFC 5382 NAT TCP Requirements October 2008
グーハ、他 最も良い現在の練習[20ページ]RFC5382NAT TCP要件2008年10月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Guha, et al. Best Current Practice [Page 21]
グーハ、他 最も良い現在の習慣[21ページ]
一覧
スポンサーリンク
