CenturyLink FlowSpec 障害とバックボーン説明責任

概況

CenturyLink の障害理由記録によると、同キャリアは2020年8月30日10:04 UTC に複数市場でのインシデントを特定した。障害は、問題のある FlowSpec アナウンスが複数のネットワーク要素で BGP の正常な確立を妨げたことに起因するとしている。14:14頃のグローバル設定変更により当該アナウンスがブロックされ、15:10までに安定したサービスとアラーム解除が報告された。[1][3][6][8]
詳細な事業者説明によると、最初の操作は顧客の1つの IP アドレスをブロックするためのものだった。ユーザーインターフェースとネットワーク機器の間の障害により、意図した特定アドレスではなくワイルドカードが受信され、二次フィルターが結果として得られた広範なルールを拒否できなかった。これらの詳細は、顧客がホストする CenturyLink 障害メモの複製に基づいており、独立して検証された設定記録ではなく、出典を明示する必要がある。[1][3]
Cloudflare は10:03 UTC からオリジン到達性エラーを観測し、48の接続都市で CenturyLink を無効にしてトラフィックを他のプロバイダーに移した。また、BGP アップデート量の急増を測定し、ルーターがセッションを繰り返し確立し、問題のあるルールを受信して再び BGP を失うというループ仮説を提案した。測定値は直接的なものだが、ループは技術的仮説であり、キャリアの内部ルーターログは公開されていない。[2][11]
ThousandEyes は、制御プレーンが機能不全に陥った場合に一致する広範なパケット損失とルート動作を観測した。その例では、バックアップ接続だけでは不十分であり、古いアナウンス、経路優先度、ピアリング密度、代替容量がトラフィックが実際に障害を回避できるかどうかに影響した。[3][4][5]
FlowSpec は単なるファイアウォールインターフェースではない。BGP を介してトラフィックマッチングルールとアクションを配布する。そのため、検証、認可、配布範囲、カナリアテスト、ロールバック、制御プレーン保護、帯域外リカバリは、ポリシーを受け入れるネットワークのリーチに見合ったものにする必要がある。[13][14][15][16][17]
説明責任は分散しているが、曖昧ではない。CenturyLink はポリシープラットフォーム、インターフェース、二次検証、ネットワーク配布、ルート制御保護、ロールバック、インシデント証拠を管理していた。顧客とピアは自社のマルチホーミング、経路ポリシー、撤退、代替容量の一部を管理していたが、キャリアの内部障害を修復することはできなかった。
永続的な修復テストは証拠に基づく。プラットフォームの無効化とフィルターの修正が是正措置として発表された。強力な保証として、実験室での正確な障害の再現、独立した制御による拒否、限定されたロールアウト、保護された管理アクセス、制御プレーン障害下でのリカバリ、同じ障害クラスに対する後のテストが追加で必要となる。[1][13][17][20]

1件の顧客ブロックがバックボーン全体の制御問題に

インシデントを理解するための最も有用な方法は、意図された範囲と実効権限の違いから始めることである。

公開された CenturyLink の障害理由記録によると、運用チームは通常のサービスの一環として FlowSpec を使用し、顧客に代わって1つの IP アドレスからのトラフィックをブロックしようとしていた。これは一般的な DDoS 緩和タスクである。意図された対象は狭く、1つの送信元、1つの顧客ニーズ、1つの限定されたトラフィックアクションだった。実際の影響ははるかに大きかった。結果として得られたアナウンスは多くのエッジデバイスに伝播し、ネットワークが依存する BGP セッションに干渉した。[1]

このミスマッチが説明責任の核心である。ユーザーインターフェースは単一のアドレスを表示する一方で、ダウンストリームのポリシーコンパイラやルーターはワイルドカードを受信する可能性がある。二次フィルターは独立しているように見えても、同じ欠陥のある前提を通じて不正なオブジェクトを解釈する可能性がある。配布システムは、各コンポーネントが有効な構文を見るため、結果として得られるルールを通常のものとして扱うが、その組み合わせた意味は壊滅的である。したがって、公的な問題は単に誰が何を入力したかではない。グローバルなリーチを持つシステムが、一見ローカルなリクエストの背後にある権限をどのように表現し、検証し、制約したかである。

FlowSpec は、トラフィックポリシーをルーティング制御プレーンに結合するため、この問題を明確にする。従来のアクセスリストは通常、デバイスやインターフェースに関連付けられる。FlowSpec は BGP を介してマッチングコンポーネントとアクションを伝達できるため、ネットワークは多くのルーターに迅速に緩和策を適用できる。この速度は大量攻撃時に有用である。同時に、意味エラーを配布問題にする。応答時間を短縮する同じメカニズムが、安全でないルールがネットワークの大部分に到達する前にそれを検出する時間を短縮する可能性もある。[13][14][15]

プロトコル自体を悪者と見なすべきではない。RFC 5575はインシデント当時のメカニズムを定義し、RFC 8955が IPv4 向けに後継となり、RFC 8956は IPv6 をカバーする。これらの文書はエンコーディング、順序付け、検証、トラフィックアクションを説明する。CenturyLink のプライベートソフトウェアパスを明らかにするものではなく、すべての実装が同じように動作することを証明するものでもない。健全な記事は、プロトコルの能力と事業者のガバナンスを区別しなければならない。このインシデントは、1つのキャリアが高い権限を持つポリシーパスをどのように実装し運用したかに関するものであり、すべての FlowSpec 導入が安全でないという結論ではない。[13][14][15]

