要約

  • UDPはコネクションレスであり、プロキシはソケットを開いた時点で宛先が到達可能かを知れない。RFC 9298は宛先からのパケットを待たずに応答するよう求め、成功を「ソケットを開き、UDPペイロードを中継する用意がある」と定義する。
  • DNS解決、ソケットの存続、送信観測、返信観測、内側プロトコルの認証・受理は別々の証拠である。一つのHTTP応答から後続の事実を推定してはならない。
  • David Schinaziの文書は、UDPの不確実性を隠さず、責任の所在を明確にした。運用側には、その限定を単一の「正常」表示で消さない設計が求められる。

待つべき信号が存在しない

TCPの感覚をそのまま持ち込むと、トンネルの成功は相手側の参加を含むように見える。TCP CONNECTの先では、プロキシが接続を試み、遠隔側とのハンドシェイク結果を知り得る。ところがUDPには共通の接続開始手順がない。

RFC 9298のクライアントは、target_hostとtarget_portを含む絶対URI Templateで宛先を示す。UDPプロキシはその値を取り出し、対象へ向けてUDPソケットを開く。HTTPの版に応じてExtended CONNECTまたはUpgradeを使い、ペイロードはRFC 9297のHTTP DatagramsとCapsule Protocolに載る。

ここで作られるソケットはプロキシ側のOS状態である。遠隔ホストは、作成そのものに返事をする義務がない。ポートが閉じていても、途中で破棄されても、アプリケーションが無応答を選んでも、作成処理は成立し得る。

そのため仕様は、プロキシには宛先到達性を知る方法がなく、宛先パケットを待たずに要求へ応答する必要があると説明する。そして成功の意味を、要求された対象へソケットを開き、UDPペイロードをプロキシする意思があることに限定する。

「到達した」「受理された」「双方向通信が続く」とは書かれていない。成功の主語はプロキシであり、宛先ではない。

DNSの先行は意味を一段だけ強くする

target_hostがDNS名なら、プロキシはHTTP応答より前に名前解決を行わなければならない。解決に失敗すれば要求を拒否し、RFC 9209のProxy-Statusでdns_errorなどを示せる。

この要件により、名前の行き先すら得ていないトンネルを成功扱いすることは防げる。しかし、名前解決が証明するのは、その時点のリゾルバとキャッシュとポリシーがアドレスを返した事実である。そこに期待するアプリケーションが存在するかまでは証明しない。

記録すべきなのは、入力名、返された候補、選択アドレス、IPファミリ、時刻、キャッシュ利用、そして実際にソケットへ設定された相手である。DNSが後で切り替わっても、既存ソケットは自動的に新しいアドレスへ移るわけではない。名前だけの表示では、この時間差が見えなくなる。

destination_unavailableやdestination_ip_unroutableといったエラーは、プロキシが得た否定的知識を表す。逆に、エラーがないことは肯定的知識ではない。ICMPは届かないことがあり、フィルタは黙って捨て、UDPアプリケーションも不正な入力に応答しないことがある。

正しい送信元と、正しい相手は同義ではない

connected UDPソケットを使える環境では、カーネルが期待する5タプルに合うパケットだけをプロキシへ渡せる。non-connectedソケットなら、プロキシ自身が返信の送信元IPアドレスとUDPポートを検査し、不一致を破棄しなければならない。

これはネットワーク上の対応確認として重要である。しかしアプリケーションの認証ではない。正しいアドレスとポートから来たデータグラムでも、内容が古い、偽造されている、別の意味を持つ、あるいは内側プロトコルが拒否する可能性がある。QUICなどが認証を備えるなら、そのハンドシェイク完了が初めて相手の証拠になる。

ソケットの寿命はHTTP要求ストリームに結び付く。ストリームが開いている間はソケットを保ち、OSから利用不能を知らされた場合はストリームを閉じる。ICMP Destination Unreachableがその契機になることもある。無通信による終了も可能だが、RFCは2分未満の短い期限を推奨しない。

したがって、ソケット作成と終了理由は強い運用証跡になる。一方、開いたままであることは「観測済みの終了条件がない」というだけで、遠隔サービスが継続して健康だという証明ではない。

成立したトンネルの中でもデータは消える

RFC 9298ではContext ID 0がUDPペイロードを運ぶ。非ゼロのIDは拡張用で、要求ごとに別の名前空間を持つ。並べ替えにより、登録前のContext IDを持つデータグラムが先に来ることがある。その場合、受信側は黙って破棄するか、登録を待って短時間だけ保持できる。

