[要約] RFC 3540は、ロバストな明示的輻輳通知（ECN）シグナリングを非ステートフルな方法で実現するための仕様です。このRFCの目的は、ネットワークの輻輳制御を改善し、パフォーマンスを向上させることです。
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
ノンセスを使用した堅牢な明示的な輻輳通知（ECN）シグナル伝達
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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.
このメモは、TCP送信者からのマークされたパケットの偶発的または悪意のある隠蔽から保護するECNへのオプションの追加である、明示的な混雑通知（ECN）-Nonceについて説明しています。これにより、受信機がECNを悪用してネットワーク帯域幅の不公平なシェアを獲得できないようにすることにより、輻輳制御の堅牢性が向上します。ECN-Nonceは、IPヘッダーのECNフィールドに2つの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つの目標は、賢明であり、標準トラックで公開される前に使用と展開を奨励することです。もう1つの考慮事項は、ファイアウォール開発者がNONCEによって提示されたパターンを認識して受け入れる時間を与えることです。より多くの経験が得られた後、将来のIETF提案標準としてこの仕様を再サブミングすることは、輸送エリアワーキンググループの意図です。
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の正しい操作には、受信者の協力が送信者に経験豊富なシグナルを返すために必要ですが、プロトコルにはこの協力を実施するメカニズムがありません。これにより、不cru慎または実装されていないレシーバーが常に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-Nonceは、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-Nonceにより、送信者はECNレシーバーの正しい動作を確認でき、信号パスにマークされた（またはドロップされた）パケットを隠す干渉は他にないことを確認できます。ECN-Nonceは、実装エラーと意図的な虐待の両方から保護します。ecn-nonce：
- 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-Nonceの使用には、ドロップテールルーターのみが使用されている場合でも、2つの追加の利点があることにも注意してください。まず、パケットドロップを送信者から隠すことはできません。第二に、それは楽観的な謝辞[Savage]を防ぎ、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]に記載されているように解釈される場合、このドキュメントに表示される場合、キーワードは必要、必要は、推奨される、推奨する、推奨することはできません。
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-Nonceは、既存の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-ECHO）フラグは、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-Nonceはこのプロトコルに追加され、受信者が認められているセグメントがマークされていないことを送信者に実証できるようにします。ランダムな1ビット値（nonce）が2つのECTコードポイントでエンコードされます。これらのNoncesの1ビット合計は、TCPヘッダーフラグであるNonCe Sum（NS）ビットで返されます。CEが両方のECN IPヘッダービットを上書きするため、パケットマーキングはECTコードポイントのNonCE値を消去します。各非CEは合計を計算するために必要であるため、正しいNonCe合計は、マークされていないパケットのみの受領を意味します。受信機がマークされたパケットを隠すことを妨げるだけでなく、ネットワークパスに沿った中間ボックスは、元のNonCEの値を正常に推測せずにパケットをマークすることはできません。
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.
送信者は、マークされた（またはドロップされた）パケットの形での輻輳適応が隠されていないことを確認するために、受信機によって返されたNonCe Sumを確認できます。NonCeの合計はわずか1つの長さであるため、送信者は、確認がマークを隠すたびに、嘘をついているレシーバーを捕まえる50〜50のチャンスを持っています。それぞれの承認は独立した試験であるため、繰り返しの輻輳信号がある場合、詐欺師は迅速に捕獲されます。
The following paragraphs describe aspects of the ECN-nonce protocol in greater detail.
次の段落では、ECN-Nonceプロトコルの側面について詳しく説明します。
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.
各謝辞には、NonCeの合計が含まれています。これは、確認によって表されるバイト範囲にわたるNoncesの1つのビット合計（排他的またはパリティ）です。すべてのパケットが個別に認められているわけではなく、パケットが確実に認められているわけではないため、合計が使用されます。合計が使用されていない場合、マークのないパケットのノンセを反映して、個々のパケットがマークされていないことを送信者に証明することができます。ただし、これらのACKは確実に配信されないため、送信者は、マークされたパケットを隠すために送信されなかったACKと失われたACKを区別することはできませんでした。NonCe Sumは、レシーバーが個々のマークされたパケットを認めないことで隠すことを防ぎます。NonCeとNonCeの合計は両方とも1つの量であるため、合計は個々の非速度よりも推測するのが容易ではありません。以下に、以下のNonCe Sumの計算を示します。
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：受信機での非CEサムの計算。
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がクリアされ、受信機のNoncesの合計が送信者の合計と一致しなくなります。Noncesが失われると、送信者と受信者の非CEの違いは、さらなる損失が発生するまで一定になります。これは、送信者にそのnonce和を受信者の合計に設定させることにより、輻輳後に送信者と受信機を再同期させることができることを意味します。渋滞の適応症は、往復あたりの1回よりも頻繁に伝達する必要はないため、CWR信号が配信されている間はチェックを一時停止し、新しいデータが認められたときにNonCe合計を受信機にリセットします。これには、受信機が再同期プロセスに明示的に関与していないという利点があります。再同期プロセスを以下の図2に示します。ACK 12（ns = 0）で返された非CE合計は、前の例（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 --
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：パケット（4：8）がマークされたときのレシーバーでの非CEサムの計算。受信者は、パケットがマークされた後に元のNonCE情報が失われたときに間違ったNonCe合計を計算できます。
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.
第三に、ノンセスがパケットで送信されるが、謝辞はバイトの範囲をカバーすることを調整する必要があります。確認されたバイト境界は、送信された境界と一致する必要はなく、情報を異なるバイト境界のあるパケットで再送信することができます。セクション6.1で、セグメントの一部を認めるときに、受信者がどのようにノンセを設定するかについて説明します。2番目の質問は、より小さなセグメントを大きなセグメントとして再送信するときに送信するノンセに簡単な答えがあります。ECNは再送信のために無効になっているため、NonCeを運ぶことはできません。再送信は輻輳イベントに関連しているため、CWRが認められ、混雑イベントが終了するまで、NonCeチェックは停止されます。
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エコーを管理します。さらに、パケットが送信されたときにノンセスを配置し、受け取ったときに非CEの合計の有効性を確認する必要があります。このセクションでは、送信プロセスについて説明します。
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つのNonCE値を1ビットノンセ値を配置するには、送信者は2つのECTコードポイントを使用します。ECT（0）は0の非CEを表し、ECT（1）1の非CEを表します。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.
送信者は、各パケットのエンドシーケンス番号から、そのシーケンス番号が付いている確認範囲で、予想されるNonCe Sum（元の送信に配置されていない）までのマッピングを維持します。
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）のNonCEの元の値が削除されます。受信者も他の当事者も、元のNONCEの値を正常に推測することなく、パケットをマークすることはできません。
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-Nonceレシーバーは、順序付けパケットが到着し、各確認の現在の非CE額を返すと、NonCe Sumを維持します。それ以外の場合、受信者の動作は[RFC3168]から変更されていません。NonCe Sumを返すことはオプションですが、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.
承認されるために、オーダーアウトオブオーダーパケットのキューからパケットが削除されると、非CEはIPヘッダーから回収されます。[最近のパケット]の[確認]シーケンス番号が進んでいるため、NONCEは現在のNonCe Sumに追加されます。
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.
マークされたパケットの場合、1つ以上のNonCE値が受信者には不明である場合があります。この場合、合計を計算するとき（または同等にゼロの値が想定される）場合、欠落している非CE値は無視され、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:
特定の確認に対応する非CEの合計を返すことは簡単です。TCPヘッダーに単一の「ns」（nonce sum）ビットで運ばれます。このビットは、以下に示すように、TCPヘッダーのバイト13でビット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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 3: The new definition of bytes 13 and 14 of the TCP Header.
図3：TCPヘッダーのバイト13および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.
初期の非CE総額は1であり、3ウェイTCPハンドシェイクのsyn/ackとackに含まれています。これにより、他のエンドポイントはNonCEサポートを推測できますが、NS/ACKの受信者がNSが後続のACKにNSを設定するかどうかを決定するかどうかを確認する必要がないという点で交渉ではありません。
This section completes the description of sender behavior by describing how senders check the validity of the nonce sums.
このセクションでは、送信者が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.
NonCeの合計は、追加の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エコーが設定されていない場合、受信者はマークされたパケットを受け取っていないと主張しているため、正しいNonCe合計を計算して返すことができます。マークを隠すために、受信者は、少なくとも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エコーが設定されている場合、受信機はうっ血信号を送信しており、NonCe Sumを確認する必要はありません。輻輳ウィンドウは半分になり、[RFC3168]のように、CWR信号が受信されるとECNエコーが送信された新しいデータが次のパケットに設定され、[RFC3168]のようにECNエコーがクリアされます。この回復プロセス中に、1つ以上の非性能が受信されなかったため、合計が正しくない場合があります。TCPは、その期間中に1つ以上の損失があるかどうかにかかわらず、TCPはRTTごとに最大1回渋滞メカニズムを呼び出すため、回復中は重要ではありません。
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.
回復後、送信者と受信者の非CEの合計を再同期して、さらなる謝辞を確認できるようにする必要があります。受信者の合計が間違っている場合、さらなる損失があるまで間違ったままになります。
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.
これにより、輻輳ウィンドウが削減された後に送信された新しいデータの確認を受信したときに、送信者が受信者の合計に非CEの合計をリセットする単純な再同期メカニズムにつながります。明示的な混雑信号に応答する場合、これはECN-Echoフラグセットのない最初の承認です。CWRフラグを含むパケットの承認です。
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)
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：パケットが失われたときのレシーバーでの非CEサムの計算、および損失後の再同時代化。累積認識が進むまで、非CEの合計は変更されません。
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.
実際には、送信者によって予想される非CEの合計が格納され、CWRの承認で受信されたNonCe合計が異なり、それ以外の場合はゼロである場合、値を少し保存することにより、再同期を実現できます。この同期オフセットビットは、予想される非CE総額と受信した非CEサムの比較で使用できます。
The sender should ignore the nonce sum returned on any acknowledgements bearing the ECN-echo flag.
送信者は、ECNエコーフラグを持つ謝辞で返されたNonCE Sumを無視する必要があります。
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レイヤーでミドルボックスの徴収をした場合など、セグメントの一部のみをカバーしている場合、送信者は次のセグメント境界で予想される非CEの合計を受け入れる必要があります。言い換えれば、元のセグメントの一部をカバーする承認には、セグメント全体が承認されたときに予想されるNonCe Sumが含まれます。
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機能を示さないことを選択できます。ECN-Nonce Senderは、ECNに入れられないパケットの後に最初の新しいデータでCWRが送信されたかのように、そのような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 Sumを送信したことがない場合、送信者は受信者が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.
受信したNonCeの合計が以前の承認で設定されている場合、送信者は、ネットワークデバイスがECN-Nonceサポートエンドポイント間の正しいECNシグナル伝達を妨げていると推測するかもしれません。誤ったノンセに対する最小応答は、受信したECEに対する応答と同じです。ただし、隠された輻輳シグナルを補うために、送信者は輻輳ウィンドウを1つのセグメントに減らし、発信セグメントでの設定を停止する可能性があります。誤った非CE額は、ECN-Nonceサポートエンドポイント間の不正行為またはエラーの兆候です。
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-Nonceを無効にするべきではありません。代わりに、輻輳ウィンドウを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-Nonceは、TCPパフォーマンスを改善するために再送信のあいまいさを除去するための最近提案されたメカニズムであるEifel [eifel]の不正行為を検出することもできます。誤動作の受信者は、送信者に輻輳行動を取り消すよう説得するために、元の送信のみを受け取ったと主張するかもしれません。再送信はECTなしで送信されるため、したがって非CEがないため、正しいNonCe Sumを返すと、元の送信のみが受信されたことが確認されます。
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-Nonceは、マークされたフラグメントを隠す誤動作レシーバーから保護することはできないため、PATH 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に入れられず、非CEを負担しません。送信者は、最初の新しく送信されたパケットで再同期する必要があります。
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.
選択的な謝辞により、受信者は最適化として注文のセグメントを認めることができます。サックをレシーバーが使用して混雑信号を非表示にすることはできないため、範囲ごとのノンセの合計を適合させるために選択的な確認オプションを変更する必要はありません。NonCe Sumは、累積認識によって認められたデータにのみ対応します。
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ヘッダーの検出されないビットエラーが発生する可能性が高くなります。輻輳通知フィールドの完全性を損なうビットエラーは、誤ったノンセが受信され、誤ったノンセの合計が返される可能性があります。
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.
ランダムなワンビットのノンセスは、暗号化品質の擬似ランダム数ジェネレーターからである必要はありません。強い乱数ジェネレーターはパフォーマンスを損なうでしょう。したがって、ランダムノンセのシーケンスは、他の目的に使用しないでください。
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.
逆に、擬似ランダムビットシーケンスは、線形フィードバックシフトレジスタ[Schneier]、またはいくつかの以前のビットを見た敵を生成機能、したがって将来の出力を推測できるようにする同様のスキームによって生成されるべきではありません。
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.
NonCe Sum（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フラグのCodePointは、RFC 2780で義務付けられているように、このRFCの標準アクションによって指定されています。IANAは、「TCPヘッダーフラグ」のレジストリに以下を追加しました。
RFC 3540 defines bit 7 from the Reserved field to be used for the Nonce Sum, as follows:
RFC 3540は、次のように、非CE合計に使用される予約フィールドからビット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-Nonceは、受信機がマークされた（またはドロップされた）パケットを隠すことを防ぐことにより、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] Ramakrishnan、K.、Floyd、S。およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、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.カッツ。EIFELアルゴリズム：スプリアスな再送信に対してTCPを堅牢にする。コンピューター通信レビュー、2000年1月。
[B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[B97] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.
[Savage] S. Savage、N。Cardwell、D。Wetherall、T。Anderson。誤動作レシーバーを使用した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.
このメモは、Stefan Savage、David Ely、David Wetherall、Tom Anderson、Neil Springによる研究から生まれました。サリー・フロイドのフィードバックと支援に非常に感謝しています。
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
David Wetherallコンピュータサイエンスエンジニアリング部門、ボックス352350ワシントン大学シアトル大学98195-2350メール：djw@cs.washington.edu
David Ely Computer Science and Engineering, 352350 University of Washington Seattle, WA 98195-2350 EMail: ely@cs.washington.edu
David Ely Computer Science and Engineering、352350ワシントン大学シアトル、ワシントン州98195-2350メール：ely@cs.washington.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。