同じ区別により、安易で弱い見出し「1つのタイプミスがインターネットをダウンさせた」を避けることができる。公開記録は正確なコマンドバイトを開示しておらず、詳細な事業者説明は、名前の付いた人物が入力した単純な可視ワイルドカードではなく、インターフェースとネットワーク機器の間の障害を説明している。インシデントはすべてのネットワークを到達不能にしたわけではない。観測者によって影響は異なり、一部のネットワークは問題を回避した。防御可能な結論はより狭く、より重要である。顧客スコープの緩和リクエストが、高度に接続されたグローバルバックボーン全体で BGP 確立を損なうほどの権限を獲得したことである。

これは、ネットワークインフラを通じて表現されたガバナンスの失敗である。関連する制御には、スキーマ検証、認可、スコープ表示、ポリシーコンパイル、二次チェック、配布境界、ルートリフレクター保護、制御プレーン例外、カナリアテスト、ロールバック、帯域外アクセスが含まれる。これらは、ルーターの数を数えたり、冗長性が存在すると述べるだけでは評価できない。

タイムラインは検出、診断、復旧を分離する

事業者のタイムラインでは、インシデント特定は10:04 UTC である。Cloudflare の監視は10:03にオリジン到達性エラーの上昇を記録し始めた。この1分の差は矛盾ではない。一方のタイムスタンプは外部測定のトリガーであり、もう一方は事業者のインシデント記録である。両方とも開始を同じ狭いウィンドウ内に位置づけている。[1][2]

Cloudflare は CenturyLink を経由するトラフィックが急減するのを確認した。その自動システムは、Cogent、NTT、GTT、Telia、Tata などの他のプロバイダーにトラフィックを移し始めた。10:03から10:11 UTC の間に、ネットワークが接続されている48都市で CenturyLink を無効にした。シフトはどこでも瞬時に行われたわけではない。代替容量を考慮する必要があった。あまりに多くのトラフィックをあまりに早く移すと、バックアッププロバイダーを過負荷にし、1つのキャリアの障害を連鎖的な問題に変える可能性がある。[2]

公開された RFO によると、アラームが蓄積される中、CenturyLink IP ネットワーク運用センターは追加の技術およびサービス保証リソースを動員した。初期の対応では原因を特定できなかった。14:00 UTC 頃、運用エンジニアリングは、問題を引き起こし BGP の正常な確立を妨げている FlowSpec アナウンスを特定した。14:14に NOC はそのアナウンスをブロックするグローバル設定変更を展開した。その変更が伝播するにつれて、BGP セッションが回復し、アラームが解除された。事業者は15:10までに安定を報告した。[1]

SANS Internet Storm Center は、ルーティング問題が BGP セッションの確立を妨げ、高レベルの設定調整によりセッションが回復したとする CenturyLink の当時の発言を捉えている。また、一部の顧客はキャリア側の修復後、ローカル機器や BGP セッションをリセットする必要があるかもしれないと警告していた。Outages メーリングリストアーカイブには、BGP 隣接関係やルートアナウンスは確認できるが、使用可能なトラフィックは依然として損なわれていると報告した事業者の記録が保存されている。これらの観測は、制御プレーンのステータスが部分的に生きているように見えても、エンドツーエンドの到達性が確保されていない場合があるため重要である。[6][8]

ThousandEyes は、インシデントの期間を約5時間と概説した。後のトポロジーおよびサービス分析を用いた研究では、測定と回復のしきい値に応じて、イベントを10:04から15:30 UTC 頃としている。正しいアプローチは、すべてのソースを1つの正確な期間に強制することではない。外部ユーザー、ピア、制御プレーンコレクター、キャリア自身のアラームは異なるレイヤーを測定した。ネットワークは、すべての顧客経路が再収束する前に内部的に安定することがあり、一部のエンドポイントはキャリアがインシデント終了を宣言する前に回復することがある。[3][9][10]

このタイムラインは3つの保証ギャップを明らかにする。

1つ目は、検出から診断までの時間である。ネットワークは追加リソースを要求するほどのアラームを生成したが、最初の外部エラーから約4時間が経過するまで原因は特定されなかった。関連する疑問は、事業者がすべてのアクティブな FlowSpec ルール、その発信元、有効なマッチ、配布範囲、依存する制御トラフィックの安全で検索可能な表現を持っていたかどうかである。

2つ目は、制御プレーン障害下での診断である。ルールが BGP セッションや管理到達性を妨害した場合、通常のツールは、対応者が必要とするまさにその時に信頼できなくなる可能性がある。ポリシーをグローバルに配布できるアーキテクチャには、損なわれた経路に依存しない除去経路が必要である。

3つ目は、復旧の証拠である。問題のあるアナウンスをブロックすることで BGP は確立できるようになったが、サービス回復はルートの再収束、ピアの動作、顧客機器にも依存していた。キャリアは、「悪いルールがブロックされた」「BGP セッションが安定した」「ルートが収束した」「トラフィックが流れている」「カスタマーサービスが正常である」を区別すべきである。それぞれの状態には異なる測定が必要である。

FlowSpec が爆発半径をどう変えたか

BGP は、自律システムが到達可能性情報を交換するために使用するプロトコルである。BGP スピーカーはルートを学習し、ポリシーを適用し、選択した経路をピアにアドバタイズする。FlowSpec はその配布モデルをトラフィックフィルターに拡張する。FlowSpec ルートは、送信元または宛先プレフィックス、プロトコル、ポート、パケット長、TCP フラグなどのフィールドを使用してトラフィックを記述し、マッチングパケットのドロップやレート制限などのアクションを関連付けることができる。[13][14][15][16]

運用上の利点は明らかである。DDoS イベント時に、プロバイダーは従来のフィルターを各エッジルーターで編集することなく、迅速に緩和策を配布できる。運用上のリスクも同様に構造的である。幅が広すぎるルールは、担当者が各ルーターにログインする前に多くのデバイスで適用される可能性がある。BGP やネットワーク管理に必要なトラフィックにマッチする場合、そのポリシーは配布または除去の手段自体を損なう可能性がある。

