本メモの状態

これはインターネット標準トラックの文書です。¶

この文書はインターネットエンジニアリングタスクフォース（IETF）の成果物です。IETF コミュニティの合意を表しており、公開審査を経て Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準に関する詳細は RFC 7841 のセクション 2 を参照してください。¶

本文書の現状、訂正情報、およびフィードバックの送付方法に関する情報は https://www.rfc-editor.org/info/rfc9298 で入手できます。¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

目次

1. 導入

HTTP は TCP トンネルを作成するための CONNECT メソッド（参照: Section 9.3.6 of [HTTP]）を提供しますが、本仕様以前は UDP トラフィック用の同等の手段がありませんでした。¶

本書は、HTTP を介して UDP 専用のプロキシとして動作するサーバーへ UDP をトンネリングするためのプロトコルを記述します。UDP トンネルはエンドツーエンドの仮想接続を作成するために一般的に使用され、その上で QUIC [QUIC] や UDP 上で動作するその他のプロトコルにより保護できます。HTTP CONNECT メソッドとは異なり、UDP プロキシ自体はトラフィックの送信先を含む絶対 URL で識別されます。クライアントはそれらの URL を [TEMPLATE] によって生成し、その方法は セクション 2 に記載されます。¶

このプロトコルは HTTP Datagrams [HTTP-DGRAM] を使用することで、既存のすべての HTTP バージョンをサポートします。HTTP/2 [HTTP/2] または HTTP/3 [HTTP/3] を使用する場合は、[EXT-CONNECT2] および [EXT-CONNECT3] に記載された HTTP Extended CONNECT を使用します。HTTP/1.x [HTTP/1.1] を使用する場合は、Section 7.8 of [HTTP] に定義される HTTP Upgrade を使用します。¶

2. クライアント構成

HTTP クライアントは "target_host" と "target_port" という変数を持つ URI テンプレート [TEMPLATE] を用いて UDP プロキシを指定するように構成されます。以下に例を示します。¶

https://example.org/.well-known/masque/udp/{target_host}/{target_port}/
https://proxy.example.org:4443/masque?h={target_host}&p={target_port}
https://proxy.example.org:4443/masque{?target_host,target_port}

URI テンプレートには次の要件が適用されます：¶

• URI テンプレートはレベル 3 以下でなければなりません（MUST）。¶
• URI テンプレートは絶対形式であり、スキーム、オーソリティ、およびパスの各コンポーネントが空でないことを含める必要があります（MUST）。¶
• URI テンプレートのパス成分はスラッシュ ("/") で始まらなければなりません（MUST）。¶
• すべてのテンプレート変数はパスまたはクエリの成分内にある必要があります（MUST）。¶
• URI テンプレートは "target_host" と "target_port" の2つの変数を含まなければならず（MUST）、他の変数を含んでも差し支えありません（MAY）。¶
• URI テンプレートは非 ASCII の Unicode 文字を含んではならず（MUST NOT）、ASCII の範囲 0x21-0x7E の文字のみを含む必要があります（パーセントエンコーディングは許可されます；参照: Section 2.1 of [URI]）。¶
• URI テンプレートは Reserved Expansion ("+" 演算子)、Fragment Expansion ("#" 演算子)、Label Expansion with Dot-Prefix、Path Segment Expansion with Slash-Prefix、または Path-Style Parameter Expansion with Semicolon-Prefix を使用してはなりません（MUST NOT）。¶

クライアントは上記の要件を検証することが推奨されます（SHOULD）；ただし、一般的な URI テンプレート実装でこれらの特定の検証が欠けている場合、クライアントはそれを使用しても構いません（MAY）。クライアントが URI テンプレートが上記要件を満たしていないことを検出した場合、クライアントはその設定を拒否し、UDP プロキシへリクエストを送信することなく中止しなければなりません（MUST）。¶

元の HTTP CONNECT メソッドはターゲットホストとポートの伝達を許可していましたが、スキーム、プロキシのオーソリティ、パス、クエリは含んでいませんでした。そのため、プロキシホストとプロキシポートのみを設定するクライアント構成インターフェースを持つクライアントも存在します。そのような制約のある実装は、デフォルトテンプレートを使用して UDP プロキシ機能へアクセスしようとすることができます。デフォルトテンプレートは "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/udp/{target_host}/{target_port}/" と定義され、ここで $PROXY_HOST と $PROXY_PORT はそれぞれ構成された UDP プロキシのホストとポートです。UDP プロキシの実装は、これらのクライアントと相互運用する必要がある場合、この場所でサービスを提供することを推奨します（SHOULD）。¶

3. HTTP 上での UDP トンネリング

