はじめに
2024年6月27日、世界中で一部の小数ユーザーが、1.1.1.1に到達不能または性能が低下していることに気付いた方もいるのではないかと思います。本現象の根本的な原因は、BGP（ボーダーゲートウェイプロトコル）ハイジャックとルートリークの組み合わせによるものでした。
Cloudflareは、ルートオリジン検証（ROV）のためのリソース公開鍵基盤（RPKI）を早期に採用していました。RPKIを使用すると、IPプレフィックスの所有者は所有権情報を安全に保存・共有することができ、他のオペレーターは、受け取ったBGPルートとルートオリジン認証（ROA）の形式で保存されている情報を比較することによって、BGPアナウンスを検証することができます。ルートオリジン検証がネットワークによって適切に実施され、プレフィックスがROA経由で署名されていれば、BGPハイジャックの影響は大幅に制限されます。過去数年間でRPKIの採用が増え、1.1.1.0/24が署名付きリソースであるにもかかわらず、インシデント発生中、1.1.1.1/32がELETRONET S.A.（AS267613）から配信され、複数のネットワーク（少なくとも1つのTier 1プロバイダーを含む）でブラックホールルートとして受け入れられました。このため、70か国、300以上のネットワークからDNSリゾルバーのアドレスが即座に到達不能となりましたが、ユーザーの全体への影響は非常に低く、たとえば英国とドイツでは1%未満であり、一部の国では、影響に気づいたユーザーは居ませんでした。
ルートリークについては、以前にも記事にしたり話題として取り上げましたが、残念ながら、現在広く展開されている中で、現在行えるのは、プロバイダーによるIRR（インターネットルーティングレジストリ）のプレフィックスリストフィルタリングなど、ベストエフォート型の保護対策のみです。1.1.1.1/32ハイジャックと同じ期間に、Nova Rede de Telecomunicações Ltda (AS262504)が誤って1.1.1.0/24をAS1031にアップストリームでリークし、このリークがPeer-1 Global Internet Exchange（AS1031）によってさらに広く伝播されたこともインシデント中に利用者が感じた影響の一因となりました。
1.1.1.1の利用者が感じた影響についてお詫びするとともに、サービスの運営を非常に重く受け止めております。この影響の根本原因はCloudflareの外部にありましたが、応答時間のより短縮化を実現するために、引き続き検出方法を改善し、インターネットコミュニティ内での当社の立場を利用して、BGPのルートオリジン検証（ROV）や自律システムプロバイダ認可（ASPA）オブジェクトなどのRPKIベースのハイジャックおよびリーク防止メカニズムの採用をさらに促進して参ります。
背景
Cloudflareは2018年に1.1.1.1パブリックDNSリゾルバーサービスを導入しました。発表以来、1.1.1.1は、誰でも無料で使用できる最も人気のあるリゾルバIPアドレスの1つとなっています。人気があり、簡単に認識できるIPアドレスだけに、運用上の困難がいくつかあります。この問題は、過去に研究所内のネットワークやテストIPアドレスとして1.1.1.1を使用したことに起因しており、予期しないトラフィックやブラックホール化したルーティング動作が残っていました。このため、CloudflareはBGPの誤ったトラフィックの影響に対処することは珍しいことではありません。この2つについては、以下で説明します。
BGPハイジャック
この問題の一部は、1.1.1.1のルーティングハイジャックの可能性に起因しています。架空のFooBar Networksが1.1.1.1/32を自社のルーターに割り当て、このプレフィックスを内部ネットワーク内で共有した場合、このお客様は1.1.1.1DNSサービスへのルーティングが困難になります。この1.1.1.1/32プレフィックスを外部ネットワークにアドバタイズすると、影響はさらに大きくなる可能性があります。CloudflareによってBGPでアナウンスされた1.1.1.0/24ではなく1.1.1.1/32が選ばれる理由は、最長プレフィックス一致（LPM）によるものです。ルートテーブルに1.1.1.1アドレスに一致する多くのプレフィックスが存在する場合でも（例えば、1.1.1.0/24、1.1.1.0/29、1.1.1.1/32など）、LPMアルゴリズムでは最も多くのビットが一致し、1.1.1.1アドレスに対して最も長いサブネットマスクを持つ1.1.1.1/32が「最長の一致」と見なされます。簡単に言うと、1.1.1.1/32が1.1.1.1に対して「最も具体的なルート」と呼ばれます。
1.1.1.1へのトラフィックはエニーキャスト経由でCloudflareにルーティングされてグローバルに配置された当社のサーバーの1つに到達するのではなく、FooBar Networks内のデバイスに到達し、そこで1.1.1.1が終了します。その結果、正当な応答がクライアントに返されなくなります。これは、FooBar Networksのネットワーク運用者によって意図的または偶発的に行われた1.1.1.1へのリクエストのハイジャックと見なされます。
BGPルートリーク
1.1.1.1が直面する影響のもう1つの原因は、BGPルートリークです。ルートリークは、ネットワークがアップストリームプロバイダーになるべきではないネットワークに対して、BGPアナウンスの観点からアップストリームになると発生します。
これは、顧客があるプロバイダーから学習したルートを別のプロバイダーに転送し、タイプ1のリーク（RFC7908で定義）を引き起こすルートリークの例です。
デフォルトフリーゾーン（DFZ）_内の十分なネットワークがルートリークを受け入れると、その_不正確な経路情報に沿ってトラフィックを転送するようになります。こうなると、多くの場合、プレフィックスをリークしたネットワークは大量のトラフィックに対応できず、過負荷状態に陥ります。以前、ペンシルベニア州のプロバイダーが、通常はトラフィックを通過させないはずのグローバルな宛先へトラフィックを引き寄せたことで、インターネットの大部分が機能停止に陥った大規模なルートリークについての記事を書いたことがあります。Cloudflareは世界で13,000以上のネットワークと相互に接続していますが、Cloudflareから直接受信したルートよりもリークしたルートに割り当てられたBGPローカルプリファレンスがネットワーク内で優先されてしまう可能性があります。非効率的に聞こえますが、残念ながら実際に起こり得ることです。
この現象を説明するには、BGPをインターネットのルーティングプロトコルとともにビジネスポリシーエンジンとして考えるとよいでしょう。トランジットプロバイダーは、データ転送の対価を支払う有料利用客を有しています。論理的に考えると、その顧客にプライベートまたはインターネットエクスチェンジ（IX）のピアリングでの接続よりも高いBGPローカルプリファレンスを割り当てます。そのため、料金を支払っている接続が最も利用されます。ローカルプリファレンスとは、どの外向き接続にトラフィックを送信するかの優先順位を決める方法と考えてください。異なるネットワークは、インターネットエクスチェンジ（IX）から受信したルートよりもプライベートネットワークインターコネクト（PNI）を優先するという選択をする場合もあります。その理由の1つが信頼性です。その理由は、プライベート接続は、2つのネットワーク間のポイントツーポイント接続と見なすことができ、その間に第三者のマネージドファブリックが介在する心配がないためです。もう一つの理由はコスト効率です。その理由は、お客様自身と別のピア間のクロスコネクトを購入する手間をかけるのであれば、それを活用して投資に見合う最高のリターンを得たいと考えるためです。
BGPハイジャックとルートリークの両方が、1.1.1.1だけでなく、インターネット上のあらゆるIPおよびプレフィックスで発生する可能性があることに注意する必要があります。しかし、前述の通り1.1.1.1は非常に認識され、歴史的に悪用されてきたアドレスであるため、他のIPリソースよりも偶発的なハイジャックやリークが発生しやすい傾向があります。
2024年6月27日に発生したCloudflare 1.1.1.1インシデントでは、私たちはBGPハイジャックとルートリークの両方の組み合わせと戦うことになりました。
インシデントのタイムラインと影響
記載の時間は全て協定世界時（UTC）です。
2024年06月27日18:51:00、AS267613（Eletronet）が1.1.1.1/32をピア、プロバイダー、およびお客様に対してアナウンスを開始。1.1.1.1/32はオリジンASであるAS267613でアナウンスされる。
2024年06月27日18:52:00、AS262504（Nova）がAS267613から受け取った1.1.1.0/24をASパス「1031 262504 267613 13335」でアップストリームのAS1031（PEER 1 Global Internet Exchange）にリーク
2024年06月27日18:52:00、AS1031（Novaのアップストリーム）が1.1.1.0/24を様々なインターネットエクスチェンジのピアとルートサーバーに伝播したことでリークの影響が拡大
2024年06月27日18:52:00、1つのTier 1プロバイダーがAS267613から1.1.1.1/32のアナウンスをRTBH（Remote Triggered Blackhole）ルートとして受け取り、そのTier 1の顧客全体でトラフィックがブラックホール化される
2024年06月27日20:03:00、Cloudflareが、様々な国からの1.1.1.1の到達可能性に関する問題に対して内部インシデントを発令
2024年06月27日20:08:00、Cloudflareが1.1.1.0/24へのトラフィックを受け取っているAS267613とのパートナーピアリングロケーションを無効化
2024日06月27日20:08:00、Cloudflareチームがインシデントについて、ピアリングパートナーのAS267613と連絡を取る
2024年06月27日20:10:00、AS262504が新しいASパス「262504 53072 7738 13335」で1.1.1.0/24を再度リークし、AS1031によって再配布される。このパスに沿っている場合トラフィックはCloudflareに正常に配信されるが、影響を受けるクライアントには高い遅延が発生する
2024年06月27日20:17:00、Cloudflareがアップストリームプロバイダーへの1.1.1.0/24のルートリークについて、AS262504と連絡を取る
2024年06月27日21:56:00、Cloudflareのエンジニアが、ブラジル国以外の複数のソースから1.1.1.0/24向けのトラフィックを受信しているAS267613との2番目のピアリングポイントを無効化
2024年06月27日22:16:00、AS262504が再度1.1.1.0/24をリークし、サンパウロのAS267613とCloudflareピアリングに一部のトラフィックを引き寄せる。結果として、一部の1.1.1.1リクエストは高い遅延で返されますが、1.1.1.1/32のハイジャックとトラフィックのブラックホール化の解決が観測される
2024年06月2802:28:00、AS262504の1.1.1.0/24のルートリークが完全に解決
お客様への影響は、「1.1.1.1にまったく到達できない」または「1.1.1.1に到達できるが1リクエストあたりの待機時間が長い」のどちらかで表面化しました
AS267613がネットワーク内のどこかで1.1.1.1/32アドレスをハイジャックしていたため、多くのリクエストがその自律システム内の複数のデバイスにおいて失敗しました。このインシデントにおいて、高い遅延ではあったものの、1.1.1.1に向けたリクエストがCloudflareのデータセンターに正常にルーティングされる期間（フラップ）がありました。
インシデント発生時に影響を受けた2つの国（ドイツと米国）を見ると、影響を受けた1.1.1.1へのトラフィックは以下のようになっています：
送信元ユーザーの国：
全体的にこの図は送信元の国あたりのリクエストの総量が比較的少ないことを意味しますが、通常であれば、米国やドイツからブラジルに1.1.1.1のリクエストがルーティングされることはありません。
Cloudflareデータセンターの立地：
グラフを見ると、1.1.1.1へのリクエストがブラジルのデータセンターに到達していることがわかります。スパイク間の落ち着きは、1.1.1.1リクエストがAS267613の前、またはAS267613内でブラックホール化された時期を示しており、スパイク自体は、リクエストとレスポンスに高い遅延を生じさせながらも、トラフィックがCloudflareに届いた時期を示しています。AS267613を使用してCloudflareピアリング場所に正常に送信されたトラフィックの短時間のスパイクは、ネットワーク内でフラッピングしている1.1.1.1/32ルートにより、トラフィックが途中経路のどこかで破棄されずにCloudflareまで到達することがあったためです。
障害の技術的説明と発生原因について
通常、ユーザーから1.1.1.1へのリクエストは、BGP Anycastを介して最も近いデータセンターにルーティングされます。このインシデントの間、AS267613（Eletronet）が1.1.1.1/32をピアとアップストリームプロバイダーにアドバタイズし、AS262504は1.1.1.0/24をアップストリームにリークしたことで、複数のネットワークでBGP Anycastの通常の経路が大幅に変更されました。
パブリックルートコレクターとモノクルツールを使用することで、不正なBGPアップデートを検索することができます。
上記では、AS398465とAS13760がルートビューコレクターに、影響が始まった頃にAS267613から1.1.1.1/32を受け取っていることが分かります。通常、デフォルトフリーゾーン（DFZ）で受け入れられる最長IPv4プレフィックスは/24ですが、ここでは、複数のネットワークがAS267613から1.1.1.1/32ルートを転送に使用しているため、トラフィックがCloudflareのPOP（Point of Presence）に到達せずブラックホール化しています。AS267613による1.1.1.1/32のアナウンスは、BGPルートハイジャックです。ルートオリジン認証（ROA）は、最大プレフィックス長が/24の配信元AS13335（Cloudflare）に対してのみ署名されているにもかかわらず、配信元AS267613のプレフィックスをアナウンスしていました。
Cloudflareで独自のBMP（BGPモニタリングプロトコル）データを調べたところ、1.1.1.1/32のBGPアップデートも確認されました。少なくともいくつかの異なるルートサーバから、BGP経由で独自の1.1.1.1/32アナウンスを受け取っています。幸いなことに、Cloudflareは、無効なASオリジンとプレフィックス長により、RPKIが無効およびDFZが無効という両方の理由でインポート時にこれらのルートを拒否しています。BMPデータ表示はポリシー適用前のものであるため、ルートを拒否しても、そのルートがピアリングセッションを通じてBGPアップデートを受信した場所を確認することができます。
monocle search --start-ts 2024-06-27T18:51:00Z --end-ts 2024-06-27T18:55:00Z --prefix '1.1.1.1/32'
A|1719514377.130203|206.126.236.209|398465|1.1.1.1/32|398465 267613|IGP|206.126.236.209|0|0||false|||route-views.eqix
–
A|1719514377.681932|206.82.104.185|398465|1.1.1.1/32|398465 267613|IGP|206.82.104.185|0|0|13538:1|false|||route-views.ny
–
A|1719514388.996829|198.32.132.129|13760|1.1.1.1/32|13760 267613|IGP|198.32.132.129|0|0||false|||route-views.telxatlつまり、複数のネットワークがグローバルルーティングテーブルに存在すべきではないプレフィックスを受け入れるだけでなく、RPKI（リソース公開鍵インフラストラクチャ）が無効なルートも受け入れています。さらに悪いことに、あるTier-1トランジットプロバイダーが、AS267613からRTBH（リモートトリガーブラックホール）ルートとして1.1.1.1/32アナウンスを受け入れ、通常であればCloudflareにルーティングされるすべてのトラフィックをエッジで破棄しています。1.1.1.1へのルーティングでこの特定のTier-1プロバイダーを活用するネットワークは、インシデント中にIPアドレスに到達できなかったため、これだけでも幅広い影響を引き起こしました。
リモートトリガーブラックホールをあまりご存知でない方のために説明すると、これは、プロバイダーに対してネットワーク内で破棄してほしい宛先のトラフィックを示すための方法で、DDoS攻撃に対抗する荒療治として存在するものです。特定のIPアドレスまたはプレフィックスが攻撃を受けている場合、ネットワークポートに到達する前に宛先IPアドレスまたはプレフィックスを破棄することで、その宛先IPアドレスまたはプレフィックスに向かうすべてのトラフィックを吸収するようにアップストリームプロバイダーに指示することができます。このインシデントの問題は、AS267613が1.1.1.1/32をブラックホール化する権限を持っていなかったということでした。Cloudflareは、AS13335宛てのトラフィックを破棄するためにRTBHを利用する唯一の権利を持つ必要がありますが、実際にはそれを行うことはありません。
1.1.1.0/24のBGPアップデートを見ると、複数のネットワークがAS262504からプレフィックスを受信し、それを受け入れています。
ここで再びASパスに注目します。今回は、アナウンスの最後にあるAS13335が発信元ASです。このBGPアナウンスは、発信元が正しくAS13335であるため、RPKIが有効ですが、パス自体が無効であるため、これは1.1.1.0/24のルートリークです。
ルートリークであると知る方法は？
~> monocle search --start-ts 2024-06-27T20:10:00Z --end-ts 2024-06-27T20:13:00Z --prefix '1.1.1.0/24' --as-path ".* 267613 13335" --include-sub
.. some advertisements removed for brevity ..
A|1719519011.378028|187.16.217.158|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|187.16.217.158|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views2.saopaulo
–
A|1719519011.629398|45.184.147.17|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|45.184.147.17|0|0|1031:1031 1031:4209 1031:4259 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519036.943174|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|route-views.amsix
–
A|1719519037|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|rrc03
–
A|1719519087.4546|45.184.146.59|199524|1.1.1.0/24|199524 1031 262504 267613 13335|IGP|45.184.147.17|0|0||false|13335|162.158.177.1|route-views.fortaleza
A|1719519087.464375|45.184.147.74|264409|1.1.1.0/24|264409 1031 262504 267613 13335|IGP|45.184.147.74|0|0|65100:7010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519096.059558|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3
–
A|1719519128.843415|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3パスの例「199524 1031 262504 267613 13335」を見ると、AS267613は機能的にAS13335のピアであり、1.1.1.0/24アナウンスをピアまたはアップストリームと共有せず、顧客（AS Cone）のみと共有する必要があります。AS262504はAS267613の顧客であり、パスの次の隣接ASN（自律システム番号）であるため、この特定のアナウンスはこの時点までは問題ありません。1.1.1.0/24で問題が生じたのは、AS262504がアップストリームであるAS1031にプレフィックスをアナウンスした時点です。さらに、AS1031はそのアドバタイズをピアに再配信しました。
これは、AS262504がリークを引き起こしたネットワークであることを意味します。AS1031は、顧客であるAS262504からリークを受け入れ、世界の複数のピアリングロケーションにルートを配布したことで幅広い影響を引き起こしました。AS1031（Peer-1グローバルインターネットエクスチェンジ）は、グローバルピアリングエクスチェンジとしてアドバタイズしていますが、CloudflareはAS1031の顧客ではないため、1.1.1.0/24はAS1031のピア、ルートサーバー、またはアップストリームに再配布されるべきではありませんでした。AS1031は、顧客BGPセッションのフィルタリングをほとんど行わず、隣接性（この場合はAS262504）と一致し、この基準を満たすものすべてを再配布するようです。残念ながら、これはAS1031にとって無責任なことであり、1.1.1.1や、保護されていないルート伝播の被害に遭う他のサービスに直接影響を与える可能性があります。もともとのリーク元ネットワークはAS262504でしたが、AS1031やその他の企業がハイジャックやリークを受け入れてさらにアナウンスを配布したことで、影響が大幅に増幅されました。
インシデントの大部分では、AS262504によるリークによってリクエストは最終的にAS267613内に送られることになり、AS267613はネットワーク内のどこかで1.1.1.1/32のトラフィックを破棄していました。そのため、AS262504はアップストリームルートをリークすることで、1.1.1.1の到達不能性の影響を増幅させました。
ルートリークの影響を制限するために、CloudflareはAS267613で複数の場所でのピアリングを無効にしました。AS262504がサンパウロを指す古いパスをリークし続けていたため、問題は完全には解消されていませんでした。サンパウロに到達したリクエストは処理することができましたが、ユーザーへの往復時間が長くなりました。Cloudflareは現在、リークと将来の防止メカニズムに関して、この記事全体で言及したすべてのネットワークとの対話を行っています。また、AS267613から1.1.1.1/32をCloudflareの許可なしにブラックホールルートとして受け入れ、大規模な影響を引き起こしたTier 1トランジットプロバイダーのうちの少なくとも1社とも対話をしています。
改善とフォローアップ手順
BGPハイジャック
RPKIのオリジン検証RPKIは最近、インターネットのルート情報を署名して保護する技術であるルートオリジン認証（ROA）を使って、全プレフィックスの50%を保護するという重要な目標を達成しました。確かに、RPKIはインターネット全体へハイジャックされたBGPプレフィックスの拡散を制限するのに役立ちますが、すべてのネットワーク、特にダウンストリームの自律システム（AS）が大量に存在する主要ネットワークの強力が必要です。1.1.1.1/32がハイジャックされた際、複数のネットワークがAS267613によってアナウンスされたルートを受け入れ、トラフィックの転送に使用しました。
RPKIとリモートトリガーブラックホール（RTBH）このインシデント中の大きな影響は、Tier 1プロバイダーがCloudflareではないサードパーティからの1.1.1.1/32をブラックホールルートとして受け入れたことによるものです。これ自体は1.1.1.1のハイジャックであり、非常に危険なものです。RTBHは、大規模なDDoS攻撃の軽減に苦労する場合に多くのネットワークで使用されている有用なツールです。問題は、RTBHに使用されるBGPフィルタリングは本質的に緩く、インターネットルーティングレジストリで見つかったAS-SETオブジェクトにのみ依存することが多いことです。ルートオリジン認証（ROA）に依存することは、RTBHフィルタリングの場合、Cloudflareのような大規模ネットワークに対して何千もの潜在的なROAを作成する必要があるため、現実的ではありません。さらに、特定の/32エントリを作成すると、AS13335になりすました誰かによって1.1.1.1/32などの個別のアドレスがアナウンスされ、インターネット上で1.1.1.1への最適なルートとなり、深刻な影響を引き起こす可能性があります。
AS-SETフィルタリングは、1.1.1.1/32のようなルートをブラックホール化する権限を表すものではありません。Cloudflareだけが、自分の運営する宛先をブラックホール化できる必要があります。プロバイダーのRTBHセッションの緩いフィルタリングを修正するための方法の一つとして、再びRPKIを活用することが考えられます。IETFの例を使うと、期限切れのdraft-spaghiti-sidrops-rpki-doa-00提案で、特定のオリジンだけがプレフィックスに対してブラックホールアクションを承認するDiscard Origin Authorization（DOA）オブジェクトが指定されていました。そのようなオブジェクトが署名され、RTBHリクエストがオブジェクトに対して検証された場合、AS267613による1.1.1.1/32の未承認のブラックホールの試みは、Tier 1プロバイダーによって受け入れられることなく、無効になります。
BGPのベストプラクティス単純にMANRSが定めたBGPのベストプラクティスに従い、デフォルトフリーゾーン（DFZ）で/24より長いIPv4プレフィックスを拒否することで、1.1.1.1への影響を軽減することができます。広範なインターネット内で無効なプレフィックス長を拒否することは、すべてのネットワークのための標準BGPポリシーに備えられているべきです。
BGPルートリーク
Route Leak Detection
現在、ルートリークはCloudflareにとって避けられないことではありませんが、インターネットは本質的に相互接続の信頼に依存しているため、影響を制限するために講じるいくつかの措置があります。
私たちは、今後も同様の事象が発生した場合に迅速に対応できるよう、ルートリーク検知システムで使用するデータソースを拡大し、検知システムにリアルタイムデータを組み込む作業を進めています。
BGP向けASPA
当社は、ASパスベースのルートリーク対策にRPKIを採用することを引き続き提唱していきます。自律システムプロバイダ認可（ASPA）オブジェクトはROAと似ていますが、許可されたオリジンASでプレフィックスに署名する代わりに、AS自体は、ルートの伝播が許可されたプロバイダーネットワークのリストで署名されます。したがって、Cloudflareの場合、有効なアップストリームトランジットプロバイダーのみが、1.1.1.0/24アップストリームのようなAS13335プレフィックスのアドバタイズを許可されたものとして署名されます。
AS262504（AS267613のカスタマー）が1.1.1.0/24アップストリームを共有したルートリークの例では、AS267613が認定プロバイダーに署名し、AS1031がそのリストに対してパスを検証している場合、BGP ASPAはこのリークを検知します。ただし、これはRPKIオリジン検証と同様に、特に大規模プロバイダーがASPAオブジェクトに基づいて無効なASパスを拒否することに依存するため、長期的な取り組みとなることが見込まれます。
その他の潜在的なアプローチ
ASPAには、注目に値するさまざまな導入段階にある代替アプローチが存在します。以下がその例ですが、広くインターネットに展開される段階まで達するという保証はありません。
たとえば、RFC9234では、BGPの機能と属性にピアロールという概念が使用されており、更新のパスに沿ったルーターの設定に応じて、「Only-To-Customer」（OTC）属性をプレフィックスに追加することで、1.1.1.0/24などのプレフィックスがリークしたパスに沿ってアップストリームへの拡散を防止します。しかし、欠点として、BGPの設定が必要であり、各ピアリングセッションに対してさまざまなロールを割り当てる必要があります。また、ベンダーの採用が完全に進んでいないため、実際の運用でこの方法を使用して良好な結果を得るには、まだ課題があります。
ルートリークを解決するためのすべてのアプローチと同様に、成功するにはインターネット上のネットワークオペレーター間の協力が必要です。
まとめ
Cloudflareの1.1.1.1DNSリゾルバーサービスが、BGPハイジャックとBGPルートリークという2つのイベントの被害に同時に遭いました。外部ネットワークの行動はCloudflareの直接的なコントロール外ですが、インターネットコミュニティおよびCloudflareの社内の両方で、影響をより迅速に検出し、ユーザーへの影響を軽減するためにあらゆる措置を講じる予定です。
長期的には、CloudflareはRPKIベースのオリジン検証とASパス検証の採用を引き続きサポートします。前者は世界最大級のネットワークの広範囲に展開され、後者はIETF（インターネット技術タスクフォース）でまだ草稿の段階にあります。その間、isbgpsafeyet.comおよび_Test Your ISP_にアクセスすることで、ご利用のISPがRPKIオリジン検証を実施しているかどうかを確認することができます。