Cloudflare の公開分析は、BGP アップデートの持続的なボリュームについて1つのもっともらしい説明を提供した。ルーターは BGP を確立し、ポリシーのリストを受信し、問題のある FlowSpec ルールに到達し、その後 BGP 接続を失う可能性がある。セッションがなくなると、動的ルールはもはや持続せず、ルーターは再接続してサイクルを繰り返す可能性がある。各サイクルはより多くのアナウンスを生成し、負荷を増加させる可能性がある。Cloudflare は、より完全な CenturyLink の証拠を待つ間、これを可能性のあるシナリオとして明確に位置づけた。これは仮説のままであるべきであり、事業者が確認したパケットトレースではない。[2]

ThousandEyes は、拡張された事業者情報を受け取った後の分析で、同様のループ状態を説明した。地理的に分散した CenturyLink インフラ全体での完全なパケット損失と、BGP の繰り返し障害と一致するアナウンスの増加を報告した。ThousandEyes は直接測定と事業者資料および解釈を組み合わせているため、記事は証拠のレイヤーを可視化し続けるべきである。パケット損失とルート動作は観測されたが、正確な内部シーケンスは CenturyLink が完全に公開していない記録に依存する。[3]

RFC 4271は、セッション安定性が重要である理由を説明している。BGP は、ルーティング状態を維持するために、持続的なピア関係と UPDATE 処理に依存する。RFC 7606は後に不正な UPDATE メッセージのエラー処理を改善し、RFC 4724は一部の制御プレーン再起動中に転送を維持することを目的としたグレースフルリスタートメカニズムを定義している。これらの文書は有用な文脈を提供するが、どちらもセッション自体をブロックするトラフィックポリシーに対する一般的な保護策ではない。ネットワークは、どのトラフィックを免除するか、どのポリシーが制御インフラに到達できるか、失敗したルールをどのように除去するかを決定しなければならない。[16][18][19]

したがって、インシデントは「爆発半径」を比喩から工学的特性に変える。ポリシーの爆発半径とは、検出とロールバックの前に影響を受ける可能性のあるデバイス、トラフィッククラス、ピア、管理経路のセットである。事業者は、デバイスグループ、プレフィックス認可、プロトコル除外、顧客固有の境界、段階的ロールアウト、時間制限、レート制御を通じてこの半径を縮小できる。また、同じ顧客ポリシーによってフィルタリングできない独立した管理プレーンを維持することもできる。

グローバルバックボーンは、この特性を明示的にすべきである。変更リクエストには、意図されたアドレスだけでなく、コンパイル後の正規化されたマッチ、それを受け入れるデバイスの数とクラス、接触する可能性のあるプロトコル、範囲内の顧客とピア、自動有効期限、ロールバック経路を示すべきである。実効範囲が大きいほど、必要な承認とテスト証拠は強固になる。

2つのチェックが失敗しても、1つの前提が失敗した可能性

公開された RFO によると、ユーザーインターフェースはワイルドカードエントリ、空白エントリ、アドレス以外の入力を拒否するように設計されていた。また、二次フィルターはこの方法で複数のアドレスがブロックされるのを防ぐことを意図していた。それでもワイルドカードコマンドは両方を通過した。二次フィルターは宛先プレフィックスを探しており、ワイルドカード表現により、コマンドを複数のアドレスではなく単一のアドレスとして解釈させた。[1]

これは、名目上の独立性と意味的独立性のない例である。2つの制御が異なるコンポーネントに実装されていても、オブジェクトがどのように表現されるかについて同じ前提に依存することがある。最初のチェックは変換前のユーザー入力を検証するかもしれない。2番目のチェックは変換された形式を検証するが、同じブラインドスポットを共有するパーサーを使用する可能性がある。両方ともワイルドカードを単一の有効なオブジェクトとして扱う場合、2つのチェックを数えることは保護を過大評価する。

より強力な設計は、独立した表現を比較することである。

1つの制御は、要求された生のアドレスを顧客の認可されたプレフィックスに対して検証できる。別の制御はルールをコンパイルし、マッチするパケットのセットを計算できる。3つ目は、結果に BGP TCP ポート179、ルートリフレクターアドレス、管理プレフィックス、顧客の割り当て外のインフラが含まれる場合に拒否できる。4つ目は、実効マッチを元の人間が読めるリクエストと比較し、範囲が拡大する場合に承認を要求できる。5つ目は、ルールをカナリアデバイスにインストールし、より広範な配布前に制御プレーンの健全性を観測できる。

したがって、「二次フィルター」という用語は疑問を招くべきである。場所が二次的なのか、ロジックが独立しているのか？効果的な防御は、単にもう1つの条件文ではない。異なる方法で失敗し、異なる真実のソースを使用するか、異なるプロパティを検証するべきである。プレフィックス認可、セットカーディナリティ、プロトコル除外、シミュレートされた実効範囲は別々のプロパティである。それらを組み合わせることで、共有パーサーエラーがすべての保護を破る可能性が低くなる。

フェイルクローズ動作も重要である。ルールを明確に正規化できない場合、安全な応答は拒否であり、広範な解釈ではない。意図された範囲と実効範囲が異なる場合、配布は停止すべきである。ポリシーが制御プレーントラフィックに触れる場合、高い権限を持つ例外プロセスが必要とされるべきである。検証サービスが利用できない場合、システムは緊急時にバイパスを許可すると想定すべきではない。

