_ITRC42_nishizuka2.pptx

Transcription

1 BGP によるドメイン間経路制御の現状と将来 : 障害事例と対策 インターネット技術第 163 委員会研究会 (ITRC meet42) NTT コミュニケーションズ 塚要

2 紹介 : l 塚要 ( にしづかかなめ ) l 2006 年 NTT コミュニケーションズ 社 l OCN アクセス系ネットワークの設計に従事した後 規模 ISP の運 サービスを担当 現在は研究開発組織にて トラフィック分析など ISP の課題に関する研究開発に従事 l メインフィールド l トラフィック分析 l DDoS 対策 l IPv4 枯渇対策関連技術 l 社外活動 l IETF 標準化 DOTS WG l JPNIC IPv6 教育専 家チーム

3 この発表では : l インターネットを流れるトラフィックの全体的な傾向がわかる ( ) l ISP の視点で BGP によってトラフィックがどのような 的で制御されているかがわかる l CDN による BGP を無視した配信の ISP 視点でのインパクトがわかる l 8/25 に発 した Route Leak 事象の背景がわかる

4 トラフィック傾向 複数 ISP のフロー情報により算出したトラフィック 期傾向を分析 送信元 IP アドレスを AS 番号に変換 ダウンロードトラフィックがどのオリジン AS から流れてくるかを集計 対象期間 :2016 年 年 8

5 ダウンロードトラフィックの寡占化 トラフィック量 (CDF) Top AS 全体比率 % % % AS( 対数 ) l 上位 100 AS で全トラフィックの約 96% を占める l 100AS 程度みれば トラフィックのおおよその 積もりには 分

6 増加傾向のコンテンツ l シェア = 対象 AS からのトラフィック / 全体トラフィック l 成 幅 = シェア上昇幅 (1 年での成 の傾き )

7 知 (2016 年 ~2017 年 ) l 上位コンテンツによる寡占化が進む l Google トラフィックのさらなる伸 l シェア 成 幅ともに最 l GCP, AWS, Azure などのクラウドサービスのシェアの伸 l SNS 系も順調にシェア増 l コンテンツのリッチ化 l 動画配信サイトも堅調にシェアを伸 l ゲーム配信系が新興 l 新興 CDN 事業者が え始めてきた l 国内 ISP からのトラフィックのシェアが減少

8 トランジット : 引きの強さと 学

9 引きの強さ l 引きの強さ : ある ISP が複数事業者でマルチホームしているときに 下りトラフィックがどちらのトランジットから流れてくるかという強さのこと ユーザ (Eyeballs) ISP Transit A Transit B コンテンツプロバイダ

10 コミット l トラフィックを何 Gbps まで流してよいのか というトランジット事業者との契約上の合意 l 10G の回線をひいたとて 従量制の料 体系 ( メガ単価 : $/ Mbps/month の価格 ) が基本 l しかし 企業の会計上は従量制の料 体系は処理しにくいので 何 Gbps までなら固定でいくら という契約を う l 例えば 3Gbps まで 100 万円 / というのを 5Gbps まで 100 万円 / にすると 収 は変わらないが実質の値下げになる l 顧客 ISP は コミットが増えた分 その回線に流したいが はたしてどのように流すのか? というのがキーポイント

11 AS-PATH による制御 (BGP) l 楽観的なトラフィック制御では AS-PATH の さで制御されるので 流したくないトランジットピアに AS Prepend をつけることで流したい回線に下りトラフィックが流れる ユーザ (Eyeballs) ISP AS プリペンドで AS-PATH を長くすることでネットワーク的に遠く見せる Transit A Transit B コンテンツプロバイダ l 実際は AS-PATH では制御されていないので ほとんどよらない ( 後述 )

12 ロンゲストマッチによる制御 l longer 経路を流せば ほぼ必ず寄ることは期待できる l ただし prefix の分割は禁断の 法 l 運 の複雑化 レイテンシの増加 トラブルの元 フルルートの増加 ユーザ (Eyeballs) 細切れ経路を A にだけ流せば ロンゲストマッチにより A にトラフィックが寄る ISP Transit A Transit B コンテンツプロバイダ

13 コンテンツへのホップ数 l 国内主要トランジット事業者 (6 社 ) について 主要 AS に何ホップで到達できるかを BGP 経路から算出 AS( トラフィック順 ) l トラフィックの多い AS ほどホップ数は近い ( 世の中のピアリング戦略が有効に働いている )

