要約

  • IESG は 2026 年 8 月 24 日、draft-ietf-masque-connect-udp-listen 第 16 版を Proposed Standard として承認した。証拠を固定した時点では RFC Editor の待ち行列にある Internet-Draft であり、発表は Google Quiche と quic-go の相互運用を報告している。
  • この方式は、一つの公開 UDP ソケットを保ったまま複数のリモート IP・ポートと通信する。公開タプルは到達可能な資源の割り当てであって、全送信元への許可ではない。機能交渉、コンテキスト登録、宛先方針、実際の配送を個別に立証する必要がある。

正しいポートに届いた、正しくない相手

ブラウザーが WebRTC のために HTTP プロキシへ UDP の公開アドレスを求める。プロキシは IP アドレスとポートを割り当てる。ICE が選んだ相手からパケットが届き、その直後、偶然ポートを見つけたスキャナーからも一つ届く。

ネットワーク上は、どちらも正しいソケットに到着した。権限上は同じではない。

これは公表済み事故ではなく、境界を確認するための例である。「Proxying Bound UDP in HTTP」が解決するのは、公開ソケットを維持しながら、相手ごとの扱いを狭く保つ問題だ。IP とポートを広告しただけでは、リクエスト、相手タプル、Context ID、プロキシ方針、クライアントの受信意思は確定しない。

承認は実装済みという意味ではない

IESG の発表時刻は 8 月 24 日 17:58 UTC。MASQUE ワーキンググループの第 16 版を Proposed Standard として承認した。

出発点の RFC 9298 は、CONNECT-UDP の一つのリクエストに一つの固定ホストとポートを置く。HTTP/3 のようなクライアント・サーバー型の UDP には適している。ところが WebRTC の ICE は複数候補との通信を必要とする。通常の CONNECT-UDP を複数開いても、HTTP の意味論上、それらが同じプロキシ実体や同じ公開 IP を使う保証はない。

新しい拡張は、一つのリクエストに公開ソケットを結び付け、データグラムまたは登録済み対応表で相手を変える。発表が示す二実装の相互運用は実行可能性の証拠だが、普及率、ブラウザーでの有効化、大規模運用、全実装の適合性までは証明しない。

8 月 28 日時点で Datatracker は依然として Active Internet-Draft と表示し、IESG 状態は RFC Ed Queue だった。IANA の作業は進行中で専門家レビューは完了、RFC Editor は参照確認と整形を待っていた。承認というニュースと、番号付き RFC、そして本番採用は区別しなければならない。

合意は往復して初めて成立する

クライアントは Connect-UDP-Bind: ?1 を送り、対応するプロキシは同じ真のブール値を返す。端点がこの機能を有効とみなすのは、その値を送信し、かつ受信した後である。異なる型の値は、フィールドがないものとして扱う。

HTTP の成功応答だけから機能を推測できない。プロキシ側も、固定宛先のリクエストを暗黙に複数相手用へ広げられない。

リクエストには二つの形がある。有効なホストとポートを残せば、バインド非対応時の固定宛先となる。二つの宛先変数をともに * にすれば、固定宛先を持たないバインド専用となる。片方だけが星印なら不正なリクエストである。この選択は Context ID 0 の意味を左右するため、監査記録に残す必要がある。

Proxy-Public-Address は資源台帳である

受理したプロキシは、少なくとも一つの公開 IP と空き UDP ポートを選び、リクエストに結び付けて Proxy-Public-Address で通知する。一つだけを示す場合、そのタプルはトンネルが閉じるまで安定しなければならない。複数なら、アドレスファミリーごとの安定性が推奨される。応答ヘッダーに載るため、後の変更を同じフィールドで伝えることはできない。

この安定性は ICE の候補として価値がある。しかし送信者の身元ではない。選ばれた相手も、未知のスキャナーも、そのソケットまでは到達し得る。

したがって、ログの主張を段階化するべきだ。「公開アドレス割り当て」は資源の確保、「パケット受信」は到達性を示すだけである。登録、方針通過、転送、クライアント配送、アプリケーション受理はまだ残っている。

Context ID が相手関係を状態にする

クライアントは偶数 ID、プロキシは奇数 ID を割り当てる。固定宛先のないバインド専用モードでは 0 は使えない。実際の固定フォールバック先がある場合だけ、0 は RFC 9298 の意味を保つ。

