同僚、注意！ 私たちのイニシアチブでは、BGPプロトコルでの「ルートリーク」の発生に対する自動保護を導入するために、BGPプロトコルで採用コールが発表されました。
つまり、2017年5月21日からIETFメーリングリストで2週間（ ここで購読できます ）、ワーキンググループの作成者による提案案を受け入れることのすべての長所と短所について議論します。 投票の結果に応じて、このドキュメントの作業は、標準ステータス（RFC）が受信または凍結されるまで継続されます。
BGP問題の状態に関心があるすべての人に、「draft-ymbk-idr-bgp-open-policy-03」という見出しの下のメッセージスレッドで英語で自分の主張を表現するようにお願いします。 意見を表明するときは、雇用主の意見ではなく、エンジニアとして意見を表明する必要があります。 あなたの意見が推論されることは非常に望ましいです-このため、あなたは私たちの提案にもう一度慣れることをお勧めします（ドラフトへのリンク： one 、 two ）。
IETFメーリングリストで誰でも意見を述べることができることを思い出してください。資格はありません。
すべての技術専門家、システム管理者、開発者、および最新のネットワークの効率的な運用を保証する重要なプロトコルの1つを近代化するイニシアチブを声援する準備ができている関心のある人のみに感謝します。
ありがとう
こんにちは 私の名前はAlexander Azimovで、Qrator Labsを代表しています。 今日、ルートリークに関する最新情報を提供します。 ルートリークのトピックを新しいと呼ぶことはできません。この問題は、私も含めて2、3回発生しました。 それでも、ホールに新参者がいる場合、そうであることを願っていますが、まずはルートリークと考えられる結果を特定することから始めます。
事前に予約しておくのは、輸送ルートの漏れについてのみです。 ルートリークは、1つのアップストリームプロバイダーまたはピアから受信したプレフィックスが別のアップストリームプロバイダーまたはピアにアナウンスされる状況です。 良い質問：あなたは何を気にしますか？ ある自律システムが、あるプロバイダーからのプレフィックスを受け入れ、別のプロバイダーにアナウンスする場合、何を気にしますか？
残念ながら、これはあなたのビジネスです-ほとんどの場合、追加の希望はネットワーク遅延を増加させますが、MitM攻撃にも使用できます。 そして、あなたは、あなたのネットワーク、あなたのグローバルな可用性、接続性を、すでに自分自身が不十分に管理されていることを示した他の誰かのネットワークに依存させたくありませんか？
このような事件がどのようなネットワークに影響するかを見てみましょう。
スライドには、2017年4月に収集した統計が表示されます。ご存知のように、毎日何千ものルートリークがあります。 これらの異常に現れるネットワークのセットは毎日変化します。したがって、4月には、40,000を超える異なるリークプレフィックスが見られます。 しかし、実際には、ルートリークは両刃の剣に似ているため、問題のあるネットワークの数ははるかに多くなります。 リークしたプレフィックスだけでなく、それらを受け入れたネットワークや自律システムにも影響します。 それでは、効果は何ですか？ あなたは驚くでしょう-それらはまったく同じです。 リークされたプレフィックスを受け入れる場合、トラフィックとクライアントのトラフィックを同じ設定が不十分なネットワークを介してリダイレクトし、まったく同じ結果になります。 最終的に影響を受ける人は誰ですか？
ほとんどすべての通信事業者が影響を受けていることがわかりました。 毎日、ほぼすべてのネットワークが少なくとも1つの漏えいしたルートを取ります。
したがって、問題はグローバルであり、すべての人に影響します。 そして、伝統的な疑問が生じます-誰が責任があるのでしょうか？
特定の悪意のあるリークをまとめてみましょう。 それらは存在しますが、ほとんどのルートリークは、BGPの動作原理を理解しておらず、設定時にミスを犯しているために発生します。 ある程度、間違った構成が見られる自律システムの数は多く、4月には1000を超えるそのようなプロバイダーがありました。
ご覧のとおり、この傾向は、観測ウィンドウを拡大しようとすると、このような異常を引き起こすスピーカーの数がさらに増えることを示しています。
それで、私たちは何ができますか？ 私たちはこれらのオペレーターに連絡することができ、彼らに間違いがある場所を説明しようとすることができます。 そして、彼らの意志が良ければ-多分彼らはそれを直しますが、保証はありません。 したがって、ルートリークの問題の技術的な側面に注目することをお勧めします。
何がありますか？
もちろん、BGPコミュニティがあります。 コミュニティを正しく構成し、フィルターを正しく構成すると、特定のネットワークがこのような異常の原因になることはありません。 2つの問題があります：ifとright。 検証はなく、プロトコルに組み込みのサポートはありません。これは、BGPの典型的なケースです-制御を損なうことに対する過度の柔軟性。 この柔軟性の結果、何千ものルートリークが発生します。
もちろん、別の方法もあります。何らかの方法で、着信BGPアナウンスメントのフィルターを構成して、それらの間のリークを検出し、それ以上の送信を停止します。 今日まで、最善の方法はAS-SETを使用することですが、ここでも問題に直面しています。 すべてのインターネットルーティングレジストリがそれらをサポートしているわけではありません;さらに、すべてのAS-SETが当てはまるわけではありません。 それらの一部は単純に正しくないため、たとえば、DTAGなどのクライアントのリストを独自のAS-SETに追加するために、承認を必要としないことを忘れないでください。 しかし、すべてのAS-SETが真実で関連性のある理想的な世界にいるとしましょう。
それでもなお、これはルートリークの一般的な問題を解決するものではありません。自律システムのクライアントコーンでこのような異常が発生した場合、そのソースは正しく、これらのアナウンスを受け入れる必要があるためです。 この場合、すべての上位レベルの通信事業者もこの誤ったルートを受け入れて使用することは明らかです。
どのソリューションが残っていますか？ これは監視中です。 実際、これはネットワークの境界外のルートリークを検出する唯一の実際の方法です。 予備的な結論を下しましょう。
今日、正しいBGPコミュニティを構成し、適切なフィルターを設定すれば、自社ネットワーク内でのリークの可能性を排除します。 着信プレフィックスに最も厳格なフィルターを設定すると、いくつかのルートリークを除外できます。 監視は、自分のネットワーク外のルートリークを検出する唯一の方法です。 監視は、誰かからのBGPルーティングリークの受け入れを検出することもできます。
ただし、上記のオプションのいずれも、指定されたオペレーターの外部で発生したルートリークを自動的に修正することを可能にしません。 サードパーティのリークを単独で修正することはできません。 この観点から見ると、問題は非常に複雑で混乱しているように見えます。
同時に、ピアツーピアの関係を入力する問題はありません。 4種類しかありません。 4番目の基本的なものの複雑な組み合わせである、別の5番目が可能です。 私の観点から見ると、ルートリークの問題は、BGPのプロトコルレベルで表される同じネイティブの関係の欠如に関連しています。 したがって、この問題を解決するために、BGPに「ロール」を追加することを提案しました。
ピアツーピア関係を反映するだけの新しい構成パラメーターBGPロールを追加することをお勧めします。 公開された役割のBGP機能を使用し、BGPに関するローカル設定とのコンプライアンスを確認するBGPセッションの開始時に、スピーカーは情報を交換します。 競合が発生した場合はどうなりますか？ これは、おそらく、あなたまたはあなたの隣人が、BGPセッションを誤って設定しようとしていることを意味します。 代替手段はありません。そのようなBGPセッションは中断する必要があります。
役割は自然なメカニズムだと思います。 役割は第三者に何も明らかにしません-心配することは何もありません。 また、ロールには多くの用途があります。 以前は手動で構成する必要があったメカニズムを自動化するために使用できます。
まず、これらは同じルートリークです。 役割を確立して修正したら、長さがゼロ（これは単なるフラグです）の「顧客専用内部」（iOTC）と呼ばれる別の属性を追加することを提案します。 ピアとプロバイダーから受信したすべてのルートにインストールされ、属性が設定されている場合、他のプロバイダーとピアへのアナウンスをフィルターする一連の自動フィルターを設定できます。 つまり ロールの設定に加えて、ルートリークを防ぐために追加の設定は必要ありません。
4オクテットの長さで、それをインストールした自律システムの番号に対応する「外部専用顧客」（eOTC）属性を確認します。 ルートがネイバーまたはクライアントにアドバタイズされる場合、自律システムはそのAC番号に等しい値を設定する必要があります。 この属性の値は変更しないでください。 提示されたシナリオでは、自律システム3は、自律システム2によって発生したルートリークを検出します。非常にシンプルで、最も重要なことは、それが機能することです。
それでは、ルートリークが見つかった場合はどうでしょうか。 プレフィックスをフィルタリングする必要があるようです。おそらくセッションをリセットする必要がありますが、実際には、3回考えて熱意を減らす必要があります。
ルートリークの検出は、eOTC推移的属性に基づいています。 他の推移的な属性と同様に、誤って変更される可能性があります。 そのため、セッションをフィルタリングして中断するのではなく、Lの値のみを非優先にする必要があります。それだけです。 ほとんどの場合、これは、リークしたルートの転送および使用から自律システムを保護するのに十分です。
GitHubにあるBIRDルーティングデーモンに基づいた概念を既に紹介しています 。 ご覧のように、構成内にはスピーカー内のルートの漏出に対する自動保護に必要なラインは多くありません。最も重要なことは、ネットワーク外から発生した漏出したルートの検出です。
一般的に、私にはそれはクールなアイデアのように思えました。 問題に対する何らかの一般的な解決策があります。 彼女はコードにいます。 ハンドルが曲がってこれらのメカニズムの動作に入る可能性がなく、すべてが自動化されています。 さらに、OPENを使用した隣接者による検証により、基本的な役割設定が正しいことが保証されます。 これが、IETFでアイデアを採用することにした理由です。 ダーリンは面白かったが、難しくて長くなった。
www.ietf.org/id/draft-ymbk-idr-bgp-open-policy-03
tools.ietf.org/html/draft-ymbk-idr-bgp-eotr-policy-00
彼の助けがなければ私はあきらめていたので、私はランディ・ブッシュに特別な感謝を伝えたいです。 今日は2つのドラフトがあります。 最初は、役割とiOTCについて説明します。 2番目はeOTCです。 両方が最終的に受け入れられ、近い将来にルーターのソフトウェアでの役割サポートが見られることを願っています。
tools.ietf.org/html/rfc7908
tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06
tools.ietf.org/html/draft-ietf-grow-bgp-reject-07
このトピックに関連する他のイニシアチブもいくつかあります。 それらの1つは、Job SnijdersによってBGP拒否と呼ばれ、BGPルーターの基本的な動作を変更します。 インポートまたはエクスポートポリシーがない場合、アナウンスの交換は行われないという考え方です。
NISTの同僚が作成したeOTCライバルもあります。 また、この問題に関するRFCステータスを持つ唯一のドキュメントは純粋に情報にすぎないことに注意してください。ルートリークとは何かを説明し、タイプの分類を示します。
質問：IETFをそのようなスローモーションのせいにするべきでしょうか？ おそらく、BGPルーティングに興味を持っていると思われる100人の人々がここにいると思いますが、IETFメーリングリストに登録していることを願っています。 そのため、IETFの停滞を非難する代わりに、彼と協力してください。 これが主なものです。
Initiative.qrator.net/details/route-leak-mitigation
その結果、何が得られますか？
これまでのところ、機能するコミュニティを適切に構成し、ルートリークがネットワークに与える可能性のある損害を最小限に抑えるために、プレフィックスを監視せずにフィルタを効率的に機能させる通常の方法はありません。
プロトコル自体に変更が行われる可能性があります。そうでない場合は（基本設定を使用して）リークの問題が解消されます。
このチャンスの存在は直接あなた次第であり、IETF内でのあなたの仕事とコラボレーションです。 ありがとう