緊急時は DDoS 緩和において予測可能な条件である。そのため、それは設計の一部であり、設計を停止する理由ではない。事業者は、事前検証および制限されているために高速な経路を必要としており、独立したレビューをスキップするために高速な経路ではない。顧客リクエストは、事前承認されたプレフィックスとアクションテンプレートにマッピングできる。ルールは自動的に期限切れになる。緊急オーバーライドは記録され、より広範なリリース前に少数のカナリアセットに制限される。

公開記録によると、CenturyLink はテスト中に FlowSpec プラットフォーム全体を無効にし、ワイルドカードを禁止するようにフィルターを修正した。これらの措置は報告されたトリガーに対処する。しかし、2つの制御が意味的に独立したかどうか、コンパイル後に範囲が計算されるかどうか、制御プレーントラフィックが保護されているかどうかをそれ自体で示すものではない。これらは、是正措置と実証された非再発を区別する証拠の疑問である。[1][20]

高度に接続されたキャリアはシステム的依存を生み出す

CenturyLink は Level 3を買収し、AS3356 はインターネットのルーティングシステムで最も接続されたトランジットネットワークの1つであり続けた。正確な商業的・技術的関係は異なるが、実際的な結果として、多くのネットワークは、どちらのエンドポイントも自らを CenturyLink のリテール顧客と考えていなくても、AS3356 を含む経路を通じて宛先に到達した。RIPEstat や公開ルーティングアーカイブは、このネットワークの役割の文脈を提供する。[11][12]

これは、バックボーンの説明責任が直接の請求書によって制限されないため重要である。他のプロバイダーの顧客でも、数ホップ先のトランジット関係に依存することがある。クラウドサービスは自らの送信経路を変更できても、障害キャリアの背後にシングルホームされたオリジンに到達できないことがある。ピアは CenturyLink を非優先にしても、リモートネットワークはそれを通る古いまたはより魅力的な経路を選択し続けることがある。キャリアの実質的な義務は、そのネットワークが作り出す依存関係に従うのであって、サポートチケットを開くことができるユーザーのセットだけではない。

Cloudflare の緩和策は、多様性の力と限界の両方を示している。複数の大規模ネットワークに接続しており、48都市で CenturyLink を迅速に無効にできた。その措置によりエラーピークは大幅に減少した。しかし、一部の Cloudflare 顧客は、オリジンサーバーが CenturyLink を回避できる使用可能な経路を持っていなかったか、キャリアが破損した経路にトラフィックを引き込むルートをアドバタイズし続けたため、到達不能のままであった。[2]

ThousandEyes は、結果が異なる顧客を比較した。OpenTable はインシデントの大部分を通じて高いパケット損失を被った。GoToMeeting は GTT をバックアッププロバイダーとして有効にし、Level 3がプレフィックスをアドバタイズし続けている間でも到達性が改善された。ルートは必ずしもより具体的ではなかった。優先度はリモートネットワークの見解と代替ピアリングの密度に依存していた。この例は、2つのプロバイダーが継続性を保証するという普遍的なルールではない。物理リンク、BGP ポリシー、アドバタイズ状態、容量がすべて一致しなければならないことを示している。[3]

したがって、「マルチホーム」というフレーズはいくつかの一般的なモードを隠す可能性がある。

2つの回線が同じ建物に同じ導管で入ることがある。2つのプロバイダーが同じバックボーンからアップストリームトランジットを購入することがある。2つのアドバタイズされた経路が見えていても、1つの古い経路が優先されることがある。バックアッププロバイダーが突然のグローバルシフトに対応する容量を欠くことがある。両方のリンクが同じ DNS、ルートサーバー、管理ポータル、顧客エッジルーターに依存することがある。組織には、インシデント中にポリシーを変更できる権限のある担当者がいないこともある。

適切な保証証拠はエンドツーエンドである。顧客は、通常時および障害時の自律システムパス、関連する物理ルート、ローカルプリファレンスと MED の動作、各プロバイダーがアドバタイズするプレフィックス、利用可能な撤退またはコミュニティ制御、テスト済み容量、フェイルオーバーのトリガーを知るべきである。監視は両方のプロバイダーの外部から行い、見えてもパケットを運ばないルートを検出できるようにするべきである。

顧客とピアにはこれらの制御に対する責任があるが、その責任はキャリアの責任を消し去るものではない。顧客はより良い多様性を設計できるが、CenturyLink の内部 FlowSpec プラットフォームが多くの要素で BGP を損なうのを防ぐことはできない。共有依存は階層化された説明責任を生み出し、均等な説明責任ではない。

制御プレーン保護は配布するポリシーを生き残らなければならない

ネットワーク全体の自動化システムには、観測と復元のための保護された経路が必要である。このインシデントでは、ポリシー配布メカニズムと BGP セッション動作が絡み合った。これは、事業者に、ポリシーが間違っている場合にネットワークが管理可能であり続けられるかどうかを問うべきである。

最初の保護は範囲である。顧客がトリガーする FlowSpec ルールは、顧客のプレフィックス、予想されるトラフィッククラス、承認されたアクションに対してのみ認可されるべきである。インフラアドレスや制御プロトコルにマッチしてはならず、別の明示的なワークフローが許可する場合を除く。検証は要求された入力だけでなく、コンパイルされたルールを使用すべきである。

2番目の保護はステージングである。ルールは最初にラボ環境に送信され、次にカナリアエッジ、次に限定されたリージョン、次に広いデバイスグループに送信される。システムは各ステップで、BGP セッション数、ルートリフレクター負荷、管理到達性、パケット損失、顧客の結果を監視するべきである。秒単位で設計された緩和策は各段階で何時間も待つことはできないが、自動化されたしきい値と即時ロールバックを使用できる。