14 凝縮するインターネット l ホップ数とトラフィックシェア トラフィックシェア トラフィックシェアで重みづけした平均ホップ数 Transit A 2.22 Transit B 2.46 Transit C 2.23 Transit D 2.20 Transit E 2.23 Transit F 2.20 ホップ数 l 国内でトランジットを購 すると 6 8 割のトラフィックは 2 ホップで到達

15 ISP のトラフィックエンジニアリングは 効かない l 主要コンテンツはほとんど 2 ホップ先 ユーザ (Eyeballs) こっちから流してほしいが ISP Transit A Transit B コンテンツプロバイダ l コンテンツ側に 特定のトランジットに流すインセンティブがあると ISP 側のトラフィックエンジニアリングは効かない l コンテンツ事業者にとっての 銭的インセンティブ l アプリケーションアウェアルーティング (cf. Google Espresso) l 上記のシチュエーションでは AS プリペンドによる操作は効かない l Transit B にとって ISP は顧客なので AS-PATH よりも Local Preference 値 ( 通常 customer > peer) が優先される

16 Google のトラフィックエンジニアリング (TE) および Espresso トラフィックエンジニアリングの入力 1) BGP 経路 2) ユーザの利用帯域と品質 3) ピアのリンク使用率 と コストなどのハイレベルなポリシ ( 論文では強調していないが ) Google にとっての効用 : グローバルトラフィック最適化 : ピアのリンク使用率の向上 ApplicaDon-aware TE: End-to-End の QoE の向上 コストダウン

17 Espresso における ベストパス (Overflow) ISP overflow したトラフィックの割合 50% 以上の ISP で 10% 以上のトラフィックが 他に回ったほうがいいとなった ごく少数の ISP では ほとんどのトラフィックが Overflow した ISP 視点では 迷惑な話

18 8/25 経路漏れ (Route Leak) 事象

19 事象の概要 : 何が起きたのか? Route Leak from Google Google からベライゾン経由の経路漏れ Google がピアから受け取った経路を誤って広報してしまった ベライゾンはそれを受け取ってしまった 経路は ISP がインターネットに通常広報している経路よりも細切れだった Recommended ArDcles 8 月 25 日に発生した大規模通信障害をまとめてみた OCN はとばっちり 米グーグルによる大規模ネット障害の真相 パブリックデータから経路リークを探る 08/25 の通信障害概説 (pdf) Large BGP Leak by Google Disrupts Internet in Japan BGP leak causing Internet outages in Japan and beyond

20 先 も Route Leak from Level3 (11/6) 北米のインターネットが約90分間不安定に 内部のComcast細切れ経路(18AS/3000 prefix)の漏洩

21 Peer Leak: ユーザへの影響について 経路リーク時 Google 以外のダウンロードトラフィック ( 全体の 70% 程度 ) Google 経路消去時のルーティングループ 被害 ISP の細切れ経路 海外経由による遅延の増加 一部影響のなかったトラフィックもあり Internet Verizon 701 通常経路 被害 ISP の細切れ経路 細切れ経路に含まれなかったアドレス帯もある 被害 ISP Google ユーザ (Eyeballs) 想定外のトラフィックによる輻輳 ほとんどが Verizon-> Google 経由に 影響 1: 海外経由による遅延の増加 影響 2: トラフィックの輻輳 影響 3: Google が経路を約 10 分後に消去した時のルーティングループ

22 リークの影響に加えて経路数の影響があった リーク影響型経路影響 自社型経路影響 透過型 約 10 万経路 約 10 万経路 リークされた経路のユーザ 自社設備 自社設備 顧客 顧客 経路のリークによって ユーザがつながりにくい事象 1. 海外経由による遅延の増加 2. トラフィックの輻輳 3. 経路消去時のルーティングループ ( ) トランジットから流入した経路増大により 自社設備に影響がでて 自社や顧客のサービスに影響 トランジットから流入した経路増大により 自社設備には影響がなくても 顧客の NW 機器 ( あるいは DC など ) が経路増大で影響 経路消去 (withdraw) 時のループに関しては IRS26 の資料参照

23 経路はどこから来たのか? 観測できているもの 被害 ISP の細切れ経路 悪意のある第 3 者 可能性 3 被害 ISP の細切れ経路 Internet Verizon 701 可能性 1 可能性 2 被害 ISP の細切れ経路 被害 ISP 細切れ経路 Google GoogleがISPから受け取った経路を内部的に分割していた (?) 2. ISPがGoogleに細切れ経路を何らかの理由で渡していた (?) 3. 第 3 者が詐称して注入した ( ) Googleが自身のミスを後日認めたためこの可能性はない (BGP 経路は 誰が注入したのかはわからないので 事象発生時点では Googleのミスかどうかは同定できなかった )

