要約

  • ECN Nonceでは、送信側がECT(0)とECT(1)をランダムに選ぶ。ルーターがCEに書き換えると元の選択が消え、混雑を隠す受信側は正しい累積値を確実には返せなくなる。
  • 正常な混雑でも同じ情報が失われるため、回復中は照合を中断し、その後に再同期する。不一致だけで受信側の悪意を証明することはできない。
  • 2018年の実験終了は、仕組みの否定ではなく、限定的な利用と共通コードポイントの機会費用を踏まえた判断だった。

過去を復元せず、比較できる状態に戻る

受信側が返した一ビットを、送信側の記録と比べない時間がある。検証のために作られた仕組みとしては、奇妙に聞こえる。しかしECN Nonceでは、その中断がなければ正しい通信まで疑わしいものになってしまう。

ルーターが混雑を示すためにパケットを書き換えると、元のランダムな値は失われる。受信側が混雑を正直に報告しても、消えた値を取り戻せるわけではない。そこで送信側は回復中の照合を止め、後から共通の基準を作り直す。失われた過去を再現するのではなく、次の比較が意味を持つ位置まで戻るのである。

この仕組みを定めたのは、N. Spring、D. Wetherall、D. Elyによる2003年6月の実験仕様、RFC 3540だった。目的は混雑の印や損失を隠した報告に対する保護であり、接続全体の認証でも、受信者の人格を判定する制度でもなかった。

二つの違いが、一つの印に変わる

前提となるRFC 3168は2001年9月に公開された。従来のECNでは二ビットの欄に、00のNot-ECT、01のECT(1)、10のECT(0)、11のCEがある。対応するパケットには、破棄の代わりに混雑経験を示すCEを付けられる。TCPの受信側はECEで知らせ、送信側はCWRで混雑への対応を示す。

この従来のルーター動作では、ECT(0)もECT(1)も混雑の印を付けてよいという意味を持つ。どちらをCEに変えても、到着時の値は同じになる。データ本体が無事に届いていても、元がどちらだったかはCEだけからは分からない。

ECN Nonceは、送信側にこの二択をランダムに行わせる。元の値を知る送信側は期待値を保存する一方、受信側は実際に届いた値しか使えない。ルーターは新たな秘密を管理する必要も、相手を審査する必要もない。いつもの混雑表示が、結果として情報を消す働きをする。

もし受信側がCEを見なかったことにしようとすれば、届いていない情報を含む正しい答えも用意しなければならない。送信側はその答えを自分の記録と照合できる。この非対称性が実験の核心であり、暗号によって情報を隠す方式とは異なる。

ACK一個ずつでは、証拠が抜け落ちる

TCPの確認応答は、パケットごとに必ず一つ戻るわけではない。遅延することも失われることもあり、一つの累積確認が複数のセグメントをまとめて覆う。最後に受け取ったランダム値だけを返す方法では、途中のACKを省くことが途中の証拠を省くことにもなりかねない。

そこでRFC 3540は、値を二を法として足し合わせる累積パリティを使う。初期値は一で、結果はNSフラグの一ビットとして返される。受信側は、順序どおりのデータに対して累積ACKが進むにつれ、対応する値を加える。送信側は元のパケットの終端シーケンス番号に結び付けた期待値を持つ。

順序を外れて先に届いたデータは、累積ACKがその位置に進んだときに加算対象となる。SACKの各ブロックについて別々の証明を作る方式ではないし、本文のチェックサムでもない。元の分割位置やACKの進行を切り離せば、NSの値だけを眺めても意味は確定しない。

未知の均等なランダムビットが一つあれば、正しいパリティを推測できる確率は二分の一になる。したがって、一度の虚偽報告が必ず見つかるとは言えない。新しく独立したランダム情報が消えれば追加の検出機会が生じ得るが、同じ未知の一ビットに依存するACKを繰り返し数えても、すべて独立した試行になるわけではない。

パリティは混雑量の記録でもない。何個のパケットに印が付いたか、その時刻はいつかという詳細をすべて表せるわけではない。フィードバックを細かくすることと、それを偽りにくくすることは、関係はあっても同じ設計課題ではない。

正直な受信側も答えを失う

CEによって消えた値は、相手の意図にかかわらず消えている。RFC 3540では、受信側は欠けた値を無視し、ゼロとして扱うのと同じ計算をしながらECEを立てる。送信側はその混雑回復中にNonceの照合を停止する。