データグラムが対応する要求より先に来た場合も同様である。クライアントはCONNECT-UDP応答を受ける前に楽観送信できるが、要求が失敗したり、プロキシが先行パケットをバッファしなかったりすれば、そのデータは処理されない。

サイズにも境界がある。Context ID 0のUDP Proxying Payloadは65,527バイトを超えられず、実際の経路MTUはさらに小さいことが多い。プロキシは転送時にIPフラグメントを新たに作ってはならず、大きすぎるHTTP Datagramを黙って捨てざるを得ない場合がある。

これらは仕様違反ではない。受け入れ応答と個々の配送は異なる状態遷移だからである。トンネルが成立したという一件の記録では、先行破棄、Context ID不明、MTU超過、復路不在、内側認証失敗を区別できない。

Schinaziを「全MASQUEの作者」にしない

RFC 9298は2022年8月にIETF Standards Trackとして公開され、David Schinaziを著者として記載する。2026年9月2日に取得したIETF Datatrackerの文章プロフィールは、彼をGoogleのsenior staff software engineer兼senior managerとし、Privacy Proxy、MASQUE、OHTTPを主に担当すると紹介する。過去にはQUICの共同リード、Chrome Networkingの責任者、Appleでのネットワーク技術開発に携わったとも記す。所属や役割、RFC件数は取得時点の情報である。

IETFの公式写真は人物同定の根拠であって、特定サービスの管理権を示すものではない。周辺技術も共同成果だ。RFC 9297はSchinaziとLucas Pardueの共著であり、RFC 9484はTommy Paulyら5人の著者がIPプロキシへ範囲を広げ、masque well-known URIの登録を更新した。MASQUE Working Groupも集団の標準化活動である。

ここで人物として評価すべきなのは、巨大な領域を一人の功績にまとめることではない。RFC 9298の一文一文が、プロキシの知識と宛先の未知を混同しない点である。

Heng LuのRunning-Code Primacyを当てはめれば、稼働する機能が実行したことだけを主張する。Minimum Initial Specificationの観点では、共通トンネルは小さく保ち、アプリケーション固有の認証、再送、成功条件を内側に残す。この二つの原則が、RFCの限定された成功を弱さではなく構造的な誠実さに変える。

状態ではなく証拠列を設計する

第一の証拠は利用許可である。クライアントの識別または権限区分、対象、ポリシー版、送信量の上限、許可・拒否を記録する。任意クライアントから任意宛先へのトンネルは、プロキシを発信元に見せ、localhost、link-local、multicast、broadcastなどの保護を迂回させ得る。

第二はDNS解決、第三はソケットである。第三にはローカル出口、connectedか否か、相手タプル、要求ストリーム、終了時刻と理由を含める。

第四はデータグラム観測である。方向別の最初と最後、個数、バイト、サイズ超過、送信元不一致、未知Context ID、バッファ制限、ICMP由来のエラーを区別する。ペイロードを長期保存しなくても、移動の証拠は作れる。

第五は内側プロトコルの結果である。認証済みハンドシェイク、要求に対応する応答、業務上の受理、明示エラー、タイムアウトをここに置く。再送の安全性もアプリケーションが決める。問い合わせの再送と、非冪等な操作の再送は同じではない。

表示は「プロキシ準備済み」「名前解決済み」「送信観測」「返信観測」「相手認証済み」「アプリ受理済み」と段階化できる。未知のままの部分を、未知として残せることが価値になる。

限定された言葉が運用を強くする

一つの緑色表示は使いやすい。しかし、早く得られるHTTP応答をアプリケーション成功として学習させれば、経路選択は受け入れが速いだけのプロキシを好むようになる。MTU破棄をアプリ障害と誤診し、送信元検査を相手認証と誤記し、返信ゼロの長時間ソケットを健全な利用と数えるようになる。

RFC 9298は、その混乱を起こす必要がないことを示す。プロキシは自分の準備を証言する。リゾルバはアドレスを証言する。OSはソケットの状態を証言する。内側プロトコルは相手と結果を証言する。

宛先の返事を待たずにトンネルが成功しても、矛盾はない。矛盾が生まれるのは、運用者がその成功に、まだ存在しない宛先の証言を書き足したときである。

出典