UDP を HTTP 上でトンネリングするためのネゴシエーションを可能にするために、本書は "connect-udp" という HTTP Upgrade トークンを定義します。生成される UDP トンネルは Capsule Protocol（参照: Section 3.2 of [HTTP-DGRAM]）と、セクション 5 で定義される形式の HTTP Datagrams を使用します。¶

単一の HTTP ストリームに関連付けられた UDP トンネルを開始するには、クライアントは "connect-udp" Upgrade トークンを含むリクエストを発行します。トンネルの宛先は、URI テンプレートの "target_host" および "target_port" 変数を介してクライアントによって UDP プロキシに示されます（参照: セクション 2）。¶

"target_host" は DNS 名、IPv6 リテラル、IPv4 リテラルの使用をサポートします。IPv6 スコープドアドレッシングのゾーン識別子はサポートされない点に注意してください。[URI] の IPv6address、IPv4address、reg-name、port の用語を用いると、"target_host" と "target_port" 変数は [ABNF] の表記を使用して 図 2 の形式に従わなければなりません（MUST）。さらに次の点に注意してください：¶

• "target_host" と "target_port" の両方は空であってはなりません（MUST NOT）。¶
• "target_host" が IPv6 リテラルを含む場合、コロン (":") はパーセントエンコーディングされなければなりません（MUST）。例えばターゲットホストが "2001:db8::42" の場合、URI では "2001%3Adb8%3A%3A42" とエンコードされます。¶
• "target_port" は 1 から 65535 までの整数である必要があります（MUST）。¶

target_host = IPv6address / IPv4address / reg-name
target_port = port

UDP プロキシング要求を送信する際、クライアントは URI テンプレート展開を実行してリクエストのパスおよびクエリを決定しなければなりません（SHALL）。¶

リクエストが成功した場合、UDP プロキシは受信した HTTP Datagrams を UDP パケットに変換し、その逆も行うことを、トンネルが閉じられるまで約束します。¶

Capsule Protocol の定義（参照: Section 3.2 of [HTTP-DGRAM]）により、UDP プロキシング要求はメッセージ本体を運ばないことに注意してください。同様に、成功した UDP プロキシングレスポンスもメッセージ本体を運びません。¶

GET https://example.org/.well-known/masque/udp/192.0.2.6/443/ HTTP/1.1
Host: example.org
Connection: Upgrade
Upgrade: connect-udp
Capsule-Protocol: ?1

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: connect-udp
Capsule-Protocol: ?1

HEADERS
:method = CONNECT
:protocol = connect-udp
:scheme = https
:path = /.well-known/masque/udp/192.0.2.6/443/
:authority = example.org
capsule-protocol = ?1

HEADERS
:status = 200
capsule-protocol = ?1

4. コンテキスト識別子

本書で定義される HTTP における UDP のプロキシ機構は、UDP ペイロードとは異なる意味を持つ HTTP Datagrams を交換するための将来の拡張を許容します。これらの拡張の一部は UDP ペイロードに追加データを付加することができ、他のものは UDP ペイロードとは完全に独立したデータを交換することができます。そのため、UDP プロキシング要求ストリームに関連付けられたすべての HTTP Datagrams は Context ID フィールドで始まります；参照: セクション 5。¶

Context ID は 62 ビット整数（0 から 2⁶²-1）です。Context ID は可変長整数としてエンコードされます；参照: Section 16 of [QUIC]。Context ID 値 0 は UDP ペイロード用に予約されており、非ゼロ値は動的に割り当てられます。非ゼロの偶数の Context ID はクライアント割り当て、奇数の Context ID はプロキシ割り当てです。Context ID 名前空間は特定の HTTP リクエストに結び付けられており、同じ数値の Context ID が異なるリクエストで同時に割り当てられ、異なる意味を持つ可能性があります。Context ID は特定の HTTP 名前空間内で再割り当てしてはなりません（MUST NOT）が、任意の順序で割り当てること MAY できます。偶数／奇数の割り当て制限はエンドポイント間の同期の必要性を回避するために存在します。しかし、一度 Context ID が割り当てられると、その使用に対するこれらの制限は適用されなくなり、その Context ID は当初割り当てたエンドポイントとは無関係に任意のクライアントまたは UDP プロキシによって使用できます。¶

登録は、エンドポイントが与えられた Context ID の意味と形式をピアに通知する行為です。本書は登録がどのように行われるかを定義しません。将来の拡張は Context ID を登録するために HTTP ヘッダーフィールドやカプセルを使用する MAY あります。使用される手法によっては、Context ID がまだ登録されていない状態で datagram が受信されることがあります。たとえば、datagram を含むパケットと登録メッセージを含むパケットが伝送中に順序入れ替わることが原因でこのような状況が生じ得ます。¶

