Network Working Group N. Spring
Request for Comments: 3540 D. Wetherall
Category: Experimental D. Ely
University of Washington
June 2003
Robust Explicit Congestion Notification (ECN)
Signaling with Nonces
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts.
このノートでは、明示的輻輳通知（ECN）-nonce、TCPの送信者からマークされたパケットの偶発的または悪質な隠蔽から保護ECNへのオプションの追加について説明します。これは、ネットワーク帯域幅の不当なシェアを獲得するためにECNを利用するから、受信機を防止することにより、輻輳制御のロバスト性を向上させることができます。 ECN-ノンスは、IPヘッダのECNフィールド二つECN-可能なトランスポート（ECT）コードポイントを使用し、TCPヘッダ内のフラグを必要とします。これは、ルータとホストの両方のための計算上効率的です。
Statement of Intent
主旨書
This specification describes an optional addition to Explicit Congestion Notification [RFC3168] improving its robustness against malicious or accidental concealment of marked packets. It has not been deployed widely. One goal of publication as an Experimental RFC is to be prudent, and encourage use and deployment prior to publication in the standards track. Another consideration is to give time for firewall developers to recognize and accept the pattern presented by the nonce. It is the intent of the Transport Area Working Group to re-submit this specification as an IETF Proposed Standard in the future after more experience has been gained.
この仕様は、マークされたパケットの悪意のあるまたは偶発隠蔽に対する堅牢性を向上明示的輻輳通知[RFC3168]へのオプションの追加について説明します。これは、広く展開されていません。実験的RFCとして公表の一つの目標は、賢明では、前の基準トラックでの出版物への使用と導入を奨励することです。もう1つの考慮事項は、ナンスによって提示されたパターンを認識し、受け入れるようにファイアウォールの開発者のための時間を与えることです。より多くの経験が得られた後、将来的にIETFのProposed Standardとして、この明細書を再提出する交通地域ワーキンググループの意図です。
The correct operation of ECN requires the cooperation of the receiver to return Congestion Experienced signals to the sender, but the protocol lacks a mechanism to enforce this cooperation. This raises the possibility that an unscrupulous or poorly implemented receiver could always clear ECN-Echo and simply not return congestion signals to the sender. This would give the receiver a performance advantage at the expense of competing connections that behave properly. More generally, any device along the path (NAT box, firewall, QOS bandwidth shapers, and so forth) could remove congestion marks with impunity.
ECNの正しい動作は、送信者に輻輳経験信号を戻すために受信機の協力を必要とするが、このプロトコルは、この協力を強制するためのメカニズムを欠いています。これは不謹慎なまたは不十分実装受信機は必ずしも明確ECN-エコーと単に送信者に混雑信号を返すことができなかった可能性が高まります。これは、適切に動作し、競合する接続を犠牲にして受信機にパフォーマンス上の優位性を与えるだろう。より一般的には、パス（NATボックス、などのファイアウォール、QOSの帯域幅整形器、および）に沿った任意のデバイスが大手を振って、輻輳マークを削除することができます。
The above behaviors may or may not constitute a threat to the operation of congestion control in the Internet. However, given the central role of congestion control, it is prudent to design the ECN signaling loop to be robust against as many threats as possible. In this way, ECN can provide a clear incentive for improvement over the prior state-of-the-art without potential incentives for abuse. The ECN-nonce is a simple, efficient mechanism to eliminate the potential abuse of ECN.
上記動作は、またはインターネットにおける輻輳制御の動作への脅威を構成してもしなくてもよいです。しかし、輻輳制御の中心的な役割を考えると、できるだけ多くの脅威に対する堅牢にECNシグナリングループを設計することが賢明です。このように、ECNは、乱用の可能性のインセンティブなし前最先端の上改善の明確なインセンティブを提供することができます。 ECN-ノンスは、ECNの潜在的な乱用を排除するための簡単で効率的なメカニズムです。
The ECN-nonce enables the sender to verify the correct behavior of the ECN receiver and that there is no other interference that conceals marked (or dropped) packets in the signaling path. The ECN-nonce protects against both implementation errors and deliberate abuse. The ECN-nonce:
ECN-ノンスは、ECN受信機の正しい動作を確認し、マークされた（または削除）隠蔽他の干渉が存在しないことを送信者を可能にするシグナリング経路におけるパケット。 ECN-nonceが実装エラーや意図的な虐待の両方を保護します。 ECN-ナンス：
- catches a misbehaving receiver with a high probability, and never implicates an innocent receiver.
- 高い確率で誤動作受信機をキャッチし、無実の受信機を暗示することはありません。
- does not change other aspects of ECN, nor does it reduce the benefits of ECN for behaving receivers.
- ECNの他の側面を変更しません。また、受信機の行動のためのECNの利益を減らすん。
- is cheap in both per-packet overhead (one TCP header flag) and processing requirements.
- 両方のパケットごとのオーバヘッド（1つのTCPヘッダフラグ）と処理要件に安価です。
- is simple and, to the best of our knowledge, not prone to other attacks.
- その他の攻撃を受けやすい、シンプルで、私たちの知る限りではありません。
We also note that use of the ECN-nonce has two additional benefits, even when only drop-tail routers are used. First, packet drops cannot be concealed from the sender. Second, it prevents optimistic acknowledgements [Savage], in which TCP segments are acknowledged before they have been received. These benefits also serve to increase the robustness of congestion control from attacks. We do not elaborate on these benefits in this document.
また、ECN-ナンスの使用が唯一のドロップテールルータが使用されている場合でも、二つの追加の利点を持って注意してください。まず、パケットドロップは、送信者から隠蔽することができません。第二に、それは彼らが受信されている前に、TCPセグメントが確認されている楽観謝辞[サベージ]を、防ぐことができます。これらの利点はまた、攻撃から輻輳制御の堅牢性を高めるのに役立ちます。私たちは、この文書のこれらの利点について詳しく説明しません。
The rest of this document describes the ECN-nonce. We present an overview followed by detailed behavior at senders and receivers.
このドキュメントの残りの部分は、ECN-nonceを説明しています。私たちは、送信側と受信側での詳細な行動が続くの概要を提示します。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
彼らは、この文書に表示される[RFC2119]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
The ECN-nonce builds on the existing ECN-Echo and Congestion Window Reduced (CWR) signaling mechanism. Familiarity with ECN [ECN] is assumed. For simplicity, we describe the ECN-nonce in one direction only, though it is run in both directions in parallel.
ECN-ナンス機構シグナリング低減既存のECN-エコーおよび輻輳ウィンドウ（CWR）上に構築します。 ECN [ECN]精通が仮定されます。それが並列に両方向に実行されても簡単にするために、我々は、一方向にのみECN-nonceを記述する。
The ECN protocol for TCP remains unchanged, except for the definition of a new field in the TCP header. As in [RFC3168], ECT(0) or ECT(1) (ECN-Capable Transport) is set in the ECN field of the IP header on outgoing packets. Congested routers change this field to CE (Congestion Experienced). When TCP receivers notice CE, the ECE (ECN-Echo) flag is set in subsequent acknowledgements until receiving a CWR flag. The CWR flag is sent on new data whenever the sender reacts to congestion.
TCPのためのECNプロトコルは、TCPヘッダ内の新しいフィールドの定義を除いて、変更されません。 [RFC3168]のように、ECT（0）かECT（1）（ECN-可能なトランスポート）が発信パケットのIPヘッダのECNフィールドに設定されています。混雑ルータは、CE（経験豊富な輻輳）に、このフィールドを変更します。 TCP受信機はCEに気づく場合、ECE（ECN-エコー）フラグはCWRフラグを受信するまで、後続の確認応答に設定されています。 CWRフラグは、送信者が輻輳に反応するたびに新しいデータに送信されます。
The ECN-nonce adds to this protocol, and enables the receiver to demonstrate to the sender that segments being acknowledged were received unmarked. A random one-bit value (a nonce) is encoded in the two ECT codepoints. The one-bit sum of these nonces is returned in a TCP header flag, the nonce sum (NS) bit. Packet marking erases the nonce value in the ECT codepoints because CE overwrites both ECN IP header bits. Since each nonce is required to calculate the sum, the correct nonce sum implies receipt of only unmarked packets. Not only are receivers prevented from concealing marked packets, middle-boxes along the network path cannot unmark a packet without successfully guessing the value of the original nonce.
ECN-ナンスは、このプロトコルに追加され、承認されたセグメントをマークされていない受信された送信者に示すために受信機を可能にします。ランダムな1ビットの値（ノンス）は、2つのECTコードポイントで符号化されます。これらナンスの1ビットの和はノンス合計（NS）ビット、TCPヘッダフラグに戻されます。 CEは、ECN IPヘッダビットの両方を上書きするため、パケットマーキングは、ECTコードポイントにノンス値を消去します。各ナンスは、合計を計算する必要があるため、正しいナンス和は、マークされていないパケットの受信を意味しています。だけでなく、ネットワーク経路に沿ってマークされたパケットを隠すことが防止レシーバ、中間ボックスは成功し、元のナンスの値を推測することなく、パケットのマークを解除することはできませんされています。
The sender can verify the nonce sum returned by the receiver to ensure that congestion indications in the form of marked (or dropped) packets are not being concealed. Because the nonce sum is only one bit long, senders have a 50-50 chance of catching a lying receiver whenever an acknowledgement conceals a mark. Because each acknowledgement is an independent trial, cheaters will be caught quickly if there are repeated congestion signals.
送信者が隠蔽されていないマーク（または削除）パケットの形でその輻輳表示を確実にするために受信側によって返さナンス和を検証することができます。ナンス合計が1ビットだけ長いため、送信者は受信確認マークを隠したときに横たわっている受信機を引くの50-50チャンスがあります。各確認が独立した試験であるので繰り返し輻輳信号が存在する場合、詐欺師はすぐにキャッチされます。
The following paragraphs describe aspects of the ECN-nonce protocol in greater detail.
以下の段落は、より詳細にECN-ノンスプロトコルの態様を説明します。
Each acknowledgement carries a nonce sum, which is the one bit sum (exclusive-or, or parity) of nonces over the byte range represented by the acknowledgement. The sum is used because not every packet is acknowledged individually, nor are packets acknowledged reliably. If a sum were not used, the nonce in an unmarked packet could be echoed to prove to the sender that the individual packet arrived unmarked. However, since these acks are not reliably delivered, the sender could not distinguish a lost ACK from one that was never sent in order to conceal a marked packet. The nonce sum prevents the receiver from concealing individual marked packets by not acknowledging them. Because the nonce and nonce sum are both one bit quantities, the sum is no easier to guess than the individual nonces. We show the nonce sum calculation below in Figure 1.
各肯定応答は、肯定応答で表されるバイト範囲にわたってナンスの1ビットの和（排他的論理和、またはパリティ）であるナンス和を運びます。いないすべてのパケットが個別に承認され、またパケットが確実に認められているので、合計が使用されています。和は使用されなかった場合は、マークされていないパケット内のナンスは、個々のパケットがマークされていない到着した送信者に証明するためにエコーすることができます。これらのACKが確実に配信されませんので、送信者は、マークされたパケットを隠すために送信されていませんでした1から失われたACKを区別することができませんでした。ナンス合計は、それらを認めないことで、個々のマークされたパケットを隠すから受信を防ぐことができます。ナンスとナンス合計は、両方の1ビット量であるため、合計は、個々のナンスより推測する何が容易ではありません。私たちは、図1の下のナンス和演算を示しています。
Sender Receiver
initial sum = 1
-- 1:4 ECT(0) --> NS = 1 + 0(1:4) = 1(:4)
<- ACK 4, NS=1 ---
-- 4:8 ECT(1) --> NS = 1(:4) + 1(4:8) = 0(:8)
<- ACK 8, NS=0 ---
-- 8:12 ECT(1) -> NS = 0(:8) + 1(8:12) = 1(:12)
<- ACK 12, NS=1 --
-- 12:16 ECT(1) -> NS = 1(:12) + 1(12:16) = 0(:16)
<- ACK 16, NS=0 --
Figure 1: The calculation of nonce sums at the receiver.
図1：受信機でナンス和の計算。
After congestion has occurred and packets have been marked or lost, resynchronization of the sender and receiver nonce sums is needed. When packets are marked, the nonce is cleared, and the sum of the nonces at the receiver will no longer match the sum at the sender. Once nonces have been lost, the difference between sender and receiver nonce sums is constant until there is further loss. This means that it is possible to resynchronize the sender and receiver after congestion by having the sender set its nonce sum to that of the receiver. Because congestion indications do not need to be conveyed more frequently than once per round trip, the sender suspends checking while the CWR signal is being delivered and resets its nonce sum to the receiver's when new data is acknowledged. This has the benefit that the receiver is not explicitly involved in the re-synchronization process. The resynchronization process is shown in Figure 2 below. Note that the nonce sum returned in ACK 12 (NS=0) differs from that in the previous example (NS=1), and it continues to differ for ACK 16.
輻輳が発生していると、パケットがマークされたり失われた後、送信者と受信者ナンス和の再同期が必要とされています。パケットがマークされている場合は、nonceがクリアされ、受信機でのナンスの合計は、もはや、送信側で合計と一致しません。ナンスが失われた後、さらに損失があるまで、送信者と受信者ナンス和の間の差は一定です。送信者が受信者のそれにそのナンスの合計を設定したことにより、輻輳した後、送信者と受信者を再同期することが可能であることを意味しています。混雑兆候がより頻繁に一度の往復あたりよりも搬送する必要がないため、送信者はCWR信号が配信されている間にチェックを一時停止し、受信機の新しいデータが確認されたときにそのナンスの合計をリセットします。これは、受信機が明示的に再同期プロセスに関与しないという利点があります。再同期プロセスは、以下の図2に示されています。ナンス和がACK 12に返さことに留意されたい（NS = 0）、前の例とは異なる（NS = 1）、それはACK 16異なりし続けます。
Sender Receiver initial sum = 1 -- 1:4 ECT(0) -> NS = 1 + 0(1:4) = 1(:4) <- ACK 4, NS=1 -- -- 4:8 ECT(1) -> CE -> NS = 1(:4) + ?(4:8) = 1(:8) <- ACK 8, ECE NS=1 -- -- 8:12 ECT(1), CWR -> NS = 1(:8) + 1(8:12) = 0(:12) <- ACK 12, NS=0 -- -- 12:16 ECT(1) -> NS = 0(:12) + 1(12:16) = 1(:16) <- ACK 16, NS=1 --
センダレシーバcychwynnol合計= 1 - 1：4 ECT（0） - > NS = 1 + 0（1：4）= 1（4）< - ACK 4、NS = 1 - - 4：8 ECT（ 1） - > CE - > NS = 1（4）+（4：8）= 1（8）< - ACK 8、ECEのNS = 1 - - 8時12 ECT（1）、CWR - > NS = 1（8）+ 1（8時12分）= 0（12）< - ACK 12、NS = 0 - - 12：16 ECT（1） - > NS = 0（12）+ 1（12時16分）= 1（16）< - ACK 16、NS = 1 -
Figure 2: The calculation of nonce sums at the receiver when a packet (4:8) is marked. The receiver may calculate the wrong nonce sum when the original nonce information is lost after a packet is marked.
図2：（：8 4）とマークされたパケットは、受信機におけるノンス和の計算。パケットがマークされた後、元の一回だけの情報が失われたとき、受信機は、間違ったナンスの合計を計算することができます。
Third, we need to reconcile that nonces are sent with packets but acknowledgements cover byte ranges. Acknowledged byte boundaries need not match the transmitted boundaries, and information can be retransmitted in packets with different byte boundaries. We discuss the first issue, how a receiver sets a nonce when acknowledging part of a segment, in Section 6.1. The second question, what nonce to send when retransmitting smaller segments as a large segment, has a simple answer: ECN is disabled for retransmissions, so can carry no nonce. Because retransmissions are associated with congestion events, nonce checking is suspended until after CWR is acknowledged and the congestion event is over.
第三に、我々はナンスがパケットを送ったが、確認応答がバイト範囲をカバーしていることを調整する必要があります。 ADIは、バイト境界では、送信の境界を一致させる必要はありません、との情報が異なるバイト境界を持つパケットで再送することができます。私たちは、6.1節で、セグメントの一部を認めたときに、受信機がnonceを設定する方法最初の問題を、議論します。 ECNは、再送信のために無効になっているので、何のnonceを運ぶことができません：2つ目の質問、大きなセグメントとして小さなセグメントを再送信する際にどのようなナンス送信するためには、単純な答えを持っています。再送が輻輳イベントに関連付けられているので、一回だけのチェックがCWRが確認され、輻輳イベントが終わった後まで中断されます。
The next sections describe the detailed behavior of senders, routers and receivers, starting with sender transmit behavior, then around the ECN signaling loop, and finish with sender acknowledgement processing.
次のセクションでは、次に、ECNシグナリングループの周囲に、送信側の送信動作で始まり、送信者、ルータと受信機の詳細な動作を記述し、送信者確認処理で終了します。
Senders manage CWR and ECN-Echo as before. In addition, they must place nonces on packets as they are transmitted and check the validity of the nonce sums in acknowledgments as they are received. This section describes the transmit process.
送信者は、以前のようにCWRとECN-エコーを管理します。彼らが送信されているよう加えて、彼らはパケットのナンスを配置する必要があり、それらが受信される確認応答にナンス和の妥当性を確認してください。このセクションでは、送信プロセスについて説明します。
To place a one bit nonce value on every ECN-capable IP packet, the sender uses the two ECT codepoints: ECT(0) represents a nonce of 0, and ECT(1) a nonce of 1. As in ECN, retransmissions are not ECN-capable, so carry no nonce.
すべてのECN-可能なIPパケットに1ビットのノンス値を配置するために、送信者が使用する2つのECTコードポイント：ECT（0）0のナンス、およびECNにおける1としてのECT（1）ナンスを表し、再送ではありませんECN対応のため、何のnonceを運びません。
The sender maintains a mapping from each packet's end sequence number to the expected nonce sum (not the nonce placed in the original transmission) in the acknowledgement bearing that sequence number.
送信者は、そのシーケンス番号を担持する肯定応答で予想ノンス和（元の送信に配置されていないノンス）に各パケットの終了シーケンス番号からのマッピングを維持します。
Routers behave as specified in [RFC3168]. By marking packets to signal congestion, the original value of the nonce, in ECT(0) or ECT(1), is removed. Neither the receiver nor any other party can unmark the packet without successfully guessing the value of the original nonce.
ルータは、[RFC3168]で指定されるように振る舞います。 ECT（0）かECT（1）の輻輳、ノンスを元の値を知らせるためにパケットをマークすることによって、除去されます。受信機も他の当事者のいずれもが正常に元ナンスの値を推測することなく、パケットのマークを解除することができます。
ECN-nonce receivers maintain the nonce sum as in-order packets arrive and return the current nonce sum in each acknowledgement. Receiver behavior is otherwise unchanged from [RFC3168]. Returning the nonce sum is optional, but recommended, as senders are allowed to discontinue sending ECN-capable packets to receivers that do not support the ECN-nonce.
ECN-ノンス受信機は、順序のパケットが到着するようにノンス和を維持し、各確認応答における現在のノンス和を返します。受信機の動作は、[RFC3168]からそうでない場合は変更されていません。送信者は、ECN-nonceをサポートしていない受信者にECN対応のパケットを送信中止することが許可されているようナンスの合計を返すことは、オプションですが、お勧めします。
As packets are removed from the queue of out-of-order packets to be acknowledged, the nonce is recovered from the IP header. The nonce is added to the current nonce sum as the acknowledgement sequence number is advanced for the recent packet.
パケットが確認応答されるアウトオブオーダーパケットのキューから削除されると、ノンスは、IPヘッダから回収されます。確認応答シーケンス番号が、最近のパケットのために進んでいるようナンスは、現在の一回だけの合計に追加されます。
In the case of marked packets, one or more nonce values may be unknown to the receiver. In this case the missing nonce values are ignored when calculating the sum (or equivalently a value of zero is assumed) and ECN-Echo will be set to signal congestion to the sender.
マーキングされたパケットの場合には、一つ以上のノンス値は、受信機には未知であってもよいです。この場合の和を計算する際に欠落ノンス値は無視される（または等価的にゼロの値が仮定されている）およびECN-エコーは、送信者に輻輳を通知するために設定されます。
Returning the nonce sum corresponding to a given acknowledgement is straightforward. It is carried in a single "NS" (Nonce Sum) bit in the TCP header. This bit is adjacent to the CWR and ECN-Echo bits, set as Bit 7 in byte 13 of the TCP header, as shown below:
与えられた確認応答に対応するナンス合計を返すことは簡単です。これは、TCPヘッダ内の単一の「NS」（ノンス合計）ビットで搬送されます。以下に示すように、このビットは、TCPヘッダのバイト13のビット7として設定CWR及びECN-エコービット、に隣接しています。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | N | C | E | U | A | P | R | S | F |
| Header Length | Reserved | S | W | C | R | C | S | S | Y | I |
| | | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 3: The new definition of bytes 13 and 14 of the TCP Header.
図3：バイト13とTCPヘッダーの14の新しい定義。
The initial nonce sum is 1, and is included in the SYN/ACK and ACK of the three way TCP handshake. This allows the other endpoint to infer nonce support, but is not a negotiation, in that the receiver of the SYN/ACK need not check if NS is set to decide whether to set NS in the subsequent ACK.
最初の一回だけの合計は1であり、三方TCPハンドシェイクのSYN / ACKとACKに含まれています。これは、他のエンドポイントがナンスサポートを推測することができますが、NSは、後続のACKにNSを設定するかどうかを決定するために設定されている場合、SYN / ACKの受信機はチェックする必要がないということで、交渉ではありません。
This section completes the description of sender behavior by describing how senders check the validity of the nonce sums.
このセクションでは、送信者がナンス和の妥当性をチェックする方法を記述することで、送信者の行動についての説明を終えます。
The nonce sum is checked when an acknowledgement of new data is received, except during congestion recovery when additional ECN-Echo signals would be ignored. Checking consists of comparing the correct nonce sum stored in a buffer to that carried in the acknowledgement, with a correction described in the following subsection.
新しいデータの確認応答を受信したときに、追加のECN-エコー信号が無視されたときに一回だけの合計は、輻輳回復中を除いて、チェックされています。チェックは、以下のサブセクションで説明した補正と、肯定応答で運ばとバッファに格納された正しいナンス和を比較することから成ります。
If ECN-Echo is not set, the receiver claims to have received no marked packets, and can therefore compute and return the correct nonce sum. To conceal a mark, the receiver must successfully guess the sum of the nonces that it did not receive, because at least one packet was marked and the corresponding nonce was erased. Provided the individual nonces are equally likely to be 0 or 1, their sum is equally likely to be 0 or 1. In other words, any guess is equally likely to be wrong and has a 50-50 chance of being caught by the sender. Because each new acknowledgement is an independent trial, a cheating receiver is likely to be caught after a small number of lies.
ECN-エコーが設定されていない場合、受信機は、著しいパケットを受け取っていないと主張するので、正しいナンスの合計を計算して返すことができます。少なくとも1つのパケットがマークされた、対応するナンスが消去されたので、マークを隠すために、受信機が正常に、それは受信しませんでしたナンスの合計を推測しなければなりません。個々のナンスが0または1であることが同じ確率で提供される、その合計はつまり0または1であることが均等にそうである、任意の推測は間違っているに等しく可能性があり、送信者が巻き込まれるの50-50チャンスを持っています。それぞれの新しい確認応答が独立した試験であるので、不正受信機は嘘少数の後に巻き込まれる可能性が高いです。
If ECN-Echo is set, the receiver is sending a congestion signal and it is not necessary to check the nonce sum. The congestion window will be halved, CWR will be set on the next packet with new data sent, and ECN-Echo will be cleared once the CWR signal is received, as in [RFC3168]. During this recovery process, the sum may be incorrect because one or more nonces were not received. This does not matter during recovery, because TCP invokes congestion mechanisms at most once per RTT, whether there are one or more losses during that period.
ECN-エコーが設定されている場合、受信機は、混雑信号を送信し、一回だけの合計をチェックする必要はありません。輻輳ウィンドウが半減され、CWRは、送信され、新しいデータと次のパケットに設定され、CWR信号が受信されるとECN-エコーは、[RFC3168]のように、クリアされます。一の以上のナンスが受信されなかったため、この回復プロセスの間に、合計が正しくない可能性があります。 TCPは、その期間中に1つ以上の損失があるかどうか、RTTごとに一回、最大で混雑メカニズムを起動するので、これは、リカバリ時に重要ではありません。
After recovery, it is necessary to re-synchronize the sender and receiver nonce sums so that further acknowledgments can be checked. When the receiver's sum is incorrect, it will remain incorrect until further loss.
さらに確認応答が確認できるように回復した後、それが再同期送信者と受信者ナンス和する必要があります。受信者の合計が正しくない場合は、さらに損失まで間違ったままになります。
This leads to a simple re-synchronization mechanism where the sender resets its nonce sum to that of the receiver when it receives an acknowledgment for new data sent after the congestion window was reduced. When responding to explicit congestion signals, this will be the first acknowledgement without the ECN-Echo flag set: the acknowledgement of the packet containing the CWR flag.
これは、送信者が、それは輻輳ウィンドウが低下した後に送信される新しいデータに対する確認応答を受信する受信機とそのナンス合計をリセットし、単純な再同期メカニズムにつながります。 CWRフラグを含むパケットの確認応答：明示的輻輳信号に応答するとき、これは、ECN-エコーフラグを設定することなく、第1の応答であろう。
Sender Receiver initial sum = 1 -- 1:4 ECT(0) -> NS = 1 + 0(1:4) = 1(:4) <- ACK 4, NS=1 -- -- 4:8 ECT(1) -> LOST -- 8:12 ECT(1) -> nonce sum calculation deferred until in-order data received <- ACK 4, NS=0 -- -- 12:16 ECT(1) -> nonce sum calculation deferred <- ACK 4, NS=0 -- -- 4:8 retransmit -> NS = 1(:4) + ?(4:8) + 1(8:12) + 1(12:16) = 1(:16) <- ACK 16, NS=1 -- -- 16:20 ECT(1) CWR -> <- ACK 20, NS=0 -- NS = 1(:16) + 1(16:20) = 0(:20)
センダレシーバ初期和= 1 - 1：4 ECT（0） - > NS = 1 + 0（1：4）= 1（4）< - ACK 4、NS = 1 - - 4：8 ECT（ 1） - > LOST - （1）8時12 ECT - >ノンス和演算データが<受信に次まで延期 - - 12時16 ECT（1） - - >ノンス和演算ACK 4、NS = 0延期< - ACK 4、NS = 0 - - 4：8再送 - > NS = 1？（4）+（4：8）+ 1（8：12）+ 1（12：16）= 1（ ：16）< - ACK 16、NS = 1 - - 16：20 ECT（1）CWR - > < - ACK 20、NS = 0 - NS = 1（16）+ 1（16：20）= 0（20）
Figure 4: The calculation of nonce sums at the receiver when a packet is lost, and resynchronization after loss. The nonce sum is not changed until the cumulative acknowledgement is advanced.
図4：損失後のパケットが失われた受信機でノンス和の計算、および再同期。累積確認応答が進行するまでナンスの合計は変更されません。
In practice, resynchronization can be accomplished by storing a bit that has the value one if the expected nonce sum stored by the sender and the received nonce sum in the acknowledgement of CWR differ, and zero otherwise. This synchronization offset bit can then be used in the comparison between expected nonce sum and received nonce sum.
実際には、再同期化は、そうでなければ、送信者とCWRの肯定応答で受信したノンス和によって格納された期待されるナンス和が異なる場合、値のいずれかを有し、そしてゼロ・ビットを記憶することによって達成することができます。この同期オフセットビットは、次に期待されるナンス和し、受信したノンス和との比較に用いることができます。
The sender should ignore the nonce sum returned on any acknowledgements bearing the ECN-echo flag.
ナンスの合計を無視すべき送信者がECN-エコーフラグを保有する任意の謝辞に戻りました。
When an acknowledgment covers only a portion of a segment, such as when a middlebox resegments at the TCP layer instead of fragmenting IP packets, the sender should accept the nonce sum expected at the next segment boundary. In other words, an acknowledgement covering part of an original segment will include the nonce sum expected when the entire segment is acknowledged.
確認応答は、代わりにIPパケットを断片化のTCP層における場合ミドルのresegmentsように、セグメントの一部のみを覆っている場合、送信者は、次のセグメント境界で予想ノンス和を受け入れるべきです。換言すれば、元のセグメントの一部をカバーする承認は全体のセグメントが確認されたときに期待されるナンス和を含むことになります。
Finally, in ECN, senders can choose not to indicate ECN capability on some packets for any reason. An ECN-nonce sender must resynchronize after sending such ECN-incapable packets, as though a CWR had been sent with the first new data after the ECN-incapable packets. The sender loses protection for any unacknowledged packets until resynchronization occurs.
最後に、ECNに、送信者は、何らかの理由で一部のパケットのECN機能を示すために選択できます。 CWRがECN非対応のパケットの後の最初の新しいデータで送られてきたかのようにECN-ナンスの送信者は、ECN-不可能なパケットを送信した後に再同期する必要があります。再同期が発生するまで、送信者は、未確認パケットの保護を失います。
The sender's response to an incorrect nonce is a matter of policy. It is separate from the checking mechanism and does not need to be handled uniformly by senders. Further, checking received nonce sums at all is optional, and may be disabled.
間違ったナンスへの送信者の応答は、ポリシーの問題です。これは、チェック機構から独立しており、送信者によって均一に処理する必要はありません。さらに、すべての受信ナンスの合計を確認することは任意であり、かつ無効にすることができます。
If the receiver has never sent a non-zero nonce sum, the sender can infer that the receiver does not understand the nonce, and rate limit the connection, place it in a lower-priority queue, or cease setting ECT in outgoing segments.
受信機が非ゼロナンスの合計を送ったことがない場合、送信側は受信側がnonceを理解していないことを推測することができ、料金は、接続を制限し、優先順位の低いキューに入れ、または発信セグメントでECTを設定することをやめます。
If the received nonce sum has been set in a previous acknowledgement, the sender might infer that a network device has interfered with correct ECN signaling between ECN-nonce supporting endpoints. The minimum response to an incorrect nonce is the same as the response to a received ECE. However, to compensate for hidden congestion signals, the sender might reduce the congestion window to one segment and cease setting ECT in outgoing segments. An incorrect nonce sum is a sign of misbehavior or error between ECN-nonce supporting endpoints.
受信されたナンス合計が前の肯定応答に設定されている場合、送信者は、ネットワークデバイスは、ECN-ノンス支持エンドポイント間の正しいECNシグナル伝達を妨害していることが推測かもしれません。誤ったノンス最小応答が受信されたECEへの応答と同じです。しかし、隠された輻輳信号を補正するために、送信者は、一つのセグメントに輻輳ウィンドウを縮小して、発信セグメントでECTの設定を中止することがあります。間違ったナンス合計は、ECN-ナンスサポートするエンドポイント間の誤動作やエラーのサインです。
The ECN-nonce can provide robustness beyond checking that marked packets are signaled to the sender. It also ensures that dropped packets cannot be concealed from the sender (because their nonces have been lost). Drops could potentially be concealed by a faulty TCP implementation, certain attacks, or even a hypothetical TCP accelerator. Such an accelerator could gamble that it can either successfully "fast start" to a preset bandwidth quickly, retry with another connection, or provide reliability at the application level. If robustness against these faults is also desired, then the ECN-nonce should not be disabled. Instead, reducing the congestion window to one, or using a low-priority queue, would penalize faulty operation while providing continued checking.
ECN-nonceがマークされたパケットが送信者に通知されることを確認を超えて堅牢性を提供することができます。また、（そのナンスが失われているため）ドロップされたパケットが送信者から隠すことができないことを保証します。滴は、潜在的に障害のあるTCPの実装、特定の攻撃、あるいは仮想的なTCPアクセラレータによって隠蔽することができます。このようなアクセラレータは、それがどちらかに成功プリセット帯域幅への「高速起動」すぐに、別の接続を再試行する、またはアプリケーションレベルでの信頼性を提供できることを賭けることができます。これらの障害に対するロバスト性も要求される場合には、ECN-ナンスは無効にすべきではありません。継続的な検査を提供しながら、その代わり、1に輻輳ウィンドウを縮小、または低優先度キューを使用して、誤動作を罰するでしょう。
The ECN-nonce can also detect misbehavior in Eifel [Eifel], a recently proposed mechanism for removing the retransmission ambiguity to improve TCP performance. A misbehaving receiver might claim to have received only original transmissions to convince the sender to undo congestion actions. Since retransmissions are sent without ECT, and thus no nonce, returning the correct nonce sum confirms that only original transmissions were received.
ECN-ナンスもアイフェル[アイフェル]、TCPの性能を改善するために再送曖昧さを除去するための最近提案されたメカニズムで不正行為を検出することができます。誤動作の受信機は、輻輳アクションを元に戻すには、送信者を納得させるだけのオリジナルの送信を受けていると主張するかもしれません。再送信は、このように正しいナンス合計を返す何ナンスを、ECTせずに送信されていない、としているだけなので、元の送信が受信されたことを確認しました。
As described in RFC3168, use of the Don't Fragment bit with ECN is recommended. Receivers that receive unmarked fragments can reconstruct the original nonce to conceal a marked fragment. The ECN-nonce cannot protect against misbehaving receivers that conceal marked fragments, so some protection is lost in situations where Path MTU discovery is disabled.
RFC3168で説明したように、ECNとフラグメント不可ビットの使用が推奨されます。無印の断片を受け取る受信機はマークされたフラグメントを隠すために、元のナンスを再構築することができます。 ECN-ナンスは、マークされた断片を隠す誤動作受信機なので、いくつかの保護はパスMTUディスカバリが無効になっている状況で失われるから保護することはできません。
When responding to a small path MTU, the sender will retransmit a smaller frame in place of a larger one. Since these smaller packets are retransmissions, they will be ECN-incapable and bear no nonce. The sender should resynchronize on the first newly transmitted packet.
小さなパスMTUに応答する場合、送信側は大きい方の代わりに小さなフレームを再送信します。これらの小さなパケットを再送信があるので、ECN-できないことと何のnonceを負いません。送信者は最初に、新たに送信されるパケットに再同期化する必要があります。
Selective acknowledgements allow receivers to acknowledge out of order segments as an optimization. It is not necessary to modify the selective acknowledgment option to fit per-range nonce sums, because SACKs cannot be used by a receiver to hide a congestion signal. The nonce sum corresponds only to the data acknowledged by the cumulative acknowledgement.
選択的確認応答は、受信機が最適化としてオーダーセグメントのうち、承認することができます。サックスが輻輳信号を隠すために受信機によって使用することができないので、単位の範囲ノンス和に合わせて選択的確認応答オプションを変更する必要はありません。ナンス合計が唯一の累積承認により認めデータに対応します。
Although the IPv4 header is protected by a checksum, this is not the case with IPv6, making undetected bit errors in the IPv6 header more likely. Bit errors that compromise the integrity of the congestion notification fields may cause an incorrect nonce to be received, and an incorrect nonce sum to be returned.
IPv4ヘッダはチェックサムによって保護されているが、これは、IPv6ヘッダーの未検出ビットエラーがやすくなって、IPv6には当てはまりません。間違ったnonceを引き起こす可能性が輻輳通知フィールドの完全性を損なうビットエラーが受信されると、間違ったナンスの合計が返されます。
The random one-bit nonces need not be from a cryptographic-quality pseudo-random number generator. A strong random number generator would compromise performance. Consequently, the sequence of random nonces should not be used for any other purpose.
ランダムな1ビットのノンスは暗号品質の擬似乱数生成器からのものである必要はありません。強力な乱数ジェネレータは、性能を損なうことになります。その結果、ランダムなナンスのシーケンスは、他の目的のために使用すべきではありません。
Conversely, the pseudo-random bit sequence should not be generated by a linear feedback shift register [Schneier], or similar scheme that would allow an adversary who has seen several previous bits to infer the generation function and thus its future output.
逆に、擬似ランダムビットシーケンスを生成関数を推定するためにいくつかの前のビットを見ている敵従ってその将来の出力を可能にする線形フィードバックシフトレジスタ[シュナイアー]、または類似の方式で生成されるべきではありません。
Although the ECN-nonce protects against concealment of congestion signals and optimistic acknowledgement, it provides no additional protection for the integrity of the connection.
ECN-nonceが輻輳信号の隠蔽と楽観確認から保護しますが、それは接続の完全性のために追加の保護を提供しません。
The Nonce Sum (NS) is carried in a reserved TCP header bit that must be allocated. This document describes the use of Bit 7, adjacent to the other header bits used by ECN.
ノンス合計（NS）を割り当てなければならない予約TCPヘッダービットで運ばれます。この文書では、ECNによって使用される他のヘッダビットに隣接するビット7の使用を記載しています。
The codepoint for the NS flag in the TCP header is specified by the Standards Action of this RFC, as is required by RFC 2780. The IANA has added the following to the registry for "TCP Header Flags":
TCPヘッダ内のNSフラグのためのコードポイントは、このRFCの標準アクションで指定されたRFC 2780.によって必要とされるように、IANAは、「TCPヘッダーフラグ」のために、レジストリに以下を追加しました：
RFC 3540 defines bit 7 from the Reserved field to be used for the Nonce Sum, as follows:
次のようにRFC 3540は、ノンス合計に使用される予約済みフィールドからビット7が定義されています。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | N | C | E | U | A | P | R | S | F |
| Header Length | Reserved | S | W | C | R | C | S | S | Y | I |
| | | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
TCP Header Flags
TCPヘッダのフラグ
Bit Name Reference
--- ---- ---------
7 NS (Nonce Sum) [RFC 3540]
The ECN-nonce is a simple modification to the ECN signaling mechanism that improves ECN's robustness by preventing receivers from concealing marked (or dropped) packets. The intent of this work is to help improve the robustness of congestion control in the Internet. The modification retains the character and simplicity of existing ECN signaling. It is also practical for deployment in the Internet. It uses the ECT(0) and ECT(1) codepoints and one TCP header flag (as well as CWR and ECN-Echo) and has simple processing rules.
ECN-ノンスは、マークされた（または削除）パケットを隠蔽からの受信を防止することによってECNのロバスト性を向上させるECNシグナリング機構に単純な変形です。この作品の意図は、インターネットにおける輻輳制御の堅牢性を向上させる手助けをすることです。変更は、既存のECNシグナリングの文字とシンプルさを保持します。また、インターネットでの展開のための実用的です。これは、ECT（0）とECT（1）コードポイントと1つのTCPヘッダフラグ（ならびにCWR及びECN-エコー）を使用し、簡単な処理ルールを有しています。
[ECN] "The ECN Web Page", URL "http://www.icir.org/floyd/ecn.html".
[ECN] "ECNのWebページ" URL "http://www.icir.org/floyd/ecn.html"。
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The addition of explicit congestion notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K.、フロイド、S.及びD.ブラック、 "明示的輻輳通知の添加（ECN）IPへ"、RFC 3168、2001年9月。
[Eifel] R. Ludwig and R. Katz. The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions. Computer Communications Review, January, 2000.
【アイフェル] R.ルートヴィヒ及びR.カッツ。アイフェルアルゴリズム：スプリアス再送に対するTCPは、堅牢な作り。コンピュータコミュニケーションレビュー、2000年1月。
[B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[B97]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[Savage] S. Savage, N. Cardwell, D. Wetherall, T. Anderson. TCP congestion control with a misbehaving receiver. SIGCOMM CCR, October 1999.
【サベージ] S.サベージ、N.カードウェル、D. Wetherall、T.アンダーソン。誤動作の受信機とのTCP輻輳制御。 SIGCOMM CCR、1999年10月。
[Schneier] Bruce Schneier. Applied Cryptography, 2nd ed., 1996
[シュナイアー]ブルース・シュナイアー。応用暗号、第2版、1996
This note grew out of research done by Stefan Savage, David Ely, David Wetherall, Tom Anderson and Neil Spring. We are very grateful for feedback and assistance from Sally Floyd.
このノートはステファン・サベージ、デビッド・イーリー、デイビット・ウェザーオール、トム・アンダーソンとニール・スプリングによって行われた研究から生まれました。私たちは、サリーフロイドからのフィードバックや支援のために非常に感謝しています。
Neil Spring EMail: nspring@cs.washington.edu
ニール・スプリングメール：nspring@cs.washington.edu
David Wetherall Department of Computer Science and Engineering, Box 352350 University of Washington Seattle WA 98195-2350 EMail: djw@cs.washington.edu
コンピュータ理工学のデイビット・ウェザーオール部門、ボックス352350ワシントン大学のシアトルWA 98195から2350 Eメール：djw@cs.washington.edu
David Ely Computer Science and Engineering, 352350 University of Washington Seattle, WA 98195-2350 EMail: ely@cs.washington.edu
デビッド・イーリーコンピュータ理工学、352350ワシントン大学シアトル、WA 98195から2350 Eメール：ely@cs.washington.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。