要約

  • RFC 3360は、ECEとCWRを設定したECN setup SYNに対し、旧Reservedビットの使用を嫌ったfirewallやload balancerがRSTを返した問題を扱う。
  • フラグを消した二回目のSYNが成功しても、最初のRSTの生成者、serverのECN対応、経路の修復、ECNによる後続効果は証明されない。

一回目のRSTは無視する。ECEとCWRを消し、二回目のSYNを送る。二回目にもRSTが返れば、今度は接続を諦める。

この動作は一見すると実務的な互換策である。同時に、同じビットを持つ同じ種類の制御メッセージについて、受信回数で意味を変えなければならなくなったことを示す。

2002年8月にBCP 60として公開されたRFC 3360は、未知のTCPフラグを見た中間装置がRSTを送る行為を問題にした。現在の製品比率を示す資料ではない。記載された測定も2000年代初頭の履歴である。重要なのは、誤った発話者が入り込むと、endpointが持つべき状態通知の意味まで弱くなるという構造だ。

RSTは状態機械の言葉である

RFC 793におけるresetは、存在しない接続への要求や、現在の接続に向けられたとは考えにくいsegmentを処理するための手段だった。受信側は接続を中止し、applicationへ通知する。RFC 9293もreset生成と検証を明示的な状態遷移として整理している。

したがってRSTは、単なるエラー表示ではない。受信側に即時の破棄を促す強い言葉である。queueが満杯、拡張を理解できない、local policyが許可しない、という別々の事情を同じ言葉で表せば、受信者は推測するしかなくなる。

firewallが拒否権を持てないという話ではない。RFC 2979はsiteが不正と判断するaccessを遮断できることを認める。境界は、その拒否が誰の判断として観測されるかにある。path上のpolicyがremote TCPの接続状態を代弁してはならない。

RFC 3360は、遮断されたportへのSYNにRSTを返す場合とは区別する。問題は通常のTCPを通しながら、標準化された拡張形式だけをRSTで壊す装置だった。

ECN交渉には理解しない装置の寛容さが必要だった

RFC 3168では、旧Reserved領域から割り当てられたECEとCWRをSYNに同時設定し、ECN利用を提案する。対応peerは所定のSYN-ACKを返す。非対応の古いTCP実装は未知のflagを無視し、通常のSYN-ACKを返す想定だった。

endpoint間の選択で済むはずの設計は、途中の装置が未知値を許容することに依存していた。RFC 3360が引用する2002年3月の調査では、12,364 siteのうち203がreset、420がdropで応答した。現代へ外挿できる数字ではないが、第三者が能力交渉の入口を閉じられたことは分かる。

client側のpacket captureに正しいaddress、port、ACKがあっても送信者は確定しない。middleboxは整合するpacketを作れる。対象装置の前後での観測、bypass比較、rule log、再現試験がなければ「serverが拒否した」は仮説である。

fallbackは接続を救い、原因を薄める

ECN setup SYNがRSTを受けたとき、ECEとCWRを消したSYNを再送する回避策がある。これが成功すればECNなしの接続ができる。さらにRSTなら通常どおり中止する。

この順序で最初のRSTは暫定扱いになる。真のserver拒否だった可能性があっても一度は無視される。plain SYNの成功はserverがECN非対応だった証拠ではなく、経路が交渉を妨害した可能性を残す。timeoutによる切替なら、単なるlossでECNを無効化したかもしれない。

RFC 3360は実装者のためらいも記録した。有効なRSTへの反応を遅らせ、正常な環境でもECNを失い、接続まで数秒以上待たせ、壊れた装置を受け入れる結果になり得る。互換性は無料ではない。

RFC 7413のTCP Fast Openにも、未知optionやdata付きSYNを落とすpathに対して通常handshakeへ戻る設計がある。user transactionは成功しても、拡張失敗がtelemetryから消えれば、装置を直す理由も消える。

challenge ACKが直すのは別の境界

RFC 5961はblind RST attackへの耐性を高めた。established connectionでwindow内だが正確なsequenceでないRSTにはchallenge ACKを返し、真正なpeerからの確認を待つ。

これはpacket受理の精度であって、初期SYNへのRSTのpolicy由来を認証する仕組みではない。RFC 5961自身も、middleboxが古いRSTを再送してACK/RST warを起こすことや、flow state削除後にchallenge ACKを落とすcorner caseを扱う。

正しいsequence、正しい送信者、正当な意味は別の属性である。syntaxが通るだけで、装置にremote endpointの意思を語る権限が生まれるわけではない。

一度目を疑う世界は次の拡張を難しくする

RFC 3360が恐れたのはTCPの凍結だった。IETFがReserved bitへ新しい意味を割り当てても、deploy済み装置が拒否すれば利用できない。endpointはreachabilityを守るため拡張を隠し、pathの誤実装が事実上の仕様になる。

RFC 6709は拡張設計上の配慮を整理し、RFC 9170はさらに、設計だけでは不十分だと述べる。extension pointは実際に変化する値で継続的に使い、failure feedbackを届けなければ錆び付く。RFC 8701のGREASEはTLSで未知値を意図的に提示するが、すべてのTCP場面への解答ではない。未知値を早期に通す試験文化の例である。

Heng Luの最小初期仕様と将来判断の局所化という原則で読むと、policyの範囲が見える。運用者は自分のnetworkで能力を拒否できる。しかし拒否はlocal decisionとして識別できるべきだ。RSTをremote factに見せると、中間装置の選好が双方のendpointを拘束するmandateへ変わる。

二回のSYNを一つの成功に畳まない

調査では最初のSYNを保存し、flag、option、address、time、狙った能力を記録する。controlled middleboxの前後に観測点を置く。RSTのACKやsequenceを検査しても、それをprovenanceとは呼ばない。

意図的なpolicyならrule owner、version、承認理由、期限を結び付ける。fallbackはRST、timeout、手動操作のどれで始まったかを残す。二回目が同じdestinationと同等pathを通ったかも確認する。

修復判定では拡張SYNを再送し、peerまで到達したこと、peer能力に応じた応答、negotiated modeでのdata、外部application resultを順に見る。config changeの成功表示はこの連鎖を代替しない。

複数経路なら結果も分ける。一つの出口でECNが通っても、別の出口に同じreset装置が残ることはある。

証拠の限界

資料は現在のdeployment率、特定vendorの動作、実事故を証明しない。ECN setup SYNへの全RSTが不正とも述べない。未知flagを無条件で通せという結論でもない。

ECNなしで接続した事実はserverの能力を示さない。ECN交渉成功も、実際のCE marking、receiver feedback、sender response、application改善を証明しない。

確かな結論は狭い。最初のRSTを疑わなければならない互換策が生まれた時点で、signalの意味とextension capacityは既に損なわれている。その損失を最終接続成功の中へ隠してはならない。

情報源