Yandex は RPKI を実装します

こんにちは、私の名前はアレクサンダー・アジモフです。 Yandex では、さまざまな監視システムとトランスポート ネットワーク アーキテクチャを開発しています。 しかし、今日は BGP プロトコルについて話します。

XNUMX 週間前、Yandex はすべてのピアリング パートナーとのインターフェイスおよびトラフィック交換ポイントで ROV (ルート オリジン バリデーション) を有効にしました。 これが行われた理由と、それが通信事業者とのやり取りにどのような影響を与えるかについては、以下をお読みください。

BGP とその問題点

おそらく、BGP がドメイン間ルーティング プロトコルとして設計されたことはご存知でしょう。 しかし、その過程で、使用事例の数はなんとか増加しました。現在では、BGP は多数の拡張機能のおかげで、メッセージ バスに変わり、オペレーターの VPN から今流行の SD-WAN までのタスクをカバーし、次のような用途さえ見つかりました。 SDN のようなコントローラーのトランスポートで、距離ベクトル BGP をリンク サット プロトコルに似たものに変換します。

図。 1。 BGP SAFI

なぜ BGP はこれほど多くの用途に利用されている (そして受信し続けている) のでしょうか? 主な理由は XNUMX つあります。

• BGP は自律システム (AS) 間で機能する唯一のプロトコルです。
• BGP は、TLV (type-length-value) 形式の属性をサポートします。 はい、これはプロトコルだけではありませんが、通信事業者間の接続点ではプロトコルに代わるものがないため、追加のルーティング プロトコルをサポートするよりも、プロトコルに別の機能要素を付加する方が有益であることが常に判明します。

彼の何が問題なのでしょうか？ つまり、このプロトコルには、受信した情報の正確さをチェックするためのメカニズムが組み込まれていません。 つまり、BGP はアプリオリな信頼プロトコルです。自分が現在 Rostelecom、MTS、または Yandex のネットワークを所有していることを世界に伝えたい場合は、どうぞ!

IRRDB ベースのフィルター - 最悪の中の最良のもの

なぜインターネットはこのような状況でも機能するのでしょうか?という疑問が生じます。 はい、ほとんどの場合機能しますが、同時に定期的に爆発し、国内セグメント全体にアクセスできなくなります。 BGP におけるハッカーの活動も増加していますが、ほとんどの異常は依然としてバグによって引き起こされています。 今年の例は、 小さなオペレータエラー ベラルーシでは、MegaFon ユーザーがインターネットの大部分に XNUMX 分間アクセスできなくなりました。 もう一つの例 - クレイジーな BGP オプティマイザー 世界最大の CDN ネットワークの XNUMX つを破壊しました。

米。 2.Cloudflareトラフィックの傍受

しかし、それでも、このような異常が毎日ではなく、半年に一度発生するのはなぜでしょうか? 通信事業者はルーティング情報の外部データベースを使用して、BGP ネイバーから受信したものを検証するためです。 このようなデータベースは多数あり、レジストラによって管理されているもの (RIPE、APNIC、ARIN、AFRINIC) もあれば、独立したプレーヤー (最も有名なのは RADB) もあり、大企業が所有するレジストラのセット全体 (レベル 3) もあります。 、NTTなど）。 これらのデータベースのおかげで、ドメイン間ルーティングの動作の相対的な安定性が維持されます。

ただし、ニュアンスがあります。 ルーティング情報は、ROUTE-OBJECTS および AS-SET オブジェクトに基づいてチェックされます。 そして、最初のクラスが IRRDB の一部に対する認可を意味する場合、XNUMX 番目のクラスにはクラスとしての認可はありません。 つまり、誰でも自分のセットに追加できるため、上流プロバイダーのフィルターをバイパスできます。 さらに、異なる IRR ベース間での AS-SET 命名の一意性は保証されていないため、何も変更しなかった通信事業者にとって、突然接続が失われ、驚くべき影響が生じる可能性があります。

さらなる課題は、AS-SET の使用パターンです。 ここでのポイントは XNUMX つあります。

• オペレーターは新しいクライアントを取得すると、それを AS-SET に追加しますが、削除することはほとんどありません。
• フィルター自体は、クライアントとのインターフェイスでのみ構成されます。

その結果、BGP フィルターの最新の形式は、クライアントとのインターフェイスで段階的に劣化するフィルターと、ピアリング パートナーや IP トランジット プロバイダーからのものに対するアプリオリな信頼で構成されています。