5. HTTP データグラムのペイロード形式

UDP プロキシング要求ストリームに関連付けられた HTTP Datagrams（参照: Section 2 of [HTTP-DGRAM]）のとき、HTTP Datagram Payload フィールドは 図 7 に定義された形式を持ちます。表記は Section 1.3 of [QUIC] を使用しています。QUIC DATAGRAM フレームを用いて HTTP Datagrams がエンコードされる場合（[QUIC-DGRAM]）、以下に定義する Context ID フィールドは QUIC DATAGRAM フレームペイロードの先頭にある Quarter Stream ID フィールドの直後に置かれます；参照: Section 2.1 of [HTTP-DGRAM]。¶

UDP Proxying HTTP Datagram Payload {
  Context ID (i),
  UDP Proxying Payload (..),
}

Context ID:

可変長整数（参照: Section 16 of [QUIC]）で Context ID の値を含みます。未知の Context ID を含む HTTP/3 Datagram を受信した場合、受信者はその datagram を黙って破棄するか、対応する Context ID の登録を待つために一時的（おおむね往復時間程度）にバッファすること SHALL です。¶

UDP Proxying Payload:

前フィールドの値に依存する datagram のペイロードです。このフィールドは空にできる点に注意してください。¶

UDP パケットは Context ID フィールドがゼロに設定された HTTP Datagrams を用いてエンコードされます。Context ID フィールドがゼロの場合、UDP Proxying Payload フィールドは UDP パケットの修飾されていないペイロード（[UDP] における data octets と同じ）を含みます。¶

UDP ヘッダの定義上（[UDP]）、65527 バイトを超える UDP ペイロードをエンコードすることは不可能です。したがって、エンドポイントは Context ID がゼロの状態で UDP Proxying Payload フィールドが 65527 バイトを超える HTTP Datagrams を送信してはなりません（MUST NOT）。受信者が Context ID ゼロを使用する HTTP Datagram を受け取り、その UDP Proxying Payload フィールドが 65527 を超えている場合、受信者は対応するストリームを中止しなければなりません（MUST）。UDP プロキシが基盤となるリンクの MTU により送出可能な UDP パケットの長さが制限されていることを知っている場合、その限界を超える incoming の HTTP Datagrams（Context ID ゼロ）は破棄する他ありません。その破棄された HTTP Datagram が DATAGRAM カプセルで運ばれていた場合、受信者はそのカプセル内容をバッファせずにそのカプセルを破棄すること SHOULD です。¶

UDP プロキシが対応するリクエストを受け取る前に HTTP Datagram を受信した場合、受信者はその HTTP Datagram を黙って破棄するか、対応するリクエストを待つために一時的（おおむね往復時間程度）にバッファすること SHALL です。¶

datagram をバッファすること（リクエスト未着や Context ID 未登録のためいずれの場合も）はリソースを消費します。datagram をバッファする受信者は、リソース枯渇のリスクを低減するためにバッファ制限を適用すること SHOULD です。たとえば、受信者はバッファ済み datagram の総数や累積サイズを、ストリーム単位、コンテキスト単位、あるいは接続単位で制限できます。¶

クライアントは UDP プロキシング要求に対するレスポンスを受け取る前に楽観的に HTTP Datagrams 内で UDP パケットの送信を開始してもよい（MAY）。ただし、そのようなプロキシされたパケットは、UDP プロキシがリクエストに対して失敗で応答した場合や、UDP プロキシがリクエスト前に受信したプロキシ済みパケットをバッファしないと判断した場合には処理されない可能性があることに実装者は留意すべきです。¶

6. 性能に関する考慮事項

バースト性の高いトラフィックは時間的に相関したパケット損失を引き起こすことがあり、それが UDP 上で動作するプロトコルの輻輳制御に対して最適でない反応を招く可能性があります。これを避けるため、UDP プロキシは UDP トラフィックのバースト性を増大させないよう努めるべきであり（SHOULD）、バッチ処理を増やすためにパケットをキューイングすべきではありません（SHOULD NOT）。¶

プロキシ対象の UDP 上で動作するプロトコルが輻輳制御を使用する場合（例: [QUIC]）、プロキシされたトラフィックは少なくとも二重のネストされた輻輳制御を被ります。基盤となる HTTP 接続は、内部トラフィックが輻輳制御されていることを外部手段で絶対確実に知っている場合を除き、輻輳制御を無効にしてはなりません（MUST NOT）。¶

