要約

  • CDN-Loopは、顧客設定によって消せない共通のループ検知手段を守る。顧客によるサービスの組み合わせや、すべてのネットワークに共通する一度限りの通過規則を定めるものではない。
  • 外部のクライアントもこのフィールドを送信できる。途中で保存されたことと、そこに書かれた経路が認証済みであることは異なる。
  • 同じ事業者の印が複数あっても、正常な内部処理を表す場合がある。構文の拒否、ローカルなループ判定、配信元の障害は別々の証拠として扱う必要がある。

503を見て、配信元を疑う前に

配信エラーをまとめる画面では、同じ状態コードが同じ原因のように扱われがちだ。だが、配信元のサーバーに届く前に、プラットフォームがサービスの組み合わせを拒否した場合もある。その失敗を単に「配信元の障害」と記録すると、判断が行われた場所を見失う。

Fastlyの現在のComputeエラー資料は、この違いを具体的に示している。CDN-Loopの構文が不適切な場合の400と、直接のループや不正なサービス連鎖を検知した場合の503を区別する。説明にはComputeとCDNサービスの間の移行も含まれる。両者ともリクエストの失敗ではあるが、失敗から読み取れる内容は同じではない。

前者は、受け取ったフィールドが想定された形式で処理できないという情報だ。後者は、認識されたサービス連鎖をローカルな規則が拒否したという情報だ。配信元が通常の処理で返す失敗は、また別の対象になる。状態コードを一つの可用性指標にまとめても、原因の境界はまとまらない。

この区別を入口にすると、CDN-Loopの役割も見えやすい。これは配信の成功証明ではなく、繰り返し処理を検知するための共通フィールドである。顧客が経路を選ぶ自由を残したまま、ネットワーク側が自分の資源を守る機会を保つ。どの失敗かを理解するには、共通の印とローカルな判定を分けて考えなければならない。

選んだ後段が、前段に戻るとき

顧客が最初の配信サービスの後ろに、別のキャッシュや処理サービスを置く。各サービスの設定だけを見れば、通常の配信元指定にすぎない。ところが後のDNS変更やサービス構成によって、後段が再び前段のネットワークに到達することがある。ここで述べるのは仕組みを説明する仮定であり、新たに観測した本番障害ではない。

すでに処理した側へリクエストが戻ると、同じ仕事に再び資源を使う。以前の通過を示す情報が残っていれば、その戻りを見分ける材料になる。途中の顧客設定で情報が消されれば、次の事業者は警告を欠いたリクエストを受け取る。

顧客の正当な権限は、次の転送先を選ぶことにある。しかし、その選択は自社以外の設備にも影響する。転送先の選択と、他者が繰り返しを判断するための情報を消す権限を同じものとして扱うと、一つの管理領域の便利さが別の領域の負担になる。

NDSS 2016で公表された転送ループの原研究は、当時の16事業者を対象とした管理された調査でこの問題を扱った。各事業者について何らかの弱点が見つかり、他のサービスが提供するヘッダーフィルタ機能を通じた防御の回避も含まれていた。ただし、この研究は2019年の標準より古い。2026年の各社に同じ弱点が残るとの主張ではない。

残る論点は、古い調査結果を現在の危険度として再掲することではない。分散した転送選択を許す仕組みが、共通の警告を消す権限まで顧客に渡してよいか、という構造的な問題である。

消してはいけない範囲を先に決める

公式情報によるとRFC8586は2019年4月のProposed Standardである。CDN-LoopはHTTPリクエスト用のフィールドとして、過去に自分のCDNを通過した可能性を識別する手段を定める。ブラウザーのリダイレクト履歴やDNSの全判断を記録する機能ではない。

RFC8586本文は、適合するCDNが生成・転送するリクエストに自分の情報を追加することをSHOULDとする。この勧告を、世界の全CDNがすべての実リクエストで実行しているという観測事実に変えてはいけない。

一方、機構が働くための顧客設定の境界は明確だ。顧客がフィールドを変更または削除できてはならない。途中の参加者が情報を保存しなければ、後続のCDNは戻ってきたリクエストを検知できない。削除を許す事業者は、参加するネットワークにも参加しないネットワークにも攻撃経路を残し得る。