AS-SET に基づくプレフィックス フィルターの置き換えとは何ですか? 最も興味深いのは、短期的には何も起こらないということです。 しかし、IRRDB ベースのフィルターの機能を補完する追加のメカニズムが登場しており、まず第一に、これはもちろん RPKI です。

RPKI

単純化すると、RPKI アーキテクチャは、記録を暗号的に検証できる分散データベースと考えることができます。 ROA (Route Object Authorization) の場合、署名者はアドレス空間の所有者であり、レコード自体はトリプル (prefix、asn、max_length) です。 基本的に、このエントリは次のことを前提としています。$prefix アドレス空間の所有者は、AS 番号 $asn が $max_length 以下の長さのプレフィックスをアドバタイズすることを許可しています。 また、ルーターは RPKI キャッシュを使用して、ペアの準拠性をチェックできます。 接頭語 - 途中の最初の話者.

図 3. RPKI アーキテクチャ

ROA オブジェクトはかなり長い間標準化されてきましたが、実際には最近まで IETF ジャーナルの紙面上にのみ残されていました。 私の意見では、この理由は恐ろしいように思えます。マーケティングが悪いからです。 標準化が完了した後は、ROA が BGP ハイジャックから保護されるというインセンティブがありましたが、これは真実ではありませんでした。 攻撃者は、パスの先頭に正しい AC 番号を挿入することで、ROA ベースのフィルターを簡単にバイパスできます。 そして、この認識が得られるとすぐに、次の論理的なステップは ROA の使用を放棄することでした。 実際、機能しないテクノロジーがなぜ必要なのでしょうか?

考えを変える時期が来たのはなぜですか? これがすべての真実ではないからです。 ROA は BGP でのハッカー活動から保護しませんが、 偶発的なトラフィックハイジャックから保護しますたとえば、一般的になりつつある BGP の静的リークによるものです。 また、IRR ベースのフィルターとは異なり、ROV はクライアントとのインターフェイスだけでなく、ピアや上流プロバイダーとのインターフェイスでも使用できます。 つまり、RPKI の導入に伴い、BGP からアプリオリな信頼が徐々に失われつつあります。

現在、ROA に基づくルートのチェックは主要企業によって徐々に実装されており、欧州最大手の IX はすでに誤ったルートを破棄しています。Tier-1 通信事業者の中でも、ピアリング パートナーとのインターフェイスでフィルターを有効にした AT&T に注目する価値があります。 最大手のコンテンツプロバイダーもこのプロジェクトにアプローチしている。 そして、数十の中規模の交通事業者がすでに誰にも知らせずにひっそりと導入している。 なぜこれらの通信事業者はすべて RPKI を実装しているのでしょうか? 答えは簡単です。送信トラフィックを他人の間違いから守るためです。 そのため、Yandex はロシア連邦でネットワークのエッジに ROV を導入した最初の企業の XNUMX つです。

次に何が起こるのだろうか？

トラフィック交換ポイントとプライベート ピアリングを備えたインターフェイスでルーティング情報を確認できるようになりました。 近い将来、上流のトラフィック プロバイダーでも検証が可能になる予定です。

これはあなたにとってどのような違いをもたらしますか? ネットワークと Yandex の間のトラフィック ルーティングのセキュリティを強化したい場合は、次のことをお勧めします。

• アドレス空間に署名します RIPEポータル内 - 簡単で、平均して 5 ～ 10 分かかります。 これにより、誰かが意図せずにあなたのアドレス空間を盗んだ場合に、私たちの接続が保護されます (これは遅かれ早かれ必ず起こります)。
• オープンソース RPKI キャッシュの XNUMX つをインストールします (熟したバリデーター, ルーティネーター)、ネットワーク境界でのルート チェックを有効にします。これにはさらに時間がかかりますが、やはり技術的な問題は発生しません。

Yandex は、新しい RPKI オブジェクトに基づくフィルタリング システムの開発もサポートしています。 ASPA (自律システムプロバイダーの承認)。 ASPA および ROA オブジェクトに基づくフィルターは、「漏洩の多い」AS-SET を置き換えるだけでなく、BGP を使用した MiTM 攻撃の問題も解決できます。

ASPA については、XNUMX か月後の Next Hop カンファレンスで詳しくお話します。 Netflix、Facebook、Dropbox、Juniper、Mellanox、Yandex の同僚もそこで講演します。 ネットワークスタックとその将来の開発に興味がある方は、ぜひお越しください。 登録は受付中です.

出所： habr.com