3番目の保護は帯域外制御経路である。事業者は、通常の顧客トラフィックと同じトランジット、ルーティングセッション、フィルタリングドメインに依存しない管理アクセスを必要とする。設定アーカイブとロールバックツールは到達可能でなければならない。グローバルな緊急ブロックは、安全でないルールによって自身のパケットが捕捉されないチャネルを通じて可能であるべきである。

4番目の保護は有効期間の制限である。緩和策は、証拠レビューがない限り期限切れになる。自動期限切れは、放棄されたり誤解されたルールの持続性を制限する。ロールバックを置き換えるものではない。5分間の壊滅的なルールは依然として受け入れられないが、長期間の露出を減らし、所有権を明示的に維持することを強制する。

5番目の保護は状態の可視性である。対応者は、すべてのアクティブな FlowSpec ルール、その発信元、リクエスター、認可、正規化されたマッチ、アクション、配布セット、インストール状態、経過時間、ロールバックステータスをリストできるべきである。また、どのデバイスがそれを拒否したか、その理由も見えるべきである。このインベントリなしでは、診断は異常な数のアラームとアップデートを生成しているネットワーク全体の探索になる。

6番目の保護は保護されたインフラポリシーである。ルートリフレクター、BGP スピーカー、DNS、時刻同期、認証、ログ、管理システムは通常の顧客宛先ではない。ネットワークは、顧客ルールがそれらに影響を与えることができるかどうか、またできる場合、どのような例外的な制御を通じてかを定義すべきである。保護は、パケット転送とポリシーの計算および配布に使用されるシステムの両方をカバーしなければならない。

RFC 7454は BGP の運用セキュリティガイダンスを提供し、RFC 7606と RFC 4724はエラー処理と再起動の側面を扱う。ソースセット内の NANOG 事業者プレゼンテーションは、FlowSpec の障害モードと実装の教訓について議論している。これらのソースは制御と疑問を定義するのに役立つ。CenturyLink の現在のアーキテクチャを認定することはできない。認定には、現在の事業者固有の証拠が必要である。[17][18][19][20]

変更管理は実効的なネットワーク権限を測定すべき

従来の変更フォームは、デバイス数、メンテナンスウィンドウ、サービス所有者によって作業を分類することが多い。FlowSpec は別の次元、すなわち実効権限を示唆する。数百のエッジルーター上の任意のパケットにマッチできるリクエストは、1つのテストシステムに限定されたより大きなテキスト変更よりも高い権限を持つ。

権限ベースの変更記録には、少なくとも5つのビューが含まれるべきである。

意図ビューは、顧客リクエストとビジネス目的を平易な言葉で述べる。このケースでは、表明された意図は1つの顧客の1つのアドレスからのトラフィックをブロックすることだった。[1]

コンパイルビューは、デバイスが受信する正確な正規化された FlowSpec コンポーネントとアクションを示す。ここでワイルドカード展開、欠落フィールド、パーサーの違いが可視化される。

リーチビューは、影響を受ける可能性のあるデバイス、リージョン、ピア、プレフィックス、トラフィッククラスを特定する。ルールが意図したとおりに機能することを前提とするのではなく、最悪のシナリオの範囲を計算すべきである。

安全性ビューは、保護された制御トラフィック、認可境界、カナリアステップ、ロールバック条件、有効期限、独立したバリデーターをリストする。

証拠ビューは、実効範囲を承認した者、実行されたテスト、最初にポリシーを受け入れたデバイス、変更されたテレメトリ、ルールが削除された時刻を記録する。

このアプローチは、レビューを「構文は有効か？」から「すべてのコンポーネントがエンコードされたとおりに動作した場合、ネットワークはどのような権限を行使するか？」に変える。また、自動化を監査可能にする。機械は、実効範囲が事前承認されたエンベロープ内に収まっている場合、ルーチンルールを承認できる。コンパイルされた範囲がそれを超える場合、人間の承認が必要とされる。どちらの経路も曖昧さを受け入れるべきではない。

ピアレビューは差分に焦点を当てるべきである。レビュー担当者は、提案された実効ルールが既知の安全なテンプレートとどのように異なるかを確認する必要があり、時間的プレッシャーの下で設定全体を解析する必要はない。システムは、拡張されたプレフィックスセット、追加されたプロトコル、広がった配布グループ、欠落した有効期限を強調表示できる。レビュー担当者は、インシデントの緊急性や顧客の重要性によって弱められない停止権限を持つべきである。

ロールバックは、通常の制御プレーンの喪失に対してテストされなければならない。前のルールを保存するだけでは不十分であり、ネットワークが削除コマンドを受信できない可能性がある。安全な設計は、キルスイッチを事前配置するか、別の管理チャネルを維持するか、初期ルールを対応者が物理的または論理的に隔離できるドメインに制限することができる。

インシデントは、メンテナンスウィンドウが不完全な保護である理由も示している。障害は北米の日曜日の朝に始まり、リスクが低いように見える時間帯だった。ティア1バックボーンには異なるタイムゾーンに顧客がおり、静かな時間がないサービスを運んでいる。さらに重要なことに、制御プレーンの障害は、対応に必要なチームやポータル自体を損なう可能性がある。爆発半径と可逆性は、時刻よりも重要である。

観測可能性は BGP 状態とサービス到達性を結びつける必要がある

ルーティングインシデント中、事業者は技術的には正確だが運用上は不完全なシグナルに溺れる可能性がある。BGP セッションは確立されているがパケットがドロップされることがある。プレフィックスはアドバタイズされたままで経路が使用不能になることがある。ルーターは管理を通じて到達可能だが顧客トラフィックは失敗することがある。グローバルルートコレクターは、すべての転送結果を明らかにすることなくアップデートを示すことができる。