UDP プロキシング要求ストリームを含む接続を持つクライアントまたは UDP プロキシが輻輳制御を無効にする場合、その接続上で ECN（Explicit Congestion Notification、[ECN]）のサポートを示してはなりません（MUST NOT）。つまり、すべての IP ヘッダを Not-ECT コードポイントでマーキングしなければなりません（MUST）。ただし、ピアが輻輳制御を無効にしていない可能性があるため、QUIC の ACK_ECN フレームや TCP の ECE ビットを介して ECN フィードバックの報告を続けること MAY できます。¶

プロキシ対象の UDP 上で動作するプロトコルが損失回復を使用する場合（例: [QUIC]）、そして基盤となる HTTP 接続が TCP 上で動作する場合、プロキシされたトラフィックは少なくとも二重のネストされた損失回復機構を被ります。これは両者が同じデータを独立に再送することがあり得るため、性能を低下させる可能性があります。これを避けるため、UDP プロキシングは QUIC DATAGRAM フレームを利用できるように HTTP/3 上で実施すること SHOULD です。¶

7. セキュリティに関する考慮事項

任意のクライアントが任意のターゲットへのトンネルを確立できることには重大なリスクがあります。これにより悪意ある者がトラフィックを送信し、それが UDP プロキシに帰属するように見える可能性があります。UDP プロキシをサポートする HTTP サーバーは、その使用を認証済みユーザーに限定すべきです。¶

受信リクエストの送信元 IP アドレスに基づいてアクセス制御を行うソフトウェアやネットワークの展開が存在します。たとえば、127.0.0.1 から発生した場合に認証なしで設定変更を許すソフトウェアがあります。そのようなソフトウェアが UDP プロキシと同じホスト上、あるいは同じブロードキャストドメイン上で動作している可能性があります。プロキシ経由の UDP トラフィックは UDP プロキシのソース IP アドレスで受信されるため、そのソースアドレスがアクセス制御に使用されている場合、UDP プロキシングクライアントは UDP プロキシを用いて本来持たないアクセス特権をエスカレートできる可能性があります。このため、UDP プロキシは UDP プロキシ自身のアドレスや localhost、リンクローカル、マルチキャスト、ブロードキャストアドレスなどの脆弱なターゲットへの UDP プロキシング要求を拒否すべきです。UDP プロキシはそのような要求を拒否する際に、Proxy-Status の destination_ip_prohibited Proxy Error Type を使用できます（参照: Section 2.3.5 of [PROXY-STATUS]）。¶

UDP プロキシはインフラとして濫用される点で TCP CONNECT プロキシと多くの類似性があります。どちらも攻撃者の送信元アドレスを攻撃対象から隠すことができます。ステートレスなボリューム型攻撃（例：TCP SYN フラッドや UDP フラッド）の場合、両タイプのプロキシはトラフィックをターゲットに渡します。ステートフルなボリューム型攻撃（例：HTTP フラッディング）が TCP CONNECT プロキシ経由で送られる場合、ターゲットが TCP SYN-ACK で応答しない限りプロキシはデータを送信しません。ターゲットへの経路がフラッドされると、TCP CONNECT プロキシはターゲットからの応答を受け取らなくなり、送信を停止します。UDP はターゲットとの間で共有状態を確立しないため、UDP プロキシはそのような状況でもターゲットへの送信を続ける可能性があります。UDP プロキシはターゲットからの応答を観測するまで転送する UDP パケット数を制限することによりある程度の保護を提供できるかもしれませんが、プロトコルがオープンな UDP ポートを標的とする場合には限定的な保護にしかなりません。そのようなパケット制限は正当なトラフィックにも問題を引き起こす可能性があります。¶

Section 4 of [HTTP-DGRAM] に記載されたセキュリティ考慮事項もここに適用されます。IP パケットを UDP 上でトンネルできるため、[TUNNEL-SECURITY] のガイダンスが適用される場合があります。¶

8. IANA に関する考慮事項

謝辞

この文書は MASQUE ワーキンググループの成果物であり、著者は MASQUE に関わるすべての参加者に感謝します。本提案は多くの人々による先行作業に直接的または間接的に触発されました。特に [HELIUM]（Ben Schwartz）、[HiNT]（Lucas Pardue）、および著者によるオリジナルの MASQUE プロトコル [MASQUE-ORIGINAL] に感謝します。¶

著者は Eric Rescorla に HTTP メソッドを使用して UDP をプロキシするという提案を示唆してくれたことに感謝します。Mark Nottingham と Lucas Pardue は本書に多くの改善を提供してくれました。本書の拡張性設計は HTTP Datagrams デザインチーム（Alan Frindell、Alex Chernyakhovsky、Ben Schwartz、Eric Rescorla、Lucas Pardue、Marcus Ihlar、Martin Thomson、Mike Bishop、Tommy Pauly、Victor Vasiliev、および著者）による議論から生まれました。¶

著者の連絡先