ウィンドウを縮小してCWRを伴う新しいデータを送り、対応する確認応答が戻ったところで、受信側の累積値を使って再同期する。実装上は一ビットの差分を持つ方法で調整できる。これは消去された情報の復元ではなく、古い欠落が後続の比較を壊し続けないための処理である。

したがって、この停止区間で値が合わないことを、混雑を隠した証拠にしてはいけない。比較対象の値だけでなく、比較してよい接続状態かどうかを先に確かめる必要がある。厳密さは、常に照合することではなく、照合が成立する条件を守ることにある。

2003年の条件では、再送はNot-ECTとなりNonceを持たなかった。送信側が選ぶ非ECT区間についても再同期が必要になる。ただし、この条件を現在のすべてのTCP実験に対する禁止事項として扱うのは誤りである。後のRFC 8311は、再送や制御パケットに関する実験上の制約を緩和している。

誤った和は、犯人の名前ではない

RFC 3540は、検査と反応を分けている。検査自体は任意であり、誤った和にどう反応するかはローカルな方針である。反応する場合には少なくともECEに応じるのと同等の対応を考え、さらに強い縮小やECTの利用停止も選択肢に含める。しかし、全参加者に同じ制裁を与える手続きではない。

その区別には技術的な理由がある。IPv4の断片の一つが未標示なら、別の断片にCEが付いていても元のNonceが分かり、隠蔽に対する保護が弱まる。IPv6ヘッダーのビット誤りは、ECNの情報を壊して誤った和を生じさせ得る。セグメントの一部へのACKは、元のセグメント境界を踏まえて解釈しなければならない。

ランダム列は暗号用途と同等の強度を求められてはいないが、過去に見た値から次の値を容易に予測できては困る。同じ列を別の用途に再利用することも避ける。仕様は接続の完全性に新たな保証を与えておらず、協力しない送信側を正しく動作させるものでもない。

初期ハンドシェイクの応答でNSがゼロ以外なら対応を推測できるが、仕様はこれを交渉とは呼んでいない。認証能力が合意されたと説明するのは、実際の交換を過大評価する。不一致が示すのは報告経路における誤りや干渉の可能性であり、特定の受信者の悪意を直接立証するものではない。

動く実験が、場所を譲るまで

ECNの意味を変える試みには、共存の問題がつきまとう。2006年11月のRFC 4774は、代替的な意味付けの識別、段階的な導入、従来のルーターやECN非対応の機器、競合する通信への影響を検討した。二ビットだから自由に使えるのではなく、二ビットを共有するから解釈の一致が必要になる。

2015年8月のRFC 7560は、より正確な混雑フィードバックの要件を扱い、当時Nonceを使うTCPスタックの既知の導入がなかったと記している。報告の完全性や正直に協力する動機は重要だが、それを実現する手段をNonceだけに限定してはいない。

2018年1月のRFC 8311は、より限定を付した形で経緯をまとめる。Nonceは仕様どおりに機能し、限られた環境で導入された。しかし広範な利用には至らなかった。これを踏まえ、実験の終了とRFC 3540をExperimentalからHistoricへ変更する理由を示した。計算方法が破綻したという結論ではない。

同文書が紹介する2014年のデータに基づく研究では、試験した581,711のIPv4サーバーで、ECNの合意後に両方のECT値を使うものはなかった。17,028のIPv6サーバーでは四つあったが、Nonceの利用か、誤った再標示かは区別できない。この数字には観測時期、標本、解釈の留保が付いており、現在の全インターネットを数えた結果ではない。

別の実験用途や別の完全性確保の手段が現れるなか、ECT(1)をNonce専用に残す理由は弱くなった。ただし解放は無制限の再解釈を意味しない。RFC 8311が認める実験には適切なIETFのExperimental RFCが必要であり、混雑制御や共存への責任も残る。

2023年1月のExperimental文書、RFC 9331は、ECT(1)をL4Sの識別に使う別の意味を定めた。現在のIANA ECNフィールド登録表は四つの値を掲載し、ECT(1)の実験用途について関連文書を参照する。最近の通信で同じビットを見ても、2003年のNonceが動いている証拠にはならない。この後続用途の存在から、L4Sの普及率や性能、安全性一般を推定することもできない。

ECN Nonceが残したのは、何でも見抜く検出器ではない。自分が持つ情報で相手の限定された主張を確かめ、分からなくなった区間を認め、再び比較できる地点から進む設計である。そして実験そのものにも、共有空間を使い続ける条件と終える条件があった。