Cloudflare はオリジンエラー、プロバイダー別トラフィック、BGP アップデータを組み合わせた。ThousandEyes は経路可視化、パケット損失、アナウンス動作を組み合わせた。NetForecast はベンチマークネットワークを使用してユーザー体験を測定した。Outages リストは、自社のエッジで症状を見ている事業者からの報告を追加した。各ソースは異なるプレーンを観測した。これらを組み合わせることで、単一のダッシュボードよりも強力なインシデント像を生成する。[2][3][7][8][11]

バックボーン事業者は、少なくとも4つの証拠レイヤーを統合すべきである。

設定レイヤーは、意図されたポリシーと実効ポリシー、配布状態、デバイス受け入れを記録する。

制御プレーンレイヤーは、BGP セッション、ルートリフレクターの健全性、UPDATE 量、ルートチャーン、収束を記録する。

転送レイヤーは、パケット損失、遅延、ネクストホップ、トラフィックが意図されたピアまたは顧客エッジに到達するかどうかを記録する。

サービスレイヤーは、顧客が実際のトランザクションを完了できるか、サポートに到達できるか、重要なアプリケーションを使用できるかを記録する。

アラーム相関は、これらのレイヤーを時間と依存関係で結びつけるべきである。新しい FlowSpec ポリシーの後に同じデバイスセットで BGP セッション損失とパケット損失スパイクが続く場合、システムはその因果候補を即座に表面化すべきである。同じバックボーンを通じて顧客ポータルに到達できなくなった場合、インシデントコマンドは通常のツールを待つのではなく、独立したサポートチャネルに切り替えるべきである。

外部測定は、古いまたは使用不能な経路をアドバタイズし続ける可能性のあるネットワークにとって特に重要である。内部テレメトリは回線がアップしているかルートが存在すると言うことができる。外部プローブは、リモートネットワークがその経路を選択するかどうか、パケットが戻ってくるかどうかを明らかにする。キャリアは自身の外部視点を運用するとともに、第三者の証拠も保存できる。

目標は、可能なすべてのメトリックを収集することではない。制限された質問に迅速に答えることである。何が変わったのか？どのデバイスがそれを受信したのか？どのセッションが失敗したのか？どのプレフィックスがアドバタイズされたままか？どこでパケットがドロップされているか？どの代替経路に容量があるか？対応者はまだ制御面に到達できるか？修正が影響を受けたすべてのドメインに到達したことを示す証拠は何か？

サポートとコミュニケーションは復旧能力の一部

公開された RFO によると、多くの影響を受けた顧客は、電話の量が極端で CenturyLink の顧客ポータルも影響を受けたため、トラブルチケットを開くことができなかった。この詳細は運用上重要である。プロバイダーはコアを修復しているエンジニアを抱えている一方で、顧客は症状を報告したり、指示を受けたり、キャリアの障害と自社のローカル障害を区別するための使用可能な経路を欠いている可能性がある。[1]

したがって、サポート容量はネットワーク回復力の制御である。ポータルは、サポートするサービスと同じルーティング依存関係をすべて共有すべきではない。ステータスページと通知チャネルは、独立したインフラを通じて到達可能であるべきである。大規模な顧客とピアには、事前に確立された連絡先と、過負荷の一般キューに依存しない機械可読な更新が必要である。

コミュニケーションはまた、技術的回復を形作る。顧客は BGP セッションをリセットしたり、ルートを撤回したり、ローカルプリファレンスを変更したり、代替容量を有効にする必要があるかもしれない。これらのアクションにはリスクが伴う。アドバイスは、誰が行動すべきか、どの証拠が行動をトリガーすべきか、どのような副作用が予想されるか、それを元に戻す方法を特定すべきである。「機器を再起動してください」などの幅広い指示は、範囲を特定せずに発行された場合、有用な状態を破壊したり、より多くのチャーンを引き起こす可能性がある。

CenturyLink のイベント中の公開声明は、IP 障害、後にルーティング問題を特定した。外部アナリストは測定が蓄積されるにつれてより詳細な情報を提供した。インシデント後の記録は、より深い原因と是正措置を提供した。この進展は正常であるが、各更新は信頼度と出典をラベル付けすべきである。インシデントコミュニケーションは、FlowSpec アナウンスが主要原因であると述べることはできるが、完全な障害チェーンが判明していると主張してはならない。

顧客はまた、キャリアの安定性と完全な経路正常化を区別するクロージャステートメントを必要とする。事業者は、悪いルールがブロックされセッションが安定したことを報告できる。また、ルート収束が続いているかどうか、一部のピアがローカルアクションを必要とするかどうか、ポータルが復旧したかどうか、正式な障害理由分析がいつ利用可能になるかも報告すべきである。

修復の主張には再現可能なテストが必要

公開された RFO によると、CenturyLink は FlowSpec プラットフォーム全体を無効にし、広範なテストを実施中であり、その間は他の緩和ツールを使用すると述べている。二次フィルターはワイルドカードエントリを禁止するように変更されており、修正されたプラットフォームはテスト後、サービス影響のないスケジュールされたメンテナンス中に戻るとしている。[1]

これらのステップは合理的である。経路を無効にすることで即時の露出を封じ込める。問題をラボで再現することで、チームが障害をトリガーして観測できることを確認する。フィルターを修正することで報告されたバイパスに対処する。残る説明責任の疑問は、修復されたシステムが統合制御としてテストされたかどうかであり、単に1つのパーサーが1つのワイルドカードを拒否したかどうかではない。