制約は狭い。顧客が配信元を選ぶ権限、他社サービスを接続する選択、すべてのリクエストヘッダーを扱う一般的な能力を一律に取り上げるものではない。守るのは、同行の判断に必要な一つの共通表面だ。

したがって、正常なサービス連鎖が拒否された際に「この顧客だけ印を消せるようにする」という解決は中立ではない。他の参加者が持てる情報も変えてしまう。議論すべきなのは、ローカルな訪問の定義、許容条件、例外を扱う責任であって、共通の警告を隠す方法ではない。

一つの名前が二度現れても、結論は出ない

FastlyのCDN-Loop資料は、ネットワークを通過するときにフィールドを付加すると説明する。独自のFastly-FFとは異なり、他のプラットフォームとの共通機構として扱われる。クラスタリングと保護用キャッシュの利用によって、掲載例ではFastlyの印が最大四つ現れる。

それを四社の経由や四つの顧客設定と読むことはできない。同じプラットフォーム内の段階が複数あるからだ。単純に「同じ名前が再出現したら必ず止める」と言うと、正常な構成までループと同一視する。

Fastlyが公開するエラーの説明は、さらに数える単位を分ける。当該サービスのために当該POPを以前に訪れた回数は最大三回、以前に実行した異なるFastlyサービスは最大六つ、以前の総ホップ数は最大二十とされる。ここでホップはFastlyサービス間の引き渡しである。

「以前の」という条件、サービス、POP、異なるサービスという修飾は数字の一部だ。これを世界共通の「CDNへのアクセスは三回まで」に縮めれば、別の規則になる。RFC8586が全事業者に三・六・二十を課しているわけではない。

資料は意図的なサービス連鎖や、第三者の後段が実は別のFastly顧客である場合にも触れる。業務上の意図が正常であることと、プラットフォームが自身の規則で拒否することは両立する。必要なのはサービス構成の理解であり、印を消して構成を見えなくすることではない。

公開された数字は現在の製品資料として有用だが、全製品が同じ情報を出すとの証明でも、永続的な保証でもない。数字だけを比較表へ転記するより、何を数えているかを一緒に持ち運ぶ方が実務に役立つ。

入口の主張には、別の限界がある

フィールドを途中で消せないことは、その中身を信じてよいことを意味しない。RFC8586は、任意のクライアントがCDN-Loopを生成できるため、その内容を信用できないと明示する。プラットフォーム内の設定権限と、外部の送信者が書いた内容の出所は別の境界だ。

仮に外部の送信者が、実際には通っていないネットワークの過去訪問を記したとする。その値だけで絶対的な歴史を認定して拒否すれば、正当な処理が止まる可能性がある。これは誤拒否の仕組みを説明する仮定であり、特定事業者の現行実装で確認した攻撃ではない。RFCは、内容に応じた挙動が新たなサービス拒否の経路にならないよう注意を求める。

だが入口の値を全部削除することも一般解ではない。前のCDNが本当に加えた情報まで失われ、元の共同防御が壊れる。保存する責任と、どこまで推論するかを制限する責任を両方果たす必要がある。

RFCは署名の可能性に触れるものの、署名方式を定義も要求もしていない。独自のハッシュが別のCDNでも検証される、鍵が共有される、パラメーターが同じ意味で読まれると想定することはできない。一区間の通信が保護されていても、それ以前の全経路を証明することにはならない。

Fastly-FFの資料は、VCLで変更から保護されることと、外部リクエストにもフィールドが含まれ得ることを同時に説明する。ComputeがCDN-Loopでハッシュを使うといった製品固有の情報も、RFCが定めた全社共通の署名方式に読み替えてはいけない。

ローカルな裏付けはローカルな調査に価値がある。その価値を認めることと、全旅程の証明へ拡張しないことは両立する。請求、権利、所在地、責任の最終認定にこのフィールドを転用すれば、証拠の能力より大きな仕事を負わせることになる。

登録とローカルな意味を混ぜない

現在のIANA HTTPフィールド登録は、CDN-Loopの名前と参照を揃える。実際の採用状況を網羅的に調べた台帳でも、各リクエストの経路認証でもない。

識別子にはCDNの管理するホスト名、必要ならポート、または規定の構文に合う仮名を用いる。ホスト名を優先するのは偶然の衝突を減らすためだ。受信した値にその名があることだけで、送信者の管理権限や過去の通過が証明されるわけではない。

追加のパラメーターはCDN自身のための情報を載せる余地になる。共有の構文があっても、すべてのカウンターに世界共通の意味が生まれるわけではない。また、項目はコンマ区切りでも複数のフィールド行でも表せる。物理的な行数を訪問回数と取り違えるべきではない。

Cloudflareの現在のヘッダー説明は、ネットワークへの再入場を許容・制限する使い方と、ほかのループ関連フィールドを示す。これはプラットフォームの機能説明であり、似た名前の情報を全部足せば認証済みの世界共通カウンターが得られるという話ではない。

Viaを使った経験が残したもの

Cloudflareの2016年1月の記事は、Viaに基づく共通のループ防御を訴えた。2019年3月の実装記事は、当時の機能や圧縮との相互作用など、その後の難しさを振り返る。同時にWorkersの子リクエストなど、複数回の正常な通過を細かく扱う必要も説明した。

2019年の記事はまだ正式RFC以前の草案を扱う。例示された表現をそのまま適合性試験の入力にしたり、現在の全アカウントに同じ許容数があると読んだりしてはいけない。また、過去に一部の実装で起きたViaの影響は、今日の全サーバーが圧縮を止めるという主張の根拠にはならない。

現在のHTTP SemanticsであるRFC9110は、Viaのプロトコル・中継者情報と、プロキシやゲートウェイの義務を独立して定める。CDN-Loopが登場してもViaの義務は消えない。Viaにある任意コメントや特定条件下の項目統合の許可を、CDN-Loopの識別子を消す権利へ移すこともできない。

新しい共通フィールドは、別用途を持つ古い表面の副作用に防御を依存させる問題を狭める。周囲のHTTP規則すべてを無効にするわけではない。共有の約束を小さく明確にすることは、他の約束を忘れることとは異なる。

主なCDNだけを調べても足りない

経路の途中にはAPIゲートウェイ、正規化処理、一般的なヘッダー変換があるかもしれない。主なCDNの設定画面でフィールドが保護されても、すべての代替経路で保存されることは証明されない。

Oracleの保護ヘッダー一覧は、API Gatewayの変換ポリシーではリクエストのcdn-loopを変更できないと記す。これはその製品の制約を示す。ループ検知方式や、顧客の構成全体が端から端まで正しいことまでは示さない。

中間処理を見落とす危険は構成上の分析であって、Oracleで新たに観測した欠陥の主張ではない。購入前に確認したいのは、どの段階が変更できるか、何を一回と数えるか、どこで拒否するか、例外を誰が扱うかという具体的な事項だ。単なる「標準対応」のラベルでは、その意味を知ることはできない。

調査の可視性にも代価がある。フィールドは別の事業者の存在や内部の段階を示し得る。仮名は文字どおりのホスト名を隠しても、匿名性や関連付け不能性を保証しない。説明のために生の経路情報を広い顧客ログへ出せば、後から回収できない情報になる場合がある。

証拠を足しても、認証にはならない

NDSS 2016の採択論文記録は、歴史的研究の出所と時期を確認する。標準は仕組みを説明し、製品資料は文書化された実装を説明し、登録簿は参照を揃える。それぞれの役割を足しても、現在の全事業者の安全性調査や、全経路の実測にはならない。

Lu Hengによる最小の初期仕様、将来のローカルな決定、自発的採用の議論は、この協調を読む視点を与える。The Policy Mirrorを含めてここで適用するのは著者の分析であり、IETFや各社がその議論を承認したとの意味ではない。

参加者は共通の小さな警告を守り、将来の数え方や処理はそれぞれの運用に残すことができる。印の保存は、他者が自分で判断するための条件を残す。その有用性を認めながら、内容が保証しない真実まで求めないことが、この仕組みの強みを正確に捉える方法になる。