24 隣接 AS とのトラフィックエンジニアリング (BGP) l MED による重み付け MED:10 ユーザ (Eyeballs) ISP 隣接 AS MED:100 l MED によって どのピアからトラフィックを出してほしいか 要望することができる l MED は受信 AS 側で上書きすることができる l インターネットでは ってくるトラフィックは 根本的には制御できない l 双 に合意がなければ

25 隣接 ASとのトラフィックエンジニアリング (BGP) l CommunityおよびLocal Preferenceによる重み付け act-community ntt.netの例 ユーザ (Eyeballs) ISP 隣接 AS sby-community l 隣接 AS 側が Community に応じた Local Preference 値の実装を公開している場合がある l Community によってどのピアからトラフィックを出してほしいか 要望することができる l 双 に合意があるとみなせる

26 地理的広がりとプレフィックス分割 l 地理的広がりがあると レイテンシが効いてくる ユーザ A ユーザ A のベスト経路 数 msec の地理的隔たり ユーザ B ISP ユーザ A 向けトラフィック ユーザ B のベスト経路 ユーザ B 向けトラフィック 隣接 AS l ISP には地理的隔たりに合わせて プレフィックスを分割して 隣接 AS に経路を広告するモチベーションがある l 特に 隣接 AS がコンテンツプロバイダで l 低レイテンシが鍵となるアプリケーションである場合 l 隣接ピア向けとそれ以外で経路の細かさが異なる場合がある

27 Peer leaks l 最近では Google および Level 3 の事例 l 隣接ピアが 誤って経路を全インターネットあるいは部分に対して広告してしまうリスク l 特定のピア だけ に細かい経路を流していると リスクが まる

28 Secure BGP 経路漏れに関して BGP 元来の脆弱性を補う提案がいくつかある BGP Prefix Origin ValidaDon Route Origin AuthorizaDons(ROAs) を配布し検証する しかし Origin AS が正しい今回のようなハイジャックには効果がなかったと思われる maxlen(maximum prefix length) は有効かもしれない BGP Path ValidaDon AS-PATH に対して 署名検証する しかし MITM は防げるが 今回のような RouteLeak は防げなかったと思われる しかし そもそも 世界中の AS が対応しないと効果がない

29 実装上 プロトコル上の対策提案 [RFC8212]Default External BGP (EBGP) Route PropagaDon Behavior without Policies 何も考えずに ebgp のピアを張ったときに 全経路を送出しようとする動作をやめる [I-D.]Route Leak PrevenDon using Roles in Update and Open messages ピアを張るときに そのピアの用途を規定する ピア経由の経路 という transidve ahribute をつける

30 Espresso のインパクト l Espresso 以前 l Google に対して プレフィックス単位での制御 ( トラフィックエンジニアリング ) を期待して 細かい経路を渡す l Espresso 以降 l ISP 側がどのような単位で経路広告をしようが Google 側が 内部処理的に品質単位でプレフィックス分割をして トラフィックエンジニアリングを実施する l 今後は ISP は細切れ経路を出さなくて済むのか? l Google に対してはそうかもしれないが 全てのコンテンツプロバイダが Google と同様の仕組みを持つとは思えない

31 細切れされていく経路

32 細切れ経路 (more specific) IPv4 総経路のうち約 50% は ( 本来不要な ) 細切れ経路

33 細切れ経路 (more specific) 経年で割合が増えているわけではないが 用途が変わってきている

34 細切れ経路を出す理由 トランジットとのトラフィックエンジニアリング パンチングホール マルチホーム時のトラフィック操作 ピアとのトラフィックエンジニアリング ピアへのみ広報 グローバルインターネットでは観測されない これが漏れてしまうとシビアな経路漏れ事象になる 経路漏れ / 経路ハイジャック対策 DDoS 対策

35 経路漏れ対策としての細切れ経路 経路漏れされてしまったら 経路漏れ経路よりも細かい経路を流す 同一の長さの経路でも AS-PATH 長で勝てるかもしれない 経路漏れされないようにするには 基本無理 いかに気づくかが大事 全ての AS に送付する経路を一致させる ピアのオペミスの影響を最小化 常時最小単位に細切れする ( 前述の Overlay Type の広報 )

36 まとめ 昨今の Route Leak 事象の背景には コンテンツプロバイダでの SDN による粒度の細かい制御のために 経路を分割したいという要求がある BGP 上に SDN 制御をアドオンするという形式が引き続き続くとすると インターネット上で観測される経路は トラフィックエンジニアリング (DDo S 対策含む ) のためにさらに分割されていくと予想される