強力な検証シナリオは、顧客スコープのリクエストから始め、明示的なワイルドカード、空白フィールド、広範なプレフィックス、代替エンコーディング、パーサー境界値、制御トラフィックにマッチするルールなど、複数の不正な表現を意図的に実行するべきである。インターフェースは安全でない入力を拒否すべきである。コンパイル済みポリシーバリデーターは独立して実効範囲を計算すべきである。プレフィックス認可は顧客の割り当て外のリソースを拒否すべきである。保護されたプロトコルチェックは BGP と管理マッチをブロックすべきである。カナリアはすべてのゲートを通過したルールのみを受信すべきである。

テストはその後、障害を導入すべきである。バリデーターが利用できなくなる。カナリアが BGP セッションを失う。ルートリフレクターが異常なチャーンを示す。ロールバックに使用される管理経路は到達可能であり続ける。自動化は伝播を停止し、損なわれた顧客プレーンに依存せずにルールを削除する。事業者は、1つの証拠記録からリクエスト、コンパイルされたオブジェクト、インストールされたデバイス、ロールバック状態を特定できるべきである。

最終段階ではスケールをテストすべきである。ルールは、独立したプローブが制御プレーンと転送の結果を監視している間、管理されたが代表的なデバイスセットに配布される。チームは、ロールバックがすべてのデバイスに到達し、古いポリシーが隠れたままにならないことを証明すべきである。テストはタイミング、しきい値、失敗、再テスト結果を記録すべきである。

独立した検証は、悪用可能な設定を公開することを必要としない。評価者は、テストが報告されたワイルドカードパス、独立したスコープ計算、保護されたトラフィック、カナリアリング、BGP 障害下でのロールバック、帯域外アクセスをカバーしたことを確認できる。公開声明は、アドレスとトポロジーを機密に保ちながら、シナリオ、合格基準、日付、残留リスクを開示できる。

完了と有効性の区別は不可欠である。「フィルター修正」は完了ステートメントである。「修正された制御は、障害のすべての表現を拒否し、立会いテストの下で爆発半径を制限した」は有効性の主張である。高い権限を持つプラットフォームがルーチン使用に戻る前に、説明責任は後者を必要とする。

説明責任マトリックス

段階	主要な制御所有者	必要な制御	存在すべき証拠	公開の境界
顧客リクエスト	CenturyLink プロダクト運用	緩和策を認可された顧客リソースと意図されたトラフィックにバインドする	リクエスト記録、プレフィックス認可、正規化された意図	特定の顧客と要求されたアドレスは公開されない
入力	CenturyLink ツール所有者	ワイルドカード、空白、曖昧、範囲外の値を拒否する	スキーマテスト、ネガティブケース、パーサーバージョン記録	正確なインターフェースとパーサーは公開されない
コンパイル	CenturyLink ポリシープラットフォーム	実効パケットマッチを計算し、意図と比較する	コンパイルされたルール、意味的差分、カーディナリティとプロトコルチェック	正確な不正コマンドは公開されない
独立検証	CenturyLink アーキテクチャ/セキュリティ	独立した論理パスを通じて広範な範囲を検出する	別のバリデーター設計、障害注入結果	公開証拠は意味的独立性を証明しない
認可	CenturyLink 変更所有者	高い権限または制御プレーンに影響するルールをエスカレーションする	承認記録、範囲表示、停止権限	個々の意思決定の所有権は公開されない
ステージング	CenturyLink ネットワーク運用	グローバルロールアウト前にカナリアと制限付き配布	デバイスグループ計画、健全性しきい値、自動停止	2020年の配布トポロジーは公開されない
制御プレーン保護	CenturyLink ルーティングアーキテクチャ	BGP、ルートリフレクター、管理を免除または別途管理する	保護されたプレフィックス/プロトコルポリシー、分離テスト	プライベートアドレッシングとトポロジーは機密保持されるべき
検出	CenturyLink NOC	ポリシー展開、BGP チャーン、パケット損失、サービス影響を相関させる	タイムライン、アクティブルールインベントリ、アラーム相関	完全なアラームストリームは公開されない
ロールバック	CenturyLink NOC およびエンジニアリング	独立した経路を通じて安全でないポリシーを削除する	キルスイッチ、帯域外アクセステスト、デバイス確認	詳細な回復アクセスはセキュリティセンシティブ
ピアリング	CenturyLink およびピア	デピアリング、撤退、収束の証拠を調整する	ピアタイムライン、ルート状態、トラフィック回復	完全な双方向記録は非公開
顧客継続性	顧客および管理プロバイダー	ポリシーおよび容量に依存しない代替経路を維持する	AS パステスト、物理的多様性、フェイルオーバー演習	顧客設計と損失は異なる
コミュニケーション	CenturyLink サービス保証	ステータス、チケット、重要な連絡先を到達可能に保つ	独立したステータス経路、更新ログ、連絡先テスト	公開パケットには部分的なサポート証拠のみ
検証	CenturyLink および独立評価者	障害を再現し、制限された非再発を証明する	テスト計画、立会い結果、残留リスクステートメント	長期的な独立テスト証拠はここでは公開されていない

マトリックスは、責任が「インターネット障害」というフレーズに陥るのを防ぐ。CenturyLink はポリシーシステムと内部バックボーンを管理していた。ピアは相互接続を管理していた。顧客は自社のエッジポリシーと多様性を管理していた。測定組織は証拠収集を管理していた。これらの責任は相互作用したが、狭いリクエストを広範な障害に変えた内部経路を再設計できたのはキャリアだけだった。

また、別の間違いを防ぐ。大規模プロバイダーがすべての顧客結果に対して責任を負うと仮定することである。シングルホームの顧客は、テスト済みのマルチホーミングを持つ顧客とは異なる継続性の姿勢を受け入れる。古いプリファレンスを保持するピアは経路を延長するかもしれない。代替オリジン接続を欠くクラウドサービスは、他の経路が回復した後も到達不能のままであるかもしれない。説明責任は各レイヤーに対する実際の制御に従うべきであり、無限に拡大すべきではない。

