| インターネット技術タスクフォース (IETF) | M. Nottingham |
| Request for Comments: 7838 | Akamai |
| カテゴリー: 標準トラック | P. McManus |
| ISSN: 2070-1721 | Mozilla |
| J. Reschke | |
| greenbytes | |
| 2016年4月 |
HTTP 代替サービス
概要
本書は HTTP の「代替サービス」を規定します。これにより、オリジンのリソースを別のネットワーク上の場所で正規に公開でき、場合によっては異なるプロトコル構成でアクセスできるようになります。
本メモの状態
これはインターネット標準トラックの文書です。
この文書は Internet Engineering Task Force (IETF) の成果物です。IETF コミュニティの合意を表しています。公開審査を受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準に関するさらなる情報は RFC 5741 のセクション 2 をご覧ください。
この文書の現状、訂正情報、およびフィードバックの送付方法に関する情報は http://www.rfc-editor.org/info/rfc7838 で入手できます。
Copyright Notice
Copyright (c) 2016 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. 導入
HTTP [RFC7230] は、リソースの識別とその位置を同一視しています。言い換えれば、"http://" と "https://" の URI は、対象を識別するためにも、アクセスするためにも使われます。
場合によっては、HTTP において識別と場所を分離し、同じ識別子を維持しつつネットワーク上の別の場所でやり取りすることが望ましいことがあります。
例えば:
- オリジンサーバーは、負荷が高いときやクライアントにより近いロケーションのサーバーを見つけたときに、クライアントを別のサーバーへリダイレクトしたい場合があります。
- オリジンサーバーは、HTTP/2 [RFC7540] のような新しいプロトコル、または Transport Layer Security (TLS) [RFC5246] のような改善されたセキュリティを用いてリソースへのアクセスを提供したい場合があります。
- オリジンサーバーは、運用上の理由から Server Name Indication (SNI)（Section 3 of [RFC6066]）をサポートするクライアントなど、クライアントを機能別に分割したい場合があります。
本仕様は HTTP における新しい概念「代替サービス（Alternative Services）」を定義します。オリジンのリソースがネットワーク上の別の場所でも正規に利用可能であることをオリジンサーバーが指名できるようにします。セクション 2（代替サービスの概念）では一般的なフレームワークを定義し、HTTP ヘッダーフィールド（セクション 3、Alt-Svc ヘッダーフィールド）や HTTP/2 フレーム（セクション 4、ALTSVC HTTP/2 フレーム）を用いてそれらの存在を通知する具体的な仕組み、および代替サービスが使用されたことを示す方法（セクション 5、Alt-Used ヘッダーフィールド）を定義します。
また、誤った場所が使用された場合にオリジンサーバーまたはその指定された代替が権限を持たないことを示すために、ステータスコード 421 (Misdirected Request)（セクション 6、421 (Misdirected Request) HTTP ステータスコード）を推奨します。
1.1. 表記規約
この文書内のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は、RFC2119 に記載されているとおりに解釈されます。
この文書は、RFC5234 で定義され、RFC7405 によって更新された拡張 BNF（ABNF）と、RFC7230 の Section 7 にある "#rule" 拡張を使用します。以下のルールは RFC5234、RFC7230、および RFC7234 に定義されています：
OWS = <OWS, see [RFC7230], Section 3.2.3> delta-seconds = <delta-seconds; see [RFC7234], Section 1.2.1> port = <port, see [RFC7230], Section 2.7> quoted-string = <quoted-string, see [RFC7230], Section 3.2.6> token = <token, see [RFC7230], Section 3.2.6> uri-host = <uri-host, see [RFC7230], Section 2.7>
2. 代替サービスの概念
本仕様は HTTP における新しい概念 "代替サービス（Alternative Service）" を定義します。オリジン [RFC6454] が異なるプロトコル/ホスト/ポートの組み合わせを通じてアクセス可能なリソースを持つ場合、そのオリジンは代替サービスを持つとされます。
代替サービスは、ネットワーク上の別の場所でオリジンサーバーのリソースとやり取りするために使用でき、場合によっては異なるプロトコル構成を使用することがあります。代替サービスは、[RFC7230] の意味で、オリジンのリソースについて権威を持つものと見なされます（Section 9.1 参照）。
例えば、あるオリジン：
("http", "www.example.com", "80")
が、以下の代替サービスでもリソースにアクセスできると宣言するかもしれません：
("h2", "new.example.com", "81")
代替サービスはその性質上、オリジンの粒度で明示的に適用されます。オリジン内のリソースに対して選択的に適用することはできません。
代替サービスは、あるリソースのオリジンを置き換えたり変更したりするものではありません。一般に、アクセス機構より上位のソフトウェアには見えません。代替サービスは基本的に代替のルーティング情報であり、DNS の CNAME や SRV レコードが名前解決レベルでルーティング情報を定義するのと同様に、オリジンに到達するために使用できます。各オリジンはこれらのルートの集合にマップされます — デフォルトのルートはオリジン自体から導出され、他のルートは代替サービス情報に基づいて導入されます。
さらに、代替サービスタプルの最初の要素はオリジンの "scheme" コンポーネントとは異なります。これはより具体的であり、使用されるプロトコルの主要なバージョンだけでなく、そのプロトコルの通信オプションも識別する可能性があります。
これは、代替サービスを使用するクライアントがリソースを取得するためにホスト、ポート、およびプロトコルを変更できることを意味しますが、これらの変更は HTTP を使用しているアプリケーションに伝播してはなりません（MUST NOT）。その観点から、アクセスされている URI およびそこから派生するすべての情報（scheme、host、port）は従前と同じままです。
重要なことに、これにはセキュリティコンテキストも含まれます。特に、TLS [RFC5246] を用いて認証が行われる場合、代替サービスは代替のホスト名ではなくオリジンのホスト名の証明書を提示する必要があります。同様に、Host ヘッダーフィールド（[RFC7230]、Section 5.4）は代替サービスではなくオリジンから導出されます（CNAME を使用する場合と同様です）。
これらの変更はデバッグツールやコンソール等で表示される場合があります（MAY）。
形式的には、代替サービスは以下の組み合わせで識別されます：
ALPN プロトコル名は、代替サービスが使用するアプリケーションプロトコルまたはプロトコル群を識別するために使われます。本仕様の目的上、ALPN プロトコル名は定義で別段の記載がない限り TLS をプロトコル群に暗黙的に含むものと見なされます。特に、ALPN 名 "http/1.1"（RFC7301 の Section 6 に登録）は TLS 上の HTTP/1.1 を識別します。
さらに、各代替サービスは有効寿命（秒単位）を持たなければなりません（Section 2.2参照）。
クライアントがオリジンに関連する代替サービスを発見する方法は複数あります。本書では二つの仕組みを説明します：Alt-Svc ヘッダーフィールド（セクション 3）と ALTSVC HTTP/2 フレームタイプ（セクション 4）。
このセクションの残りは、発見方法に関係なく代替サービスに共通する要件を説明します。
2.1. ホスト認証
クライアントは代替サービスがオリジン全体の管理下にあり、当該オリジンに対して有効であるという合理的な保証を持つこと（MUST）が必要です。これはセクション 9.2 の攻撃を軽減します。
本書の目的上、「合理的な保証」は RFC2818 に定義された証明書検証を含む TLS ベースのプロトコルの使用によって確立できます。クライアントは合理的な保証を確立するために追加の基準を課すことができます（MAY）。
例えば、オリジンのホストが "www.example.com" で代替が "other.example.com"、プロトコルが "h2" の場合に、提示された証明書が "www.example.com" に対して有効であればクライアントは代替を使用できます。しかし、どちらかが "h2c" で提供されている場合、当該プロトコルではオリジンと代替の関係を確立する手段がないためクライアントはそれを使用できません。
2.2. 代替サービスのキャッシュ
代替サービスを発見するためのメカニズムは、それらに対して有効寿命を関連付けます。例えば Alt-Svc ヘッダーフィールドは "ma" パラメータを使用します。
クライアントは、代替サービス情報が新鮮である限りいつでもオリジンの代わりに代替サービスを使用することができます（詳細は Section 2.4 を参照）。
代替サービスへの既存の接続を持つクライアントは、その有効寿命が切れてもそれを使い続ける必要はありません。キャッシュ機構は新しい接続を確立するために代替サービスを使用できる期間を制限するためのものであり、既存の接続の利用を制限するものではありません。
代替サービスは当該オリジンについて完全に権威的であり、キャッシュされた代替サービスエントリをクリアまたは更新し、有効寿命を延長し、オリジンサーバーが持つその他の権限を行使できます。
代替サービスがクライアントを最適なサーバーへ誘導するために使用される場合、ネットワーク構成の変化によりキャッシュされた値が最適でなくなることがあります。そのため、クライアントはネットワーク状態に関する情報が利用可能なときに、"persist" フラグに値 "1" を持たないすべての代替サービスをキャッシュから削除することを推奨します（SHOULD）。
2.3. サーバー名表示の要求
クライアントは SNI（TLS Server Name Indication）をサポートしていない限り、TLS ベースの代替サービスを使用してはなりません（MUST NOT）。これは代替サービスホスト上の IP アドレスの節約を助けます。
TLS によって TLS クライアントが提供する SNI 情報は代替ではなくオリジンのものになる点に注意してください（Host ヘッダーフィールドの値も同様です）。
2.4. 代替サービスの利用
代替サービスはその性質上 OPTIONAL です：クライアントはそれらを使用する必要はありません。ただし、サーバーが代替サービスを利用する際にクライアントが予測可能な動作をすることは、負荷分散のような目的に資するため有利です。
したがって、本仕様をサポートするクライアントが代替サービスを認識した場合、代替サービス情報が新鮮であり（Section 2.2）、代替サービスのプロトコルのセキュリティ特性が既存の接続と比較して望ましい場合、クライアントは関連するオリジンへのすべてのリクエストに対してその代替サービスを利用すべきです（SHOULD）。有効な代替サービスはその後オリジンと同様に扱われます。これには代替サービスを広告する能力も含まれます。
クライアントが複数の代替サービスを認識した場合、セキュリティ特性を考慮しつつ自身の基準に従って最適なものを選択します。例えば、オリジンが複数のバージョンの HTTP をサポートしていることを通知するために複数の代替サービスを広告することがあります。
あるリクエストのためにプロキシを使用するように設定されたクライアントは、そのリクエストのために直接代替サービスに接続してはならず（SHOULD NOT）、代わりにそのプロキシを経由してルーティングすべきです。
クライアントがリクエストのために代替サービスを使用する場合、Alt-Used ヘッダーフィールド（セクション 5）を使用してサーバーにこれを通知できます。
クライアントは既存の接続上のリクエストをブロックする必要はありません；代替接続が確立されるまで既存の接続を使用できます。ただし、既存接続のセキュリティ特性が弱い場合（例えば平文の HTTP/1.1）には、新しい接続が完全に利用可能になるまでブロックして情報漏洩を避ける方が理にかなっていることがあります。
さらに、代替サービスへの接続が失敗するか応答しない場合、クライアントはオリジンまたは他の代替サービスへフォールバックすることができます（MAY）。ただし、これはダウングレード攻撃の原因となり得るため、代替サービスの強化されたセキュリティ特性を失うことになります。代替サービスへの接続が期待されたプロトコルをネゴシエートしない場合（例えば ALPN が h2 をネゴシエートしない、または h2c への Upgrade 要求が受け入れられない場合）、その接続は失敗したものとみなさなければなりません（MUST）。
3. Alt-Svc HTTP ヘッダーフィールド
HTTP(S) オリジンサーバーはレスポンスに Alt-Svc ヘッダーフィールドを追加することで、クライアントに代替サービスの利用可能性を通知できます。
Alt-Svc = clear / 1#alt-value clear = %s"clear"; "clear", case-sensitive alt-value = alternative *( OWS ";" OWS parameter ) alternative = protocol-id "=" alt-authority protocol-id = <a href="#imported.abnf" class="smpl">token</a> ; percent-encoded ALPN protocol name alt-authority = <a href="#imported.abnf" class="smpl">quoted-string</a> ; containing [ <a href="#imported.abnf" class="smpl">uri-host</a> ] ":" <a href="#imported.abnf" class="smpl">port</a> parameter = <a href="#imported.abnf" class="smpl">token</a> "=" ( <a href="#imported.abnf" class="smpl">token</a> / <a href="#imported.abnf" class="smpl">quoted-string</a> )
フィールド値は、各々が一つの代替サービスを示す値のリスト、またはキーワード "clear" のいずれかで構成されます。
特殊値 "clear" を含むフィールド値は、オリジンがそのオリジンに対するすべての代替を無効化することを要求していることを示します（同じレスポンスに "clear" と代替サービスが両方含まれている場合のような、無効な応答を含む場合も含む）。
ALPN プロトコル名はオクテット列であり、形式に関する追加の制約はありません。トークンで許可されないオクテット（RFC7230 Section 3.2.6 参照）は、RFC3986 Section 2.1 に従ってパーセントエンコーディングされなければなりません。したがって、パーセント文字 "%"（16 進で 25）を表すオクテットもパーセントエンコードされなければなりません。
任意の ALPN プロトコル名を正確に一つの方法で表現するために、以下の追加制約が適用されます：
- ALPN プロトコル名内のオクテットは "%" を除きトークン文字として有効であればパーセントエンコードしてはなりません、
- パーセントエンコーディングを使用する場合は大文字の16進数字を使用しなければなりません。
これらの制約により、受信者は単純な文字列比較でプロトコル識別子を照合できます。
"alt-authority" コンポーネントは OPTIONAL な uri-host（RFC3986 Section 3.2.2 の "host"）とコロン（":"）とポート番号で構成されます。
例えば：
Alt-Svc: h2=":8000"
これは同一ホスト上のポート 8000 で "h2" プロトコル（RFC7540）を示します。
ホストを変更する例：
Alt-Svc: h2="new.example.org:80"
これはホスト "new.example.org" のポート 80 で "h2" プロトコルを示します。":" は "token" で許可されないため "quoted-string" 構文を使用する必要がある点に注意してください。
プロトコル名のエスケープ例：
| ALPN プロトコル名 | protocol-id | 注記 |
|---|---|---|
| h2 | h2 | エスケープ不要 |
| w=x:y#z | w%3Dx%3Ay#z | "=" と ":" をエスケープ |
| x%y | x%25y | "%" をエスケープする必要あり |
Alt-Svc は任意の HTTP レスポンスメッセージで現れてよく、ステータスコードに依存しません。Alt-Svc を受け取った受信者はこれを無視することができます（特定の状況では無視が要求されます；詳しくはセクション 2.1 と 6 を参照）。
Alt-Svc フィールド値は複数の値を持つことができます：
Alt-Svc: h2="alt.example.com:8000", h2=":443"
複数の値が存在する場合、値の順序はサーバーの優先順位を反映します（最初の値が最も優先されます）。
Alt-Svc によって広告された値は、クライアントが代替サービスへの新しい接続を開くために使用できます。後続のリクエストはこの新しい接続を直ちに使用開始するか、既存の接続を使用し続けながら新しい接続を作成することができます。
HTTP/2 を使用する場合、サーバーは代わりに ALTSVC フレーム（セクション 4）を送信すべきです（SHOULD）。単一の ALTSVC フレームは接続ごとに送信できます；すべてのリクエストごとに新しいフレームを送る必要はありません。それにもかかわらず、HTTP/2 上で配信されたレスポンス内の Alt-Svc ヘッダーフィールドは有効です。
各 "alt-value" の後にはセミコロンで区切られた追加パラメータの OPTIONAL リストが続くことがあり、各 "parameter" は名前と値からなります。
本仕様は "ma" と "persist" の二つのパラメータを定義します（セクション 3.1）。未知のパラメータは MUST 無視されなければなりません。すなわち、それらが現れる値（alt-value）は未知のパラメータが存在しないかのように処理されなければなりません。
新しいパラメータは拡張仕様で定義できます（登録の詳細はセクション 7.3 を参照）。
"quoted-string" 構文を許すすべてのフィールド要素は RFC7230 の Section 3.2.6 に従って処理されなければなりません（MUST）。
3.1. Alt-Svc ヘッダーフィールド値のキャッシュ
Alt-Svc を使用して代替サービスが広告されると、それはそのメッセージ生成から 24 時間新鮮と見なされます。これは "ma"（max-age）パラメータで変更できます。
構文：
ma = <a href="#imported.abnf" class="smpl">delta-seconds</a>; see [RFC7234], Section 1.2.1
delta-seconds 値はレスポンスが生成されてから代替サービスが新鮮と見なされるまでの秒数を示します。
Alt-Svc: h2=":443"; ma=3600
レスポンスの経過時間の決定に関しては RFC7234 の Section 4.2.3 を参照してください。
例えば、次のレスポンスは：
HTTP/1.1 200 OK Content-Type: text/html Cache-Control: max-age=600 Age: 30 Alt-Svc: h2=":8000"; ma=60
代替サービスが今後 60 秒間利用可能であることを示します。ただし、レスポンスは既に 30 秒キャッシュされているため（Age ヘッダの値）、実際にはこのレスポンスを受信してから推定転送時間を差し引いた 30 秒間だけ代替サービスは新鮮です。
HTTP キャッシュの新鮮度（ここでは 600 秒）は Alt-Svc 値のキャッシュには影響しない点に注意してください。
オリジンから Alt-Svc レスポンスヘッダーフィールドを受け取った場合、その値は当該オリジンに対するキャッシュされたすべての代替サービスを無効化し置き換えます。
デフォルトでは、クライアントはネットワーク変更を検出したときにキャッシュされた代替サービスをクリアします。クライアントアクセスネットワークに特有でない長寿命の代替サービスは、"persist" パラメータを値 "1" で持ち、ネットワーク構成の変更を超えて有用であることを示すヒントを与えることができます。
構文：
persist = "1"
例えば：
Alt-Svc: h2=":443"; ma=2592000; persist=1
本仕様は "persist" に対して単一の値のみを定義します。クライアントは "1" 以外の値を持つ "persist" パラメータを無視しなければなりません（MUST）。
代替サービスのキャッシュに関する一般要件はセクション 2.2 を参照してください。
4. ALTSVC HTTP/2 フレーム
ALTSVC HTTP/2 フレーム（RFC7540、Section 4） は、HTTP/2 クライアントに代替サービスの利用可能性を通知します。
ALTSVC フレームは HTTP/2 に対する非クリティカルな拡張です。このフレームをサポートしていないエンドポイントは無視します（RFC7540 の拡張ルールに従う）。
ストリーム 0 以外のストリームでサーバーからクライアントへ送られた ALTSVC フレームは、伝達された代替サービスがそのストリームのオリジンに関連付けられていることを示します。
ストリーム 0 の ALTSVC フレームは、フレームの Origin フィールドに含まれるオリジンに関連付けられた代替サービスを示します。クライアントが現在の接続に対して権威があると見なさないオリジンに関連付けられたものは無視しなければなりません（MUST）。
ALTSVC フレームタイプは 0xa（10）です。
+-------------------------------+-------------------------------+ | Origin-Len (16) | Origin? (*) ... +-------------------------------+-------------------------------+ | Alt-Svc-Field-Value (*) ... +---------------------------------------------------------------+
図 1: ALTSVC フレームペイロード
ALTSVC フレームは以下のフィールドを含みます：
- Origin-Len:
- Origin フィールドの長さをオクテット単位で示す符号なし 16 ビット整数。
- Origin:
- OPTIONAL な文字列列で、代替サービスが適用されるオリジンの ASCII シリアライゼーションを含みます（RFC6454 Section 6.2 参照）。
- Alt-Svc-Field-Value:
- 一連のオクテット（フレーム長から先行するすべてのフィールドの長さを差し引いて決定される長さ）で、Section 3 で定義された Alt-Svc フィールド値（ABNF 生成規則 "Alt-Svc"）と同一の値を含みます。
ALTSVC フレームはフラグを定義しません。
ALTSVC フレームはクライアントによる受信を意図しています。サーバーとして振る舞うデバイスはこれを無視しなければなりません（MUST）。
ストリーム 0 上の Origin 情報が空（長さ 0）の ALTSVC フレームは無効であり無視されなければなりません（MUST）。ストリーム 0 以外のストリームで非空の Origin 情報を含む ALTSVC フレームは無効であり無視されなければなりません（MUST）。
ALTSVC フレームはホップバイホップで処理されます。仲介者は ALTSVC フレームを転送してはならず（MUST NOT）、ただし自身のクライアントに送るための新しい ALTSVC フレームを作成する際にその情報を使用することはできます。
ALTSVC フレームを受信することは Alt-Svc ヘッダーフィールドを受信することと意味的に同等です。その結果、ALTSVC フレームは対応するオリジンの代替サービスを置き換えます。Alt-Svc ヘッダーフィールドと ALTSVC フレームの使用を混在させるのは、受信の順序が予測困難になるため賢明ではありません。
5. Alt-Used HTTP ヘッダーフィールド
Alt-Used ヘッダーフィールドは、Host ヘッダーフィールド（RFC7230 Section 5.4）と同様に、リクエストで使用されている代替サービスを識別するために使われます。
Alt-Used = uri-host [ ":" port ]
Alt-Used は、代替サービスがループを検出したり、負荷分散のためにトラフィックを差別化したり、トラフィックの意図された宛先を識別できるようにすることを目的としています。プロトコルが既に使用されている後でこの情報を導入するのは問題を生じやすいことが実証されています。
代替サービスを使用する場合、クライアントはすべてのリクエストに Alt-Used ヘッダーフィールドを含めるべきです（SHOULD）。
例えば：
GET /thing HTTP/1.1 Host: origin.example.com Alt-Used: alternate.example.net
6. 421 (Misdirected Request) HTTP ステータスコード
421 (Misdirected Request) ステータスコードは RFC7540 の Section 9.1.2 で定義されており、現在のサーバーインスタンスが要求されたリソースに対して権威を持たないことを示します。これは代替サービスが権威を持たないことを示すためにも使用できます（セクション 2 を参照）。
代替サービスから 421 を受け取ったクライアントは、当該オリジンに対する代替サービスキャッシュから対応するエントリを削除しなければなりません（MUST; セクション 2.2 参照）。リクエストメソッドの冪等性に関わらず、クライアントはリクエストを別の代替サーバーまたはオリジンへ再試行してもよい（MAY）です。
421 レスポンスに含まれる Alt-Svc ヘッダーフィールドは無視されなければなりません（MUST）。
7. IANA の考慮事項
7.1. ヘッダーフィールド登録
HTTP ヘッダーフィールドは IANA が管理する "Message Headers" レジストリに登録されます（https://www.iana.org/assignments/message-headers/）。
本書は以下の HTTP ヘッダーフィールドを定義しているため、恒久的登録に従ってそれらの関連するレジストリエントリが追加されました（BCP90 参照）：
Change Controller は "IETF (iesg@ietf.org) -- Internet Engineering Task Force" です。
7.2. ALTSVC HTTP/2 フレームタイプ
本書は ALTSVC フレームタイプを "HTTP/2 Frame Type" レジストリに登録します（RFC7540, Section 11.2）。
- Frame Type: ALTSVC
- Code: 0xa
- Specification: Section 4 of this document
7.3. Alt-Svc パラメータ登録
"HTTP Alt-Svc Parameter Registry" はパラメータの名前空間を定義します。これは <http://www.iana.org/assignments/http-alt-svc-parameters> に作成され、維持されます。
7.3.1. 手続き
登録には以下のフィールドが含まれなければなりません（MUST）：
- Parameter Name
- Pointer to specification text
この名前空間に追加される値は Expert Review を必要とします（RFC5226 Section 4.1 参照）。
7.3.2. 登録
"HTTP Alt-Svc Parameter Registry" には以下の登録が含まれています：
| Alt-Svc パラメータ | 参照 |
|---|---|
| ma | Section 3.1 |
| persist | Section 3.1 |
8. 国際化に関する考慮事項
ヘッダーフィールド（セクション 3）または HTTP/2 フレーム（セクション 4）に現れる国際化ドメイン名は、A-label（RFC5890 Section 2.3.2.1）を使用して表現されなければなりません（MUST）。
9. セキュリティに関する考慮事項
9.1. ポートの変更
代替サービスを使用するということは、少なくとも代替のポートでオリジンのリソースにアクセスすることを意味します。したがって、代替サービスを挿入し広告されたポートで受信できる攻撃者はオリジンをハイジャックできます。特定のサーバーでは、ユーザーが共有ポート上でいくつかの個人ページを制御でき、特権の低いポートでリクエストを受け付けることが通常あります。
例えば、攻撃者があるページに HTTP レスポンスヘッダーフィールドを追加できる場合、Alt-Svc ヘッダーフィールドを使用して同じホスト上の異なるポートへオリジン全体のトラフィックをリダイレクトできます。そのポートが攻撃者の管理下にあれば、攻撃者は HTTP サーバーになりすますことができます。
このリスクはセクション 2.1 の要件によって緩和されます。
サーバー側では、代替サービスを広告できる権限やそのホスト上でリスンするポートを開ける者を制限することで、このリスクを低減できます。
9.2. ホストの変更
代替サービスの使用によりホストが変更される場合、攻撃者がオリジンへの通信をハイジャックする機会が生じます。
例えば、攻撃者がユーザーエージェントに対して "innocent.example.org" のすべてのトラフィックを "evil.example.com" に送らせるように代替サービスを関連付けられれば、攻撃者はそのオリジンになりすますことができます。これはローカルに行われる場合（ポート変更の緩和策を参照）や中間者によるリモート（man-in-the-middle）攻撃として行われる可能性があります。
これが、代替サービスがオリジンの管理下にあり有効であるという合理的な保証をクライアントが持つことを要求する（セクション 2.1）の理由です。例えばオリジンのための証明書を提示することで代替サービスがオリジンのトラフィックを配信する権限を持つことを証明できます。
この保証は代替サービスを認証するために用いられる方法の強度に依存します。特に TLS 認証を用いる場合、攻撃者の証明書を正当なものに見せかける既知の攻撃が存在する点に注意してください。
代替サービスはそのような攻撃を持続させるために利用され得ます。例えば中間者がターゲットへの TLS 保護通信を中間者攻撃で傍受し、その後長い有効寿命を持つ代替サービスへすべてのトラフィックを誘導すれば、ユーザーエージェントは中間者を通さない場合でも攻撃者にトラフィックを送り続けることになります。
実装は代替サービスでも証明書ピンニング検証（RFC7469 など）を直接接続時と同様に実行しなければなりません（MUST）。実装は代替サービスに対してどの証明書が受け入れ可能かについて追加の要件を設けることもできます。
9.3. プロトコルの変更
代替サービスの使用により ALPN プロトコルが変更される場合、新しい接続のセキュリティ特性は「通常の」オリジンへの接続と異なることがあります。プロトコル識別子自体がそれを示唆するためです。
例えば、"https://" URI に対してエンドツーエンド暗号化（TLS 等）を使用しないプロトコルが広告されている場合、これは URI スキームが暗示するセキュリティの期待を裏切ります。したがって、クライアントは代替サービスを盲目的に使用してはならず、提示された選択肢が仕様、実装、エンドユーザーのセキュリティ要件と期待を満たすか評価しなければなりません。
9.4. 代替サービスを利用するクライアントの追跡
代替サービスを選ぶことはサーバーが供給した新しいホスト名に接続することを意味します。サーバーがユニークな名前を使用すると、クライアント要求を追跡できるようになります。特に "persist" フラグが使われる場合、複数のネットワークに跨ってユーザーを追跡できる可能性があります。
リクエストの相関を防ぎたいクライアントは、相関されるべきでない複数のリクエストに対して代替サービスを使用しないことを決定できます。
ユーザーエージェントでは、オリジン固有データがクリアされる（通常クッキーがクリアされる）際に、代替サービス情報もすべて削除されなければなりません（MUST）。
9.5. リクエストスキームに関する混乱
一部のサーバーサイド HTTP アプリケーションは接続のコンテキストに基づいてセキュリティを仮定します。例えば、ポート 443 で提供されることを "https://" URI の使用と同一視し、それが暗示するさまざまなセキュリティ特性を前提とすることがあります。
これは接続自体のセキュリティ特性だけでなく、接続先クライアント側の状態にも影響します。例えば Web ブラウザは多くの場合、"https://" と "http://" を扱いで区別します。
代替サービスの用途の一つは接続を異なるプロトコルやポートに移行することにありますが、これらのアプリケーションはある接続のセキュリティ特性を混乱させ、セキュアなコンテキスト向けの情報（例：クッキーやコンテンツ）をそれをセキュアとして扱わないクライアントへ送ってしまうことがあります。
このリスクは、サーバーがプロトコルで明示的に運ぶ URI スキーム（HTTP/2 の ":scheme" や HTTP/1.1 のリクエストターゲットの absolute form）をセキュリティコンテキストの指標として使用することで軽減できます（RFC7540 Section 8.1.2.3 および RFC7230 Section 5.3.2 を参照）。
プロトコルがスキームを明示的に運ばない場合（通常は TLS 上の HTTP/1.1 でのように）、サーバーはすべてのリクエストを非安全コンテキストと見なすか、非安全なスキーム（例：HTTP）のために代替サービスを広告しないことでこのリスクを軽減できます。
10. 参考文献
10.1. 規範的参考文献
- [RFC2119]
- Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
- [RFC2818]
- Rescorla, E., “HTTP Over TLS”, RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
- [RFC3986]
- Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
- [RFC5226]
- Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
- [RFC5234]
- Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
- [RFC5890]
- Klensin, J., “Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework”, RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
- [RFC6066]
- Eastlake, D., “Transport Layer Security (TLS) Extensions: Extension Definitions”, RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
- [RFC6454]
- Barth, A., “The Web Origin Concept”, RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.
- [RFC7230]
- Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
- [RFC7234]
- Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Caching”, RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
- [RFC7301]
- Friedl, S., Popov, A., Langley, A., and S. Emile, “Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”, RFC 7301, DOI 10.17487/RFC7301, July 2014, <http://www.rfc-editor.org/info/rfc7301>.
- [RFC7405]
- Kyzivat, P., “Case-Sensitive String Support in ABNF”, RFC 7405, DOI 10.17487/RFC7405, December 2014, <http://www.rfc-editor.org/info/rfc7405>.
- [RFC7540]
- Belshe, M., Peon, R., and M. Thomson, Ed., “Hypertext Transfer Protocol version 2”, RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
10.2. 参考資料
- [BCP90]
- Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004, <http://www.rfc-editor.org/info/bcp90>.
- [RFC5246]
- Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
- [RFC6265]
- Barth, A., “HTTP State Management Mechanism”, RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
- [RFC7469]
- Evans, C., Palmer, C., and R. Sleevi, “Public Key Pinning Extension for HTTP”, RFC 7469, DOI 10.17487/RFC7469, April 2015, <http://www.rfc-editor.org/info/rfc7469>.
謝辞
Adam Langley, Bence Beky, Chris Lonvick, Eliot Lear, Erik Nygren, Guy Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, Matthew Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard Bradbury, Stephen Farrell, Stephen Ludin, and Will Chan に感謝します。フィードバックと提案に感謝します。
Alt-Svc ヘッダーフィールドは SPDY の Alternate-Protocol ヘッダーフィールドの設計の影響を受けています。