状態遷移には三種類の Capsule がある。COMPRESSION_ASSIGN（0x11）が ID の意味を提案し、COMPRESSION_ACK（0x12）が保存済みであることを返し、COMPRESSION_CLOSE（0x13）が拒否または終了を示す。

IP バージョン 0 は非圧縮コンテキストを作る。各データグラムに IP とポートが入り、クライアントからプロキシでは宛先、逆方向では受信元を示す。4 または 6 なら圧縮コンテキストで、タプルを一度登録し、以後は ID と UDP ペイロードだけを送る。

同じ ID の二重割り当て、同じタプルへの複数 ID、閉じた ID の再利用は禁止される。閉鎖後に並べ替えで遅れて届いたデータは黙って破棄する。古い番号が新しい関係の権限を持つことを防ぐ規則だ。

ACK 前の先行送信は許されるが、割り当てがまだ届いていないか拒否されればデータを失う。送信側が ID を使った事実と、受信側が登録を受け入れた事実を同じイベントにしてはいけない。

未知の送信元を受けるかはクライアントが決める

非圧縮コンテキストを要求できるのはクライアントだけで、同時に一つしか開けない。各受信データグラムが新しい送信元タプルを名乗れるため、その範囲は広い。

クライアントは最初から開かないことも、後で閉じることもできる。その場合、プロキシは未知の送信元に対するファイアウォールとして働く。既存の圧縮対応表は残るが、プロキシは新しい圧縮コンテキストを開けない。閉じた入口を別経路で復活させないためだ。

公開ポートを維持したまま権限だけを狭められる。割り当て、既知の相手、未知の相手は別々の状態として扱われる。

可変宛先には可変宛先の検査が要る

固定 CONNECT-UDP では、トンネル作成時に宛先を拒否できる。バインド型では宛先がデータグラムや登録メッセージへ移るため、検査もそこへ移る。

非圧縮データグラムなら、プロキシは毎回 IP とポートを禁止方針と照合する。圧縮なら、COMPRESSION_ASSIGN で提示されたタプルを調べ、許されない登録を拒否する。ループバック、リンクローカル、私設網、管理用サービスなど、具体的な範囲は運用者が決める。

TURN と比べると理解しやすい。リレーアドレスの割り当て、相手への permission、channel binding は独立した状態である。仕組みは同一ではないが、公開リレーを得ることと相手への許可を分ける点は共通する。

容量制限も安全性の一部である

受理した Context ID はメモリーを使う。フロー制御や輻輳制御で送れない ACK と CLOSE は応答バッファを使う。そのため、開ける ID 数と保留応答数には上限が必要であり、後者が尽きたプロキシはリクエストストリームを中断しなければならない。

上限は、設定値、使用量、拒否数、待ち時間、中断、クライアント版とともに観測する。記録がなければ、資源枯渇防止が原因不明の切断に見え、危険な緩和を招く。

圧縮状態の変更は実効 MTU も変える。非圧縮では毎回アドレスとポートが増え、圧縮では省かれる。途中の変化は DPLPMTUD を妨げ得るため、圧縮を使うなら早期に要求する。それでも、サイズ別損失と経路成功の実測が必要だ。

共有 IP だけでは責任を特定できない

RFC 6269 が扱う通り、IP 共有は評判と利用者の対応を粗くする。一つのプロキシ IP の背後には、多数のポート、トンネル、クライアント、Context ID、リモート相手が存在し得る。

不正利用の調査には、公開ポート、トンネル、認証済みクライアント、コンテキスト状態、相手タプル、方針結果、実際の転送結果が必要だ。境界で捨てたスキャンを、利用者へ届けた通信として扱ってはならない。

一つのデータグラムを説明する証拠

最低限、次の順序を結び付ける。

  1. 認証済みリクエストとトンネル識別子
  2. 双方向のバインド交渉
  3. 固定フォールバックまたは専用モード
  4. 公開タプルと存続期間
  5. Context ID の割当側と一意性
  6. ASSIGN、ACK、CLOSE
  7. 圧縮・非圧縮の意味
  8. 正確なリモート送信元または宛先
  9. 方針版と判定
  10. ID と応答バッファの余力
  11. 受理、破棄、一時保留
  12. 公開ソケットでの送受信
  13. クライアント配送と ICE またはアプリ結果

正しい登録があってもパケット損失や ICE 失敗は起こる。プロトコル状態は処理を許すが、実行結果だけが利用可能な経路を示す。文書は最小共通規則を定め、運用者はローカルなコードと観測で効果を証明する。これが Running-Code Primacy の実務である。

情報源