公開記録が証明できないこと

ソースセットは、インシデント、そのネットワークメカニズムを高いレベルで、広範な影響、主要な制御の疑問を確立するのに十分強い。完全なフォレンジック記録ではない。

元の CenturyLink RFO は、安定した事業者公開ではなく、顧客がホストするベンダーノートの複製としてここに存在する。複数の同時代および後のソースがその主要な発見を繰り返しており、信頼性は高まるが、出典の明示は依然として必要である。将来の事業者公開または規制当局提出記録が、このパケットの文言に取って代わる可能性がある。

Cloudflare の BGP ループ説明は技術的にもっともらしく、観測されたアップデートと一致するが、開示された CenturyLink のパケットキャプチャではない。記事は、すべてのルーターが正確にそのループを繰り返したと述べてはならない。ThousandEyes は追加の観測と解釈を提供するが、キャリアの完全なプライベートテレメトリを欠いている。

RouteViews はコレクターに見えるアップデートを記録するが、すべての内部ルートリフレクター状態や転送決定を記録するわけではない。RIPEstat は AS とルーティングの文脈を提供するが、根本原因の判定ではない。APNIC と CNSM の研究はインシデント後に測定方法を適用するが、プライベートな意思決定の所有権を割り当てるものではない。RFC はプロトコル動作とグッドプラクティスを定義するが、名前の付いた事業者によるコンプライアンスを認定するものではない。

このパケット内のどのソースも、個人の過失、意図、規律結果を証明しない。どのソースも、すべての顧客の正確な金銭的損失を証明しない。どのソースも、敵対的な行為者が CenturyLink を侵害したことを証明しない。どのソースも、その後の数年間にわたるすべての是正措置を独立して検証しない。

これらのギャップは、欠落した証拠を誰が保持しているかを特定するため、可視化されたままにすべきである。CenturyLink は設定系統、検証設計、ラボ再現、ロールアウトポリシー、テスト結果を提供できる。ピアは双方向ルートとデピアリング記録を提供できる。顧客は障害とフェイルオーバーの証拠を提供できる。独立評価者は、機密性の高いトポロジーを開示せずに是正措置を検証できる。

再利用可能なバックボーンポリシー説明責任テスト

CenturyLink インシデントは、トラフィックポリシーを大規模に配布できるすべての事業者にとって実用的なテストを提供する。

意図：人間のリクエストは認可されたリソースに制限され、曖昧さなく表現されているか？

コンパイル：システムは、すべてのパーサー、ワイルドカード、デフォルト後の正確な実効マッチを示すことができるか？

権限：承認は、ルールが影響を与える可能性のあるデバイス数、トラフィッククラス、制御システムに応じて増加するか？

独立性：二次制御は異なるプロパティを検証するか、異なる真実のソースを使用するか？

保護された経路：顧客ポリシーは BGP、ルートリフレクター、管理、認証、DNS、ログ、時刻システムに触れることができるか？

ステージング：ルールはカナリアテストでき、制御プレーンやサービスの健全性が変化した場合に自動的に停止できるか？

ロールバック：対応者は、損なわれたプレーンに依存せずにルールを削除できるか？

可視性：インシデントコマンドは、すべてのインストールされたルール、デバイス状態、セッション効果、顧客結果を見ることができるか？

依存関係：ピアと顧客は、代替経路がポリシー独立かつ適切なサイズであるかテストしたか？

証明：実際に報告された障害は再現され、修復された制御は現実的な条件下で立会いテストされたか？

これらの質問に答えられない事業者は、グローバルなポリシー配布機能をルーチン自動化として扱うべきではない。最近のインシデントがないことは、意味的境界が安全であるという証拠ではない。

結論

CenturyLink の2020年障害は、FlowSpec がエキゾチックだから重要だったのではない。狭い運用意図がバックボーン全体の権限を獲得したから重要だった。

公開証拠は、問題のある FlowSpec アナウンス、BGP 確立障害、広範な到達性喪失、安定性を回復したグローバル設定アクションを示している。また、外部ネットワークがピアリング、経路優先度、古いアドバタイズ、代替容量に応じて障害を異なる形で経験したことも示している。証拠が示していないことも同様に重要である。正確なコマンド、完全な内部トポロジー、個人の意思決定チェーン、独立した長期修復の証明である。

説明責任はこれらの境界に従う。CenturyLink はポリシーを変換、検証、配布したプラットフォームを管理していた。ルーティング制御プレーンとリカバリ経路がそのポリシーから保護されるかどうかを管理していた。顧客とピアは自社の継続性の一部を管理していたが、AS3356 の内部メカニズムを修復することはできなかった。標準化団体と測定組織はプロトコルと観測を提供したが、運用権限は提供しなかった。

したがって、修復基準は具体的である。高い爆発半径を持つポリシーシステムは、実効範囲が意図と一致すること、独立した制御が意味的拡大を拒否すること、制御トラフィックが保護されること、ロールアウトが制限されること、ロールバックが制御プレーン障害を生き残ること、外部到達性が回復を確認することを証明すべきである。その証拠がなければ、「冗長バックボーン」はトポロジーを説明するが、権限は1つの脆弱な経路に集中したままになる。

永続的な教訓は、すべての緩和を遅くすることではない。緊急時が来る前に権限を制約することで速度を安全にすることである。顧客ブロックは顧客ブロックのままでなければならない。それがグローバルなルーティングイベントになり得るとしたら、ネットワークは単に設定エラーを被ったのではない。再構築と証明を必要とする説明責任設計を露出させたのである。

CenturyLink の2020年 FlowSpec 障害が示すバックボーン変更管理